Home

Software Engineering im Unterricht der Hochschulen

1. http www microsoft com windows netmeeting 86 Philipp Bouillon Jens Krinke Stephan Lukosch den anzeigen wohingegen CURE in einem eigenen Browserfenster l uft Um also zu den synchronen Kommunikationswerkzeugen von CURE zu gelangen muss die IDE der Studierenden mit CURE berlagert werden Es findet ein Kontextwechsel statt der den Arbeitsfluss unterbricht Dieser notwendige Wechsel f hrte dazu dass die Studie renden aufgeh rt haben CURE f r ihre Chats zu benutzen was wiederum dazu f hrte dass die Betreuer des Praktikums keine M glichkeit mehr hatten auf diese Chats ein zugehen Um diesen Nachteil zu umgehen haben wir ein CURE Plug in f r Eclipse entwickelt das aus mehreren Sichten besteht Ein Screenshot dieses Plug ins ist in Ab bildung 1 zu sehen Die Hauptsicht zeigt die Seite eines Raums w hrend die Baum ansicht auf der rechten Seite alle momentan zur Verf gung stehenden R ume anzeigt Ein Softwareprojekt wird in einem eigenen Raum abgelegt w hrend die einzelnen Seiten Informationen ber die Teilprojekte Meilensteine und verschiedene andere Themen enthalten ure Eclipse Platform ER Fie ER niate Storch Prefect fan Window Heb rn amp 4 amp EI howe yResoace Srerigator D dpbore ven au _ 9 e 0 0 u SE TentProfnet d aop rereh co none E G Gavi feonony Casses amp hee JEG rcthodapP ape FE Maw dean G Uter promets D kipe bereien gap Ty Chet noom 1h Co
2. 2 Schreiben von Story Cards 3 Aufwandssch tzung Priorisierung 4 Aus wahl und Implementierung Schritte 2 4 eine Iteration werden dann noch einmal aus gef hrt In den meisten Schritten passieren noch einige weitere Aktivit ten z B Refac toring aber f r diese Diskussion ist das ohne Belang Wichtig ist nun e Jeder der sieben Schritte dauert genau 10 Minuten die Agile Hour also 70 Minuten e Das konstruierte Produkt wird nicht programmiert sondern gezeichnet e Die Entwickler arbeiten paarweise pair painting und haben nur einen Stift pro Paar Erfahrung T i t Abb 2 Agile Hour Erfahrung erw chst aus der Interaktion obwohl nur gemalt wird Es gibt noch einige weitere Regelungen die die Agile Hour einem agilen Software Projekt hnlicher machen sollen Was bewirkt eine Agile Hour nun aber in Bezug auf Erfahrungen Wir haben Gruppen bungen zum Thema agile Methoden in Form von Agile Hours durchgef hrt Jede Gruppe umfasste etwa 10 Studierende Die bungsbe treuer haben die Agile Hours als Coaches betreut waren also dabei Anschlie end wur de reflektiert und wir haben mit einem anonymen Fragebogen die Stimmung abgefragt In den meisten Agile Hours kam es zu Zeitnot und Hektik mitunter bereitete das Malen in Paaren Probleme fast immer auch die Integration der Teilergebnisse aller Paare Die R ckmeldungen sprechen eine klare Sprache Die Agile Hour vermittelt den Teilneh mern praktische Ken
3. Lehrstuhl f r Softwaretechnik Universitat des Saarlandes Postfach 15 11 50 66041 Saarbr cken lindig zeller cs uni sb de Zusammenfassung Ein semesterbegleitendes Softwaretechnik Praktikum verleitet die Teilnehmer dazu vor lauter Begeisterung und Gruppendruck andere Veranstaltungen zu vernachl ssigen An der Universit t des Saarlandes wird das Praktikum daher in der vorlesungsfreien Zeit absolviert und zwar als sechsw chiger Vollzeitkurs mit begleitender Vorlesung Diese Form wirkt studienverk rzend und verein facht die Teamarbeit durch Ganztagspr senz Risikomindernde Ma nahmen wie ein einheitliches vorgegebenes Pflichtenheft spielerische Elemente und automa tisch testbare Erfolgskriterien sorgen f r hohe Motivation bei reibungslosem Ab lauf 1 Stand der Dinge Die Universit t des Saarlandes hat 2001 im Rahmen der Umstellung auf ein Bache lor Master System ein neues Softwaretechnik Praktikum eingef hrt das mit 14 von 30 ECTS Punkten etwa die H lfte des 3 Semesters einnahm Das Ziel des Praktikums ist das systematische Programmieren im Gro en im Team Dazu durchlief im Praktikum jedes Team aus f nf Studenten f nf Phasen e Anforderungsanalyse abgeschlossen mit Pflichtenheft e Grobentwurf abgeschlossen mit Objektmodell und Sequenzdiagrammen e Feinentwurf abgeschlossen mit Prosa Beschreibung und Unit Tests e Implementierung abgeschlossen mit fertigem Produkt e Test abgeschlossen mit Testbericht Die
4. mit XP experimentiert Auf der IF wurde mit 10 Teilnehmerinnen ein einw chiges XP Projekt durchgef hrt Das Software Praktikum ist eine Pflichtveranstaltung im Informatik Grundstudium in dem die Studierenden im Team von 6 bis 8 Studierenden entweder ein Semester oder sechs Wochen lang in einer Blockveranstaltung Softwareentwicklungs Projekte durchf hren Insbesondere hat uns als Lehrende die Frage interessiert wie auf sinnvolle Weise die XP Konzepte einf hrt werden k nnen wie Programmieranf nger damit zurechtkommen und welche Techniken von XP besonders nutzbringend sind Im Anschluss werden zun chst hnliche Projekte zur Einf hrung von XP vorgestellt unser Versuchsrahmen beschrieben und unser Einstieg in XP erl utert Dann wird genauer auf die f r die Lehre wichtigen Merkmale von XP eingegangen der Unterschied zur UML basierten Vorgehensweise herausgestellt und unsere Ergebnisse in den Experimenten mit XP vorgestellt Aus den positiven und negativen Erfahrungen werden Konsequenzen f r die weitere Ausbildung im Software Praktikum gezogen 2 Die Einf hrung in XP Newkirk und Martin beschreiben in NeMa01 sehr anschaulich ein reales Pilotprojekt zur Einf hrung von XP in einer Softwarefirma Keine der beteiligten Personen alle erfahrene Softwareentwickler hatte zuvor in einem echten XP Projekt gearbeitet Die lebhaften Schilderungen der positiven Erfahrungen und Fehler haben unsere Neugier geweckt XP selbst auszuprobieren Auch a
5. sammensetzung n tig war Dies war aber ohne gro e Probleme m glich Im Laufe des Semesters stellte sich heraus dass die Vermittlung des Lehrstoffs bottom up sowohl Vor als auch Nachteile mit sich bringt Ein deutlicher Vorteil war dass die Studierenden sich gleich am Anfang mit dem Quellcode besch ftigen konnten Dies war ohne SWE Vorwissen m glich Durch die kurze Einf hrung in die Program miersprache Java und die kleinen bungen konnten die Studierenden langsam und gef hrt den Quellcode von Sysiphus kennen lernen Wie erhofft war die Erstellung der Modelle anhand des Codes relativ einfach Insbesondere ist es hilfreich wenn die Stu dierenden in einem ersten Schritt vorhandene Modelle erg nzen bevor sie sie dann selbstst ndig erstellen Weiterhin kann das Bewusstsein f r das Thema Testen von Anfang an geschaffen werden da von Beginn an ausf hrbarer Code vorliegt Beim Forward Engineering konnte dann von Anfang an jeweils die Testplanung parallel zur Spezifikation durchgef hrt werden Die Vermittlung der SWE Phasen in umgekehrter Reihenfolge hatte aber den Nach teil dass die Studierenden relativ bald unter den vielen Einzeltechniken den Wald vor lauter B umen nicht mehr sahen und die Zusammenh nge der Techniken erst in der zweiten H lfte entdeckten So entstand nach einigen Wochen ein Motivationsproblem das nur durch erh hten Betreuungsaufwand abgefangen werden konnte Die Verwirrung zwischen den Ebenen Anwendun
6. Abnahme und bergabe Des Weiteren muss Qualit tssicherung und Projektmanagement geleistet werden Ne ben der praktischen Arbeit geh ren zum Studienprojekt begleitende Vorlesungen und ein Seminar In der Regel wird ein Studienprojekt von einem Institut angeboten Dabei ber nimmt ein Mitarbeiter die Kundenrolle zwei Mitarbeiter betreuen die Teilnehmer Die Anforderungen an Projekt und Produkt werden vom Institut festgelegt Weil ein Mitar beiter die Rolle des Kunden nicht vollst ndig wahrnehmen kann haben wir hochschul externe und damit reale Kunden in das Studienprojekt eingebunden 3 2 Vorbereitung des Projekts Ein Semester vor Beginn des Studienprojekts wurde das Projektziel innerhalb des Insti tuts gekl rt und festgelegt Im Studienprojekt sollte ein System zur Verwaltung und Darstellung von Anforderungen und weiteren Informationen erstellt werden Als Archi tektur war eine Basissoftware f r die Verwaltung von Projektinformationen gefordert dazu sollte ein Plug in f r die Verwaltung von Anforderungen und Beziehungen zwi schen Anforderungen erstellt werden Weitere Plug ins f r die Verwaltung von Hand bucheintr gen oder Testf llen integriert mit den Anforderungen sollten m glich sein 140 Tilmann Hampp Stefan Opferkuch Rainer Schmidberger Dieses System sollte als Web Anwendung in Java realisiert werden und auf einer Da tenbank basieren Wir konnten zwei externe Kunden gewinnen Ein Kunde war ein Schulungsunter
7. Das Konzept der Teachlets wurde urspr nglich zur Vermittlung von Entwurfsmus tern entwickelt scheint aber Potenzial f r eine breitere Anwendung zu haben In diesem Artikel werden prim r Teachlets zur Vermittlung von Entwurfsmustern diskutiert weil hier die meiste Erfahrung gesammelt wurde Im Ausblick werden weitere m gliche Anwendungsfelder angesprochen Das Konzept wurde in einem Projektseminar im Sommersemester 2004 an der Uni versit t Hamburg erstmalig vorgestellt und von den Teilnehmern sehr positiv auf genommen Der Veranstalter f hrte zu Beginn einige Teachlets selbst durch um das Konzept zu verdeutlichen Anschlie end hat im Laufe der Veranstaltung jeder Teil nehmer mindestens ein Teachlet selbst entwickelt und an der Gruppe ausprobiert Dieser Artikel ist in erste Linie ein Erfahrungsbericht Im folgenden Abschnitt wird zun chst das Grundkonzept eines Teachlets vorgestellt Abschnitt 2 stellt ein Beispiel dar und Abschnitt 3 fasst die Erfahrungen zusammen die bisher bei der Durchf hrung von Teachlets gesammelt wurden In Abschnitt 4 wird das Konzept einer seminararti gen Teachlet Werkstatt dargestellt in der die Teilnehmer selbst Teachlets entwerfen und auf diese Weise intensiv mit dem zu vermittelnden Stoff umgehen m ssen Ab schnitt 5 gibt einen Ausblick auf weitere Anwendungsfelder sowie auf Aktivit ten die den Ansatz weiter erkunden k nnen 2 Teachlets Die folgende Definition bildet die programmatische Grundlage
8. Die Studierenden wissen zu Beginn dass sich Details ndern k nnen aber nicht welche Details das sind und streben angesichts dieses Risikos einen m glichst flexiblen Ent wurf an In den folgenden zwei Wochen wird das System implementiert Meilenstein ist hier das Bestehen eines vorgegebenen automatischen Tests der die ge samte Funktionalit t des Systems abdeckt Zum Einreichen und Testen der Programme setzen wir Praktomat Zel00 ein Plagiaten sp ren wir mit JPlag PMPO00 nach In den letzten zwei Wochen wird das System eingesetzt Ohne Kunden muss es f r die Studierenden eine weitere Motivation geben das System auf Herz und Nieren zu pr fen Meilenstein ist daher die Qualifikation f r ein Turnier in dem die besten Systeme gek rt werden 72 Christian Lindig und Andreas Zeller Vorlesung MDMOFSSMDMDFSSMDMODFSSNDMDFSSMOMDFSS MOMDE UU Einsatz 4 I Meilenstein Kompletter i Meilenstein Automatisch Meilenstein Qualifikation durchgesehener Entwurf getestete Implementierung gegen einfache Mannschaft i i 2 Wochen 2 Wochen 2 Wochen Abb 1 Schematischer Ablauf des Praktikums Die Forderung nach einem objektorientierten Entwurf innerhalb von zwei Wochen be dingt eine gro e Menge an Stoff der zu Beginn behandelt werden muss Konkret haben die Studierenden in der ersten Woche jeden Morgen zwei Vorlesungsstunden absolviert mit Themen wie Teamarbeit objektorientierte Modelli
9. Ergebnisse aus Hauptstudiumspro jekten entsprechen unserer Einsch tzung nach qualitativ dem g ngigen Industriestan dard oder liegen sogar dar ber Wir werden daher zuk nftig Projekte der Lehre nach M glichkeit mit externen Kun den durchf hren Literatur Lud 99 J Ludewig Softwaretechnik in Stuttgart ein konstruktiver Informatik Studiengang Informatik Spektrum 22 1 1999 57 62 Lud 01 J Ludewig Hrsg Praktische Lehrveranstaltungen im Studiengang Softwaretechnik Programmier kurs Software Praktikum Studienprojekte Fachstudie Mit Beitr gen von Stefan Krau Jochen Ludewig Patricia Mandl Striegnitz Ralf Melchisedech Ralf Rei ing Bericht der Fakult t Informatik Universit t Stuttgart 3 Auflage 2001 AMEISE Didaktische Vielfalt f r SESAM Susanne Jager Elke Hochm ller Roland Mittermeir Andreas Bollin Daniel Wakounig Institut f Informatik Systeme Universit t Klagenfurt Fachhochschule Technikum K rnten Universitatsstr 65 67 A 9020 Klagenfurt Primoschgasse 8 A 9020 Klagenfurt susi roland andi daniel isys uni klu ac at E Hochmueller fh kaernten at 1 Motivation Der Stuttgarter SESAM Simulator Dra00 hilft Studierenden Projektmanagement f higkeiten ohne Gef hrdung eines realen Projekts zu erwerben Allerdings ist die Feedbackgenerierung aufw ndig AMEISE beschleunigt dies und erlaubt didaktische Variationen der Projektsimulationen Mit03 2 AMEISE spezifis
10. J Seel Georg Simon Ohm Fachhochschule N rnberg private Mitteilungen 1998 Sta 01 Standish Group International inc Extreme Chaos 2001 www standishgroup com sample_research PDFpages extreme_chaos pdf
11. Neumeyer TU Darmstadt Softwaretechnik Praktika Softwaretechnik live im Praktikum zur Projekterfahrung P G hner F Bitsch H Mubarak Univ Stuttgart Vom Code zu den Anforderungen und wieder zur ck Software Engineering in sechs Semesterwochenstunden B Paech L Borner J R ckert Univ Heidelberg A H Dutoit T Wolf TU M nchen Ein Softwaretechnik Praktikum als Sommerkurs 2 uun2000000000000nn0n000 C Lindig A Zeller Univ des Saarlandes viii Inhalt Fernlehre und Nahlehre Eine Plattform f r die Softwaretechnik Fernlehre 0 0 eseeee 81 P Bouillon J Krinke S Lukosch FernUniversit t Hagen Eine Werkstatt zum Vermitteln objektorientierter Entwurfs und Sprachkonzepte mit Teachlets unrusnannnsnannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnannnnn ann 93 A Schmolitzky Univ Hamburg PSP und XP Using Personal Software Process exercises to teach process measurement uressssnnnnnnenennnnnnnnnnnnnenennnnnnnnnnnnnnnneennnnnnnnn anne 105 A l Verkamo A Saura Univ Helsinki Erfahrungen mit XP unssnnsssnnssnnnnnnennnnnnnnnnnnnnnennnnnnn nennen nennen anne nenn 114 D Schmedding I Beckmann Univ Dortmund Praktika mit externen Projekten Softwaretechnologie Praktikum im Grundstudium universit res oder reales Projekt unsnssesnnnnnnnnnnannnnnannnnnnnennnnnnnnnnnnnnn 124 B Demuth TU Dresden L Schmitz Uni
12. Praktikumsleiter sollte dabei thematisieren welche Optionen ein Team zur Einhaltung harter Termine hat Mehrarbeit Abstriche bei Funktionalit t Abstriche bei Qualit t und danach aufzeigen welche Konsequenzen die getroffenen Entscheidungen haben Professioneller Werkzeugeinsatz Zu viele Werkzeuge lenken vom eigentlichen Ziel der Ausbildung ab wenige helfen die Konzepte durch Anwendung zu lernen Glinz1996 Praxis bliche Werkzeuge f r Modellierung Codierung bersetzung und Fehlersuche sind in diesem Sinne richtig am Platz in jedem Software Praktikum Die obligatorische Verwendung eines Konfigurationsmanagement Werkzeugs ist jedoch zweischneidig Ohne das Chaos einmal selbst erlebt zu haben sehen die Studierenden die Notwendigkeit des Konfigurationsmanagements nicht ein Dirty Tricks K nstlich herbeigef hrte Serverabst rze korrupte Code Reposito ries usw werden von Dawson2000 empfohlen um Praxisn he herzustellen Unserer Erfahrung nach kreieren Teilnehmer vergleichbare unvorhersehbare Produktivit ts verluste bereits selber durch unklare Abstimmung im Team vergessenes Abspeichern von Arbeitsergebnissen etc Insgesamt erscheint ein sehr sparsamer Einsatz von Dirty Tricks vorzugsweise bei sehr Fortgeschrittenen sinnvoll 6 Robert Stoyan Martin Glinz Weitere Ma nahmen e Integration mit vorgegebenen Schnittstellen e Projektmanagement siehe Abschnitt Leistungskontrolle e Wechselnde Ansprec
13. Zu gro sind die Unterschiede in den Rahmenbedingungen in der Motivation und in vielen weiteren Aspekten Wir hielten es f r unrealistisch alle diese Unterschiede berbr cken zu wollen Wir haben daher entschieden die meisten Unterschiede zu akzeptieren aber an einigen wenigen Stellen gezielt zu intervenieren Die interessantesten waren e Strikte Rollentrennung zwischen Kunde Entwicklern und der Firma der Entwickler Wir haben am Lehrstuhl die Rollen verteilt und darauf geachtet sie nicht zu vermischen Die fiktive Entwicklungsfirma war mit Qualit tssi cherern bestrebt die Qualit t ausgelieferter Teil Produkte hoch zu halten Diese Rollenteilung ist an Hochschulen oft un blich Unserer Ansicht nach ist sie aber f r viele typische Projekteffekte unabdingbar Und erfreulicher weise bereitet die Rollenteilung auch f r Betreuer kaum zus tzlichen Auf wand e Quality Gates zur groben Qualit tssicherung Das ist eine Variante von eher formalistischen Pr fungen an festgelegten Stellen im zuvor definierten Pro zess eine Art verallgemeinerte Meilensteine f r das Multiprojekt management Sie laufen hnlich wie Review Sitzungen ab und dienen vor al lem dazu festgelegte Mindeststandards an festgelegten Prozessstellen quer ber alle Projekte sicherzustellen Wir haben durch drei Quality Gates einen Qualit tsmindeststandard in allen abgelieferten Produkten erreicht Quality Gates sind in der Industrie weit verbreitet
14. auch dessen Ergebnisse zu kontrol lieren Dies ist an sich einfach Im SoPra wurde direkt vorgegeben dass zwingend in jeder Praktikumseinheit alle Ergebnisse vom Team abgegeben werden m ssen damit die Teammitglieder ihren Leistungsnachweis erhalten Die Tutoren geben Lob und erkl ren M ngel bei gr eren Problemen muss das Team noch mal abgeben 12 Robert Stoyan Martin Glinz Der damit vorprogrammierte Frust bei unterschiedlichen Leistungen im Team ist der schwierigere Teil Dieser kann vorab mit dem Vergleich zur Industriepraxis und Defini tion als Lernziel in Praxisn he verwandelt werden Damit dies zum vollwertigen Prakti kumsinhalt wird miissen Teamarbeitskompetenzen auch unterrichtet werden siehe z B Raasch1997 Speziell beziiglich Leistungskontrolle wurde im SoPra gelehrt was getan werden kann Jeder hat die Eigenverantwortung abzusch tzen ob er mit seinen Teammitgliedern zum Ziel kommt Wenn w hrend der Arbeit die eigene Leistung oder die eines Teammitglieds ungeniigend ist offen dariiber sprechen und nach Abhilfe suchen sowie nach Aufgaben welche ein solches Teammitglied dennoch tibernehmen kann Wenn das Team das Problem nicht l sen kann dem Tutor Bescheid sagen Wenn Tutor und Obertutor das Problem nicht l sen k nnen gelangt das Problem an die Prak tikumsleitung die im Extremfall Teams neu zusammenstellen oder iiberpriifen kann ob der Betreffende die Voraussetzungen fiir das Praktikum erfiillt Das liegt so weit
15. dass die mit dem Rationale verbundene Review Funktionalit t auch zur direkten Kommunikation zwischen Betreuer und Studierenden genutzt werden kann Der Betreuer kann f r die Aufgabenbearbeitung spezifische Fra gen festlegen die von den Studierenden beantwortet werden m ssen Dies erm glichte sie bei der Bearbeitung der Dokumente in die richtige Richtung zu lenken Weiterhin konnten die Betreuer den Studierenden mit dem Werkzeug sofort strukturiert Feedback zu ihren L sungen geben bzw L sungen hinterfragen Am Schluss des Semesters bewerteten die verbliebenen 8 Studierenden die Lehrver anstaltung Dabei zeigte sich dass alle Studierenden viel oder zu mindestens etwas Spa an den gestellten Aufgaben hatten auch wenn der Nacharbeitungsaufwand mit durchschnittlich 7 angegebenen Stunden pro Woche doch recht hoch war Einem Gro teil der TeilnehmerInnen war die Verwendung von Sysiphus als bungsobjekt f r den Lernerfolg wichtig 3 bzw sogar sehr wichtig 2 Eine Person war der Meinung dass die Verwendung von Sysiphus eher hinderlich f r den Lernfortschritt gewesen ist Die Arbeit in der Gruppe wurde von 3 Studierenden als sehr wichtig und von weiteren 3 Studierenden als wichtig eingesch tzt Hingegen empfanden 2 Studierende die Arbeit in der Gruppe als st rend Zusammenfassend kann gesagt werden dass die Lehrveranstaltung ein Erfolg gewe sen ist und bei den Studierenden gro en Anklang gefunden hat Die Studierenden haben trot
16. gung gestellt um Reengineering zu ben Das SoPra hat w chentlich vier Stunden Pr senzzeit mit Anwesenheitspflicht Voraussetzung sind Programmier kenntnisse in Java die jedoch erfahrungsgem sehr unterschiedlich ausfallen sowie der Besuch einer zweist ndigen Vorlesung Software Engineering im Semester davor F r jede Durchf hrung des SoPra wird ein wissenschaftlicher Assistent als Prakti kumsleiter bestimmt 2004 der Erstautor dieses Beitrags ein Professor der Zweitau tor tr gt die Gesamtverantwortung f r Konzept und Durchf hrung des SoPra Zur Durchf hrung des Praktikums und zur Betreuung der Studierenden stehen dem Prakti kumsleiter pro Klasse ein Obertutor und vier Tutoren zur Verf gung Jeder Tutor ist f r zwei Teams verantwortlich Die Obertutoren bereiten gemeinsam mit dem Praktikums leiter das gesamte Praktikum vor Sie sind an der Auswahl der ihnen zugeordneten Tutoren aus dem Kreis der Bewerberinnen und Bewerber beteiligt anschlie end schu len sie diese in zwei Tagen Pr senzunterricht Im Projekt haben Praktikumsleiter und Obertutoren die Rolle des Auftraggebers die Tutoren die von Coaches die Teams sind Firmen Die Praktikumsaufgabe im Sommersemester 2004 war die Erstellung der Software f r ein B rsencafe bei dem die Preise ausgew hlter Speisen und Getr nke sich je nach Nachfrage der G ste ndern Die Software muss die Erfassung der Bestellungen der G ste die Berechnung der variablen Preise die Anzeige
17. ltigt Praktika richten sich schon st rker an das praktische K nnen und die Erfahrung Ich m chte im vorliegenden Beitrag vier verschiedene Ans tze vorstellen die im Studium explizit auch die Weitergabe von Erfahrungen bewirken sollen Dann vergleiche ich die Kernideen und arbeite heraus wof r sich welche Form gut eignet und wann weni ger Daraus ergeben sich einige Empfehlungen wie man Erfahrungen nicht Wissen im Studium handhaben kann Der Beitrag ist als Diskussionsimpuls zu verstehen 2 Simulation eines ganzen Software Projekts SESAM Das Projekt SESAM wurde vor ber zehn Jahren am Lehrstuhl von Prof Jochen Lude wig an der Universit t Stuttgart gestartet Dra 95 Ihm liegt die Idee zugrunde ein in teraktives Simulations und Lehrspiel f r Software Projektleiter zu entwickeln Dabei sollte ein gesamtes Software Projekt simuliert werden nur der Projektleiter selbst war real und interagierte mit dem simulierten Rest seines Projekts SESAM wurde schon in den fr hen 90er Jahren in der Lehre eingesetzt Sch 94 Es wird auch heute noch weiterentwickelt ASE 04 Erfahrung tJ ky Abb 1 SESAM Erfahrung erw chst aus Interaktion mit dem simulierten Projekt Im Kern braucht SESAM ein umfassendes dynamisches Modell des simulierten Ent wicklungsprojekts Dei 94 Es muss auf Korrektes das hei t der Vorlesung entspre chendes Verhalten des Projektleiters reagieren aber auch auf Verst e und Fehler ein
18. nur solche Medien einzusetzen die die Studierenden auch w hrend des Praktikums einsetzen k nnen daher haben wir zum Beispiel auf Metaplanw nde und Moderationskarten gr tenteils verzichtet und stattdessen W nde Beamer Laptop und Flipcharts eingesetzt Arbeitsteilung Etliche Aufgaben m ssen nicht von allen Teammitgliedern gemeinsam bearbeitet werden sondern k nnen auf Teilgruppen verteilt werden Dies erh ht die Effizienz des Teams erheblich wenn einige Regeln beachtet werden beispielsweise e F r jede Aufgabe sollte es eine verantwortliche Person und eine Deadline geben e Zu Beginn der Aufteilung sollte sichergestellt werden dass die einzelnen Teilgruppen genau wissen was sie bearbeiten sollen und welche Form die Ergebnisse haben sollen z B Stichpunktliste kurze Pr sentation e Wird ein Dokument aufgeteilt bietet es sich an dass vorher eine Teilgruppe eine Vorlage erstellt aus der die Formatierungen Formulierungsstil Umfang ersichtlich sind diese Vorlage sollte gemeinsam von allen Teammitgliedern diskutiert und verabschiedet werden e Wird Sourcecode aufgeteilt gibt es Richtlinien f r das gemeinsame Nutzen eines CVS Repositories zum Beispiel regelm iges Einchecken Update bevor man eine Datei bearbeitet nur Einchecken von compilierbaren Code 3 5 Projektmanagement In der Regel haben nicht alle Teilnehmer an dem Praktikum bereits eine Software Engineering Vorlesung geh rt und daher keine recht
19. 99 bereits ausf hrlich berichtet Die Durchf hrung des Praktikums in einer fr hen Phase des Studiums soll eine um fassende Ausbildung aller Studenten auf dem Gebiet der Softwaretechnologie gew hr leisten birgt aber auch Probleme in sich Insbesondere die j hrliche Teilnehmerzahl von ca 500 Studenten an der TU Dresden ca 90 an der UniBw M nchen erfordert einen au erordentlich hohen organisatorischen und personellen Aufwand Zeitweilige Engp sse bei den Hilfskraftmitteln vor etwa f nf Jahren gaben dann den Ansto an der TU Dresden die externe Form der Praktikumsdurchf hrung als m gliche Alternative zu erproben Seitdem nehmen dort je nach Anzahl der verf gbaren Praktikumspl tze j hr lich 15 20 der Studenten am externen Praktikum teil Die Studenten m ssen sich explizit daf r bewerben und werden aufgrund ihrer Vorleistungen in der Grundlagen lehrveranstaltung Softwaretechnologie ausgew hlt F r uns ergab sich die seltene Gelegenheit die beiden unterschiedlichen Formen der Praktikumsdurchf hrung bei identischer Studiensituation ber einige Jahre neben einander zu beobachten und zu vergleichen Im Folgenden beschreiben wir Ziele und Rahmenbedingungen des Software praktikums innerhalb eines Massenstudiums Abschnitt 2 anhand der internen Prakti kumsform die davon abweichenden Merkmale externer Projekte Abschnitt 3 sowie Beobachtungen und Erfahrungen die wir im Laufe der Jahre bei der Durchf hrung dieses Praktikums m
20. Anforderungen und wieder zur ck 67 Danksagung Wir danken Philipp H fele f r seinen Einsatz bei der Gruppenbetreuung und allen Teil nehmerlInnen f r die konstruktive Mitarbeit Literatur Bec 03 P Becker Pechau W G Bleek H Z llighoven Integration agiler Prozesse in die Softwaretechnik Ausbildung im Informatik Grundstudium In SEUH 03 dpunkt verlag 2003 S 8 21 Ble 99 W G Bleek G Gyczan C Lilienthal M Lippert S Roocks H Wolf H Z llighoven Von anwen dungsorientierter Softwareentwicklung zu anwendungsorientierten Lehrveranstaltungen der Werkzeug amp Material Ansatz in der Lehre In SEUH 99 Teubner 1999 S 9 20 Bot 01 K Bothe U Sacklowski Praxisn he durch Reverse Engineering Projekte Erfahrungen und Ver allgemeinerungen In SEUH 01 dpunkt verlag 2001 S 11 21 Dem 99 B Demuth H Hu mann S Zschaler L Schmitz Erfahrungen mit einem frameworkbasierten Softwarepraktikum In SEUH 99 Teubner 1999 S 21 30 Dut 02 A H Dutoit B Paech Rationale based use case specification Requirements Engineering Journal vol 7 S 3 19 2002 Dut 04 A H Dutoit T Wolf B Paech B Borner J R ckert Using Rationale in Software Engineering Education in submission 2004 Ecl 04 Eclipse http www eclipse org 2004 Jud 04 JUDE http objectclub esm co jp Jude 2004 Kle 01 N Kleiner S Sarstedt Einsatz von Standardprozessen bei der Gestaltung von Lehrveranstaltung
21. Berichten ber Software Praktika sonst der Fall ist Nicht zum Praktikum wird beschrieben welcher didaktische Nutzen entsteht sondern zu didaktischen Zielen wird genannt welche Me thoden und Techniken zur Erreichung dieser Ziele beitragen Im Aufruf zur Einreichung von Beitr gen f r die SEUH 2005 wird als Themen schwerpunkt unter anderem Invarianten der Softwaretechnik Lehre Verfallsdatum gt 2050 genannt Wir hoffen dass diejenigen von uns die im Jahr 2050 noch leben dann verifizieren k nnen dass einige der in unserem Beitrag zusammengetragenen Erkenntnisse zu diesen Invarianten geh ren Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 15 Danksagung Wir danken allen die an der Entwicklung und Durchf hrung des Software Praktikums an der Universit t Z rich beteiligt waren und sind Unser besonderer Dank richtet sich an Silvio Meier Christian Seybold Nancy Merlo Schett und Philippe Sch rmann f r den Erfahrungsaustausch Harald Gall und Gerald Reif f r die konstruktiven Hinweise zu diesem Artikel sowie nicht zuletzt unseren Tutoren und Studierenden f r unz hlige kompetente R ckmeldungen Literatur Beck2000 K Beck eXtreme Programming explained Embrace Change Reading Addison Wesley Bothe2001 K Bothe U Sackowski Praxisn he durch Reverse Engineering Projekte Erfahrungen und Verallgemeinerungen In H Lichter M Glinz Hrsg Software Engineering im Unterric
22. Das Praktikum begann im Februar 2003 und endete im August 2003 Es nahmen etwa 60 Studenten teil In der ersten Veranstaltung stellten sich die Kunden vor und das Las tenheft wurde pr sentiert Nach Zusammenstellung der Gruppen aus je drei Studenten und Zuordnung der Gruppen zu einer der drei Komponenten wurden sechs Teams ge bildet die aus je drei Gruppen f r die drei Einzelkomponenten bestanden So erstellte jedes Team ein Gesamtsystem Wichtig hierbei war dass alle Teams die Komponenten an genau festgelegten Schnittstellen verbinden mussten Der Ausfall einer Gruppe konnte so durch eine andere Gruppe ersetzt werden Die Schnittstelle zwischen den Komponenten bildeten die Klassen des fachlichen Dom nenmodells das ber eine Persistenzschicht auf eine relationale Datenbank abge bildet wurde Die Persistenzschicht wurde von den Betreuern gestellt und war nicht Teil der studentischen Arbeit Das fachliche Dom nenmodell wurde in einem Workshop gemeinsam mit den Studenten erarbeitet und anschlie end den Gruppen als UML Modell und Java Code zur Verf gung gestellt Aus den Dom nenklassen wurde auch das relationale Modell abgeleitet das damit ebenfalls allen Gruppen vorgegeben wurde Projekte der Lehre mit hochschulexternen Kunden 137 Nach der Kundenpr sentation entwickelten nun die Studenten einen Fragenkatalog f r die zwei Wochen sp ter stattfindende Kundenbefragung Die Kundenbefragung war derart organisiert dass ein Team also drei
23. Den 98 M Deneke U Schr der M Brunner Constructionist Learning in Software Engineering Projects SEES 1998 Software Engineering Education Symposium 18 20 November 1998 Poznan Polen 1998 Fle 02 A Fleischmann Entwurf eines berufsbegleitenden Aufbaustudiengangs fiir Software Engineering Diplomarbeit am Fachbereich Informatik der Technischen Universit t Darmstadt Betreuer Prof Henhapl Darmstadt 2002 Gna 03 M Gnatz L Kof F Prilmeier T Seifert A Practical Approach of Teaching Software Engineering In P Knoke A Moreno M Ryan Hrsg 16th Conference on Software Engineering Education and Training pages 120 128 IEEE Computer Society March 2003 Hen 02 W Henhapl Hrsg Informationsseite des Instituts f r Praktische Informatik an der TU Darmstadt zum Software Engineering Projekt Darmstadt 2002 http www pi informatik tu darmstadt de se2002 Henn 02 M Henninger H Mandl Zuh ren verstehen miteinander reden Hans Huber Verlag 2003 Kom 04 Hochschuldidaktische Arbeitsstelle der Technischen Universit t M nchen Teamtrainings nach dem KOMPASS Konzept Darmstadt 2004 http www tu darmstadt de hda tutorengruppe kompass html Lan 00 B Langemaack M Braune Krickau Wie die Gruppe laufen lernt Anregungen zum Planen und Leiten von Gruppen Beltz Verlag Weinheim 2000 Lud 02 J Ludewig Thesen zur Softwaretechnik in den Universitat Vortrag am 30 April 2002 in der TU Darmstadt auf dem Symposium S
24. Feinentwurf f r Erweiterung Integrationstest 9 von REQuest li k Sequenzdiagramme Sequenzdiagramme Feinentwurf Integrationstestplan Entwurfsmuster 10 Inspektion Meilenstein 2 I Komponententest Klassendiagramme Implementation der Erweiterung von REQuest Programmierrichtlinien 2 ogra ermenin Implementation Ausf hrung der Tests Usability Test y Pr sentation der Ergebnisse Meilenstein 3 d Java Einf hrung und kleine Java bungen Abb 1 Abfolge der Themen einzeln vorgestellt und einge bt w hrend in der zweiten H lfte diese Techniken zu einem durchg ngigen Entwicklungsprozess verbunden werden Vom Code zu den Anforderungen und wieder zur ck 59 Die Abfolge der Themen ist in Abbildung 1 verdeutlicht und wird im Abschnitt 3 n her erkl rt Klammern bedeuten dass das Thema inhaltlich an diese Stelle geh rt aber aus Zeitgr nden in die 2 H lfte verschoben wurde Qualit tssicherungsma nahmen sind fett gedruckt Die Bearbeitung der Reverse Engineering Aufgaben sowie der Forward Engineering Aufgaben erfolgt in Teams mit enger Betreuung durch je einen Mitarbei ter um insbesondere auch die Kommunikations und Koordinationsaspekte des SWE einzu ben 2 2 Das zu bearbeitende System Sysiphus Wie oben erl utert sollen die Studierenden mit einem existierenden Softwaresystem arbeiten Dazu muss nat rlich einerseits der Code zugreifbar sein anderer
25. Gliederung und die Aufgabenstellung waren betont realistisch Dazu geh rte dass die Aufgabe von lehrstuhlfremden Kunden gestellt wurde dies waren Mitarbeiter der Informatik die im Rahmen von Forschungsprojekten geeignete Programmieraufgaben zu vergeben hatten von der inhaltlichen Betreuung des Praktikums aber entbunden wa Ein Software Praktikum als Sommerkurs 69 ren Im Laufe des Semesters gab es Meilensteine zu denen die entsprechenden Phasen dokumente vorliegen mussten und bewertet wurden Die Softwaretechnik Vorlesung fand zeitgleich statt sie war im Inhalt auf den Fortschritt im Praktikum abgestimmt Obwohl das Praktikum zu den beliebtesten Veranstaltungen des Grundstudiums ge h rte gab es eine Reihe von Problemen Zeitaufwand Unter Druck von Gruppe und Kunden neigten Studierende da zu ihre Arbeit besonders gut zu machen und dar ber andere Vorlesungen zu vernachl ssigen DHZS99 Dies wirkte tendenziell studienverl ngernd Gruppen aus schlechten Studenten Die Leistung von Informatikern schwankt bekanntlich in gro em Ma e DHZS99 Wir haben festgestellt dass gute Studenten gerne mit anderen guten Studenten eine Gruppe bilden was die Leistungsunterschiede der Gruppen potenziert und schlechtere so wie unkommunikative Studenten alleine zur ckl sst Gruppen aus guten Studenten Gruppen nur aus guten Studenten handeln sich Probleme ein wenn sie glauben dank ihrer Programmierkompetenz Entwurf und Gruppenkommunikati
26. Im externen Praktikum sind alle Teammitglieder auf einem etwa gleich hohen Niveau und werden damit eher gleich stark am Projekt beteiligt Eventuel le Teamprobleme sind hier oft darauf zur ckzuf hren dass starke Individualisten auf einander treffen Diese Studenten entsprechen oft dem Klischee des Hackers der zudem keine Teamerfahrung mitbringt Bei der Betreuung sind beide Ph nomene zu ber cksichtigen und entsprechend zu behandeln Es hat sich gezeigt dass es notwendig ist den Tutoren konkrete Entscheidungshil fen und Druckmittel zur Durchsetzung der Praktikumsanforderungen zur Verf gung zu stellen und ihr Einsatz h ufig auch erforderlich ist Speziell im internen Prak tikum f hrt die Arbeit an einem komplexen zeitaufw ndigen Projekt ohne realen Kun den bei vielen Studenten zu geringem Engagement Der Lernerfolg und der Nutzen f r zuk nftige Projekte sind f r sie in dieser fr hen Phase des Studiums oft schwer abzu sch tzen Daher neigen die Studenten dazu die Anforderungen nicht ernst zu nehmen sowie Fehler bzw Zeit berschreitungen zu bagatellisieren Hier ist es entscheidend Meilensteine klar zu definieren und deren Nichteinhaltung mit Konsequenzen zu ver binden Ebenso muss das Einfordern definierter Dokumente und Ergebnisse zu konkre ten Terminen durch die Tutoren konsequent durchgesetzt werden Problematisch ist in diesem Zusammenhang die Einsch tzung von Zwischenergebnissen H ufig k nnen abgegebene Doku
27. Iteration bildete ein lauff higes Produkt mit eingeschr nkter Funktionalit t Dieses Produkt wurde von den Kunden evaluiert sodass Anforderungs nderungen in der zwei ten Iteration realisiert werden konnten Nach der zweiten Iteration wurde das vollst n dige Produkt ausgeliefert Dieses iterative Vorgehen haben wir gew hlt weil einer der beiden Kunden auf das Produkt angewiesen war Dieser Kunde konnte das Produkt fr h einsetzen au erdem konnten noch nderungen und Korrekturen in der zweiten Iteration durchgef hrt wer den Als zweiten Vorteil sahen wir dass die externen Kunden w hrend des Projekts eingebunden werden und den Fortschritt verfolgen k nnen Die Pilotkunden sind durch diesen Ablauf und die Organisation an mehreren Stellen in das Projekt eingebunden Zur Analyse der Anforderungen finden Kundengespr che statt die externen Kunden w hlen ein Angebot in der Angebotspr sentation aus bewer ten einen Prototyp und nehmen so die Spezifikation ab Dann nehmen sie die erste Ite ration ab und stehen zur Analyse von Anforderungs nderungen f r die zweite Iteration und zur Abnahme des Endprodukts zur Verf gung Begonnen hat das Studienprojekt Ende Oktober 2003 das Vorprojekt endete im De zember 2003 Das Ende der ersten Iteration war auf Mai 2004 festgelegt Ende August 2004 wurde das Projekt abgeschlossen 3 5 Durchf hrung des Projekts Nach Abschluss des Vorprojekts wird das Projekt von den Teilnehmern insbesondere vom
28. Prinzip der Test daf r geschrieben Die Spezifikation einer Komponente erfolgt also durch die Definition des Tests den sie erf llen muss Es wird nur genau so viel implementiert dass der Test durchl uft und keine Zeile mehr Kommen neue Anforderungen hinzu wird zun chst das Testprogramm erweitert das dann nat rlich nicht mehr durchl uft Danach die Klasse erg nzt bis der Test wieder durchl uft So soll vermieden werden dass mehr implementiert wird als unbedingt notwendig ist Im traditionellen Prozess ist Testen nach Abschluss der Implementierung bei Studierenden besonders unbeliebt JUnit dagegen motiviert durch schnelle Erfolgserlebnisse Aus Abbildung 3 l sst sich ablesen dass die XP Gruppe tats chlich viel getestet hat anfangs mehr als sie implementiert hat w hrend sich die UML Gruppen erst ab der zweiten Woche mit der Implementierung und dann haupts chlich in der dritten Woche mit dem Testen besch ftigt haben Nach einer gewissen Umgew hnungszeit waren auch die PraktikumsteilnehmerInnen in der Lage nach dem Test First Prinzip zu arbeiten Wir konnten beobachten dass Testen sogar Spa machen kann wenn der gr ne Balken erscheint Von der XP Gruppe wurde im Software Praktikum mehr Zeit f r das Testen als f r das Implementieren aufgewendet F r Test First von GUI Klassen ist uns allerdings keine L sung eingefallen 3 6 Kundenorientierung Starke Kundenorientierung durch direkte Integration des Kunden als akt
29. Reihe von Methoden und Techniken zur Erreichung didaktischer Ziele die f r Software Praktika besonders relevant sind Aus Platzgr nden beschr nken wir uns auf die folgenden f nf Ziele Praxisn he Motivation der Teilnehmer Motivation der Tutoren Erfolg im Umgang mit unterschiedlichen Vorkenntnissen Individualit t und Wirksamkeit der Leistungskontrolle DD Im n chsten Kapitel stellen wir das Software Praktikum an der Universit t Z rich als typisches Beispiel vor Das darauf folgende Kapitel behandelt die Methoden und Tech niken gegliedert nach den didaktischen Zielen Das Software Praktikum dient hier als Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 3 durchg ngiges Fallbeispiel um die Anwendung unmittelbar zu veranschaulichen Das letzte Kapitel diskutiert die Ergebnisse und verallgemeinert sie 2 Fallbeispiel Das Software Praktikum an der Universit t Z rich Das Software Praktikum an der Universit t Z rich kurz SoPra ist ein Pflichtprakti kum im vierten Semester des Studiums der Wirtschaftsinformatik an der Universit t Z rich Die Studierenden sollen im SoPra lernen in einem Team von 4 6 Personen ein Software Projekt von den Anforderungen bis zur Pr sentation des Produkts durchzu f hren Es nehmen je nach Jahrgang 80 160 Studierende teil aufgeteilt in drei bis vier Klassen Alle Teams bearbeiten die gleiche Aufgabe Ein Teil des ben tigten Codes wird zur Verf
30. Sicht die umfangreiche Dokumentation deren Notwendigkeit erst sp t erkannt wurde sowie die hohe Arbeitsbelastung Im Folgenden werden Lessons Learned aus der Sicht der Lehrenden auszugsweise vorgestellt e Risiken wurden grunds tzlich nicht erkannt oder untersch tzt So wurden die Einarbeitungszeiten f r unbekannte Programmiersprachen und umgebungen unterbewertet oder die M glichkeit sich ndernder Anforderungen erst gar nicht als Risiko eingestuft Bei der n chsten Durchf hrung werden daher Krisen wie Erkrankung eines Teammitglieds simuliert um die Risikowahrnehmung zu verbessern e Prototypen wurden nicht ausreichend erstellt e Erst in der letzten Iteration wurde realistisch geplant mit Aktionslisten und die Planung anschlie end auch durchgesetzt e In den Iterationen wurde jeweils nur ein Schwerpunkt bearbeitet z B in der ersten Iteration nur die Anforderungsspezifikation dagegen blieben Architektur Test usw au en vor e Unklaren Anforderungen standen die Studierenden zun chst sehr ratlos gegen ber e Der Umgang mit Projektr ckschl gen kann in Vorlesungen nicht gelehrt werden Um diese Erfahrung zu vermitteln wurde eine didaktische Kombination zwischen Vorgaben und Endscheidungsfreiheit an vielen zentralen Stellen gew hlt Dies f hrte zum einen dazu dass Notwendiges wie etwa Spezifikationen nicht aureichend ausgef hrt wurde Auf der anderen Seite wurde durch Sackgasseneffekte ein hoher Lernerfolg erziel
31. Unter XP wurde besserer Code erzeugt Ein Vergleich des Programmcodes der XP Gruppe mit dem Programmcode der anderen Gruppen ergab dass die XP Gruppe Erfahrungen mit XP 121 k rzeren leichter lesbaren und verst ndlicheren Code geschrieben hat als die anderen Gruppen Bckm04 Paararbeit und Refactoring scheinen die Lesbarkeit des Codes positiv zu beeinflussen Wir konnten durch Messungen belegen dass die XP Gruppe z B sehr viel weniger duplizierten Code als die anderen Gruppen erzeugt hat Bckm04 Duplizierter Code ist besonders problematisch weil er schlecht wartbar und bei nderungen besonders fehleranf llig ist Eine ganze Reihe der von Fowler Fowl01 vorgeschlagenen Refactorings besch ftigen sich mit der Beseitigung von dupliziertem Code Der massive Einsatz von Werkzeugen wie z B GUI Buildern f hrt zu Code der sehr geschw tzig und schwerf llig ist Er enth lt sehr viel Redundanz unn tige Kommentare und ist wenig elegant Ein typisches Problem ist dass die generierten Namen nicht durch sprechende Bezeichner ersetzt werden Anstatt mit Vererbung zu arbeiten wird bei hnlichen Klassen der Code kopiert und abgewandelt Das ist in der Wartungsphase u erst problematisch wenn alle Stellen gesucht werden m ssen an denen nderungen vorgenommen werden m ssen 3 5 Testen Die Bedeutung des Testens in der Softwareentwicklung wird bei XP besonders betont Bevor eine Komponente implementiert wird wird nach dem Test First
32. aber auch zu den Betreuern und dem Organisator f rdern Zun chst werden nach Ablauf der ersten H lfte des Fachprakti kums die Studierenden zu einem informellen Gespr ch und Erfahrungsaustausch in eine Gastst tte eingeladen Bei diesem Gespr ch in lockerer Runde ist es m glich Probleme anzusprechen und den bisherigen Verlauf zu diskutieren Insbesondere f r Studierende aus fremden Kulturkreisen stellt dieses etwas andere Zwischengespr ch einen Ge winn dar Die zweite Veranstaltung findet zum Abschluss des Fachpraktikums statt Auch hier sollen die Studierenden ihre zum Teil sehr intensiven Erfahrungen bei der Bearbeitung des Fachpraktikums schildern In einer offenen Diskussion k nnen Kritik und Lob in Anwesenheit des Professors und der Betreuer ausgesprochen werden Fehler werden gemeinsam analysiert und ausgewertet Die Veranstaltung wird mit einem gemeinsamen Abendessen abgeschlossen Beide Veranstaltungen haben sowohl bei Studierenden als auch bei Betreuern einen hohen Stellenwert und tragen dazu bei dass die beim Fachpraktikum gewonnenen Er fahrungen im Ged chtnis bleiben 5 6 Ergebnisprasentation Die Ergebnispr sentation nimmt im Fachpraktikum eine besondere Rolle ein Viele der teilnehmenden Studierenden kennen das Fachpraktikum aufgrund des Roboterwettren nens Das Besondere an dieser Veranstaltung ist dass nicht nur die Teams im Mittel punkt stehen sondern auch das Publikum Die Attraktivit t der Roboterwettrennen
33. aber bei Kollaboration geht es um weit mehr als nur um Instant Messaging Andere Plug ins wie Jazz Che03 versuchen Eclipse um Kollaborationsaspekte zu erweitern aber Jazz konzentriert sich dabei auf synchrone Kommunikationsprozesse und auf Teams die eng beieinander arbeiten Solche Plug ins sind f r die Situation an der FernUniversit t also nicht geeignet Andererseits unterst tzt CURE Haa04a Haa04b als kooperative Lernplattform der FernUniversit t bereits die synchrone und asynchrone Kooperation CURE unterst tzt gemeinsames Lernen in verteilten Teams mittels eines Standard Web Browsers und des Internets CURE basiert auf der Kombination der Raum Metapher die h ufig zur Strukturierung der Kollaboration eingesetzt wird Gre02 Pfi98 mit Ideen aus Web basierten Arbeitsbereichen Wiki Leu01 und Kommunikations und Koordinationswerkzeugen Zu den Werkzeugen z hlen ein E Mail System Dokumentenverwaltung und ein Kalender mit Terminfindungsfunktionen Studierende http eimp sourceforge net d http pepemax jabberstudio org 84 Philipp Bouillon Jens Krinke Stephan Lukosch der FernUniversit t sind bereits an dieses System gew hnt so dass sich eine Einbindung in unsere neue Plattform fiir Softwaretechnik Projekte anbietet Jedes Softwaretechnik Projekt das im Rahmen der Fernlehre durchgef hrt wird muss als verteilte Softwareentwicklung engl DSE Distributed Software Engineering betrachtet werden DSE wird bereits v
34. alle Entwicklungsphasen von der Anforderungsermittlung bis zur Pilotanwendung Teams f nf Personen entwickeln die gleiche Web basierte Applikation Der Entwicklungsprozess angelehnt an Spiralmodell und RUP gibt die Iterationen und Hauptmeilensteine mit Ergebnissen und Terminen vor l sst den Teams jedoch viel Freiheit Ausgangspunkt sind bewusst unklare Anforderungen Das Entwicklungsende etwa initial operational capability ist festgelegt auf zwei Wochen vor Vorlesungsende und wird gefolgt von dem Piloteinsatz In Workshops werden von den Teams die Details f r T tigkeiten und Entwicklungsdokumente erarbeitet z B der Inhalt einer Architekturspezifikation Die Teams k nnen Umwege einschlagen Durch Statusberichte und Projektreviews vor allen Praktikumsteilnehmern sowie Team internen Gespr chen mit den Betreuern wird das Vorgehen diskutiert reflektiert und notfalls von diesen korrigierend eingegriffen Im SS2004 schlossen vier Teams ihre Aufgabe ein Werkzeug zur Vorlesungs evaluierung zu realisieren mit einer erfolgreichen Pilotanwendung ab Es gab jedoch erhebliche Funktions und Qualit tsunterschiede 148 Peter Kaiser Sven Klaus 2 Die Erfahrungen Die Studierenden bewerteten den Lernerfolg des Praktikum als sehr hoch Sie lobten die spannende praxisnahe Aufgabe die intensive Betreuung sowie den Lerneffekt bzgl des Nutzens von guter Planung und gutem Software Engineering Negativpunkte waren aus ihrer
35. auf der Hand es wird jedoch erst dann wirksam wenn es w hrend des Praktikums mehrfach genau in den Lektionen in denen erfahrungsgem Probleme auftauchen sowohl Teil nehmern als auch Tutoren gesagt wird Eine interessante Beobachtung war dass Teammitglieder einerseits die Trittbrettfah rer fast nie auffliegen lassen andererseits jedoch dankbar sind wenn Tutoren und Kurs leitung ihre Aufgabe wahrnehmen solche Probleme zu vermeiden oder gegebenenfalls die betreffenden Personen zu identifizieren und fair zu handhaben Differenzierung innerhalb der Teamleistung Mit Hilfe der bislang beschriebenen Methoden kann eine faire Beurteilung erfolgen ob Teilnehmer den Kurs bestanden haben Um differenzierte Noten zu vergeben verwendet Forbrig1997 eine Teamnote mit Auf und Abschl gen je nach messbaren individuellen Leistungen Dort wird auch auf Erfahrungen anderer mit verschiedensten Teambenotungsstrategien verwiesen Plagiate vermeiden geht vor bestrafen Dem Kopieren von Code kann durch meh rere Ma nahmen entgegnet werden Wettkampfgeist hilft gegen Kopien unter den Teams Der entstehende Geheimhaltungseffekt ist so stark dass im SoPra bei einem angeordneten wechselseitigen Code Review der Teams alle sorgf ltig darauf achteten den zu reviewenden Code so auszuw hlen dass keine f r den Sieg entscheidenden Produktmerkmale von der anderen Gruppe einzusehen waren Die Reviews an sich konnten zum Gl ck ohne Beeintr chtigung konstruktiv dur
36. dem Prinzip Lernen near the job Dementspre chend anspruchsvoll sind die Projektthemen Projekte werden von Medientechnik und Mediendesign Studenten gemeinsam durchgef hrt An einem Projekt nehmen ca zehn 152 Hans Georg Hopf Personen teil In der p dagogischen Arbeit mit den Projektteilnehmern kommen unter weitgehender Orientierung am Prinzip des selbstgesteuerten Lernens verschiedene Me thoden zur Anwendung Methodenmix Selbstgesteuertes Lernen wird als einheitlicher Sammelbegriff f r unterschiedliche konzeptionelle Ans tze verwendet Die Gemein samkeit dieser Ans tze besteht darin dass der lernende Mensch Initiator und Organisa tor seiner eigenen Lernprozesse ist Orientierung am individuellen Lernbedarf und indi vidualisiertes Lernen bieten M glichkeiten f r ein nachhaltiges und effektives Lernen CG 04 E Learning Anteile k nnen auch hier genutzt werden um Wissen verf gbar zu machen bzw Wissen zu vertiefen Mit der Projektarbeit wird individuelles Lernen mit Lernen im Team kombiniert Individuell wird jedes Team Mitglied sich seiner ber nommenen Aufgabe stellen und sich Wissen Kenntnisse F higkeiten und Fertigkeiten auf seinem Spezialgebiet aneignen Selbstlernen In besonderen Problemsituationen kann im Team diskutiert und auf den Erfahrungshintergrund der anderen Team Mitglieder zur ckgegriffen werden Teamlernen Lernen und Arbeiten verschmelzen zu einem Prozess In dieser Kombination verl uft der Wissense
37. der aktuellen Preise und der Preisentwicklung sowie das Erstellen der Rechnungen f r die G ste unterst tzen Die erste Lektion beinhaltete Teamfindung und das erste Kundengespr ch Nach Anforde rungsspezifikation Oberfl chenprototyp erneuten Kundengespr chen Modellierung Architektur und Detailentwurf Reviews Programmieren und Test endete das Prakti kum mit der Wettkampfpr sentation aller Teams vor dem Kunden Der Aufwand des Praktikumsleiters betrug 1 3 Personenmonate f r die Durchf h rung und 2 Personenmonate f r die Weiterentwicklung der didaktischen Methoden und der Unterlagen des Praktikums Seit der erstmaligen Durchf hrung des SoPra im Jahr 1996 sind mehr als ein Personenjahr Aufwand in die Entwicklung von Unterlagen Aufgaben dem minuti sen Praktikumsdrehbuch und zur Verf gung gestelltem Code geflossen Ryser1999 4 Robert Stoyan Martin Glinz Wir haben fast alle der nachstehend beschriebenen Methoden und Techniken im SoPra 2004 selbst mit Erfolg eingesetzt Das Praktikum hat in dieser Form die beste Bewertung durch die Studierenden seit seinem Bestehen erhalten 3 Methoden und Techniken 3 1 Didaktisches Ziel Praxisnahe Praxisn he ist ein klassisches Ziel der Ausbildung im Software Engineering Software Praktika bieten hierzu viele methodische M glichkeiten Echte Kunden echte Anwendung Die authentischste Praxisn he gibt die Praxis selber was jedoch nicht funktioniert ist die Verbindung eines
38. ergreifen oder zum Nach arbeiten fehlender Vorkenntnisse zu motivieren Druck Gleich in der ersten Stunde einen konstruktiven Druck aufbauen e Das erwartete Niveau an Vorkenntnissen objektiv beschreiben Sie m ssen selbst st ndig eine einfache Programmieraufgabe l sen k nnen z B e Eine grobe aber quantifizierte Sch tzung geben wie viel Zeit die Teilnehmer bei unterschiedlichen Vorkenntnissen f r die Lehrveranstaltung einplanen m ssen sehr grob ca ein Tag plus Pr senzzeit wenn Vorkenntnisse erf llt ansonsten e Zeigen wie die personenbezogene Ergebniskontrolle erfolgt und was die Konse quenzen sind Beispiel Projektplan mit Namen wer was macht Der Tutor wird zu den Abgaben Fragen an einzelne Personen stellen Hinweisen auf die soziale Kon trolle durch das Team ob man diesem zur Last fallen will e Benennen was Teilnehmer tun m ssen die im Kurs verbleiben wollen aber die Vorkenntnisse nicht erf llen Folgendes Java Buch nehmen und inklusive der dor tigen bungen bis Kapitel durcharbeiten hierf r mindestens Zeit einplanen Eine derma en akkurate Ansage ist eher ungew hnlich und l st bei den Studierenden ein sp rbares Erwachen aus Es ist die faire Information die sie brauchen um Tenden zen zur Aufwandsminimierung zu berwinden und ihre erfolgreiche Teilnahme verant wortlich planen zu k nnen Nur wenn der Hinweis zu Beginn erfolgt besteht noch real die Chance dass
39. f r alle Teammitglieder und den Betreuer erh ht da CodeBeamer alle zuletzt bearbeiteten Tasks anzeigen kann Neben CodeBeamer gibt es auch noch andere Plug ins die sich z B zum Ziel gesetzt haben Bugzilla in Eclipse zu integrieren Phase 3 Entwurf Es gibt bereits eine Reihe von UML Entwurfswerkzeugen aber keines der verf gbaren Open Source Werkzeuge erlaubt das gemeinsame Modellieren ber das Internet In dieser Hinsicht w re zumindest eine grafische Diff Sicht sinnvoll die dem Benutzer direkt anzeigt welche Ver nderungen seit dem letzten Zugriff vorgenommen wurden zum Beispiel indem ver nderte hinzugef gte oder entfernte Elemente grafisch hervorgehoben werden Des Weiteren sind die meisten UML Werkzeuge nur schwer in ein Softwaretechnik Praktikum zu integrieren da sie entweder zu schwer zu bedienen sind oder nicht genug Funktionalit t besitzen F r unsere Zwecke am besten geeignet sind Together und MagicDraw Andere Werkzeuge sind entweder noch nicht mit Eclipse integrierbar oder haben Stabilit tsprobleme Ein vielversprechendes Projekt namens GroupUML Bou04 wird derzeit an der TU M nchen entwickelt Dabei handelt es sich um ein Werkzeug mit dem mehrere Benut zer gleichzeitig halb formale UML Diagramme erstellen k nnen Zum einen ist es m g lich komplette UML Diagramme zu zeichnen auf der anderen Seite k nnen aber auch http www borland com together eclipse gt http www nomagic com Eine Pla
40. hren Wir werden JRefleX noch evaluieren und es dann in unsere Plattform integrieren 4 Erfahrungen und Ausblick Bei der Analyse der verschiedenen Plug ins haben wir festgestellt dass die meisten Plug ins gute L sungen f r eine einzelne spezifische Problemstellung bieten In unserer Situation reicht es jedoch nicht aus dass eine Unterst tzung in Eclipse existiert Stattdessen brauchen wir eine L sung in der die einzelnen Plug ins enger miteinander zusammenarbeiten So gibt es zwar einige Instant Messaging Plug ins f r Eclipse aber sie sind untereinander nicht austauschbar da sie f r diesen Zweck auf einem Frame work wie Koi basieren m ssten hnliches gilt f r Kollaborations und Projektmanagement Werkzeuge Jede L sung implementiert ihre eigenen Diskussionsforen Kalender Dokumentmanager usw Aber es ist unm glich diese mit anderen Foren oder Kalendern zu integrieren Das f hrt zu einer Situation in der unsere Softwaretechnik Plattform mindestens vier Diskussionsforen anbietet 1 Klassische Newsgroups 2 ein Diskussionsforum in der allgemeinen Lehrplattform 3 die Mail und Chat L sung in CURE und 4 die Diskussionsforen innerhalb von CodeBeamer Das verwirrt nat rlich und muss deshalb von einer allgemeineren integrierten L sung abgel st werden CURE wurde bereits einmal alleine und wird gerade ein weiteres Mal in Verbin dung mit CodeBeamer f r die Unterst tzung von Studierenden in Softwaretechnik Prak
41. ihre Motivation bei der Durchf hrung des Praktikums im Vergleich zu anderen Lehrveranstaltungen des Studiums als h her Die ser Meinung waren 35 Studenten 9 bewerteten ihre Motivation als gleich hoch 6 Stu denten als niedriger Fast alle Studenten n mlich 49 von 50 hatten das Gef hl dass im Softwarepraktikum ein Lerneffekt eingetreten ist Als besonders positiver Aspekt des Softwarepraktikums wurde von den Studenten hervorgehoben dass im Praktikum eine eigenst ndige Teamarbeit unter realen praxis nahen Projektbedingungen durchgef hrt werden konnte Negativ wurden die nach Mei nung der Studenten veraltete Rechner und Softwareausstattung und Terminkonflikte mit anderen Lehrveranstaltungen eingesch tzt Ebenfalls negativ wurden die Aspekte versp tete Absprachen ber Schnittstellen ungenaue Anforderungen des Kunden an die Software und Unstimmigkeiten innerhalb der Gruppen und zwischen den Teams bewertet Dabei ist jedoch festzustellen dass dies Schwierigkeiten sind unter denen viele Softwareprojekte in der Industrie ebenfalls leiden und somit die Studierenden in gewisser Weise auf die Probleme die sie in ihrem sp teren Berufsleben unter Umst nden erwarten vorbereitet werden Der Umfang des Praktikums war nach Einsch tzung von 32 Studierenden genau richtig 16 Studierende empfanden den Aufwand als leicht zu hoch Dies zeigt dass der Umfang der Aufgabe f r das Softwarepraktikum richtig gew hlt worden war und zu k nftige Aufga
42. im Be Projekte der Lehre mit hochschulexternen Kunden 139 reich Klassenmodellierung bei den Betreuern erforderlich Wie zu erwarten war hatten sich einige Gruppen aufgel st durch Schwund der Mitglieder oder neu formiert Durch die festen Schnittstellen hat sich dies aber auf die brigen Gruppen nicht weiter ausgewirkt So konnte jede Gruppe ihre Abgabe mit den jeweils anderen Komponenten integrieren 3 Studienprojekt im Hauptstudium Im Hauptstudium des Studiengangs Softwaretechnik sind zwei Studienprojekte vorge sehen in denen von Studenten jeweils ein vollst ndiges Softwareprojekt durchgef hrt wird Das Studienprojekt A ist das erste Projekt und wird von den Informatik Instituten angeboten das Studienprojekt B wird im Anwendungsfach absolviert Wir haben im Wintersemester 2003 04 ein Studienprojekt A mit externen Kunden angeboten und durchgef hrt 3 1 Rahmenbedingungen Die Rahmenbedingungen f r das Studienprojekt A werden durch die Pr fungsordnung festgelegt Die Teilnehmerzahl ist auf 7 bis 12 Teilnehmer begrenzt der Umfang f r die praktische Arbeit ist auf 10 Semesterwochenstunden je Teilnehmer festgelegt das sind 400 Entwicklerstunden Die vorgegebene Dauer betr gt 9 Monate Im praktischen Teil sollen die Teilnehmer ein vollst ndiges Softwareprojekt durchf hren Dazu geh ren die Phasen Konzeption Analyse Spezifikation Realisierung Entwurf Feinentwurf Co dierung Modul Test und Montage Integration Gesamttest
43. mit st ndig wechselnden Partnern das Lernen voneinander Als Konsequenz davon dass durch so genannte Stories beschriebene Funktionalit t realisiert wird wobei viele Klassen des Systems ver ndert werden m ssen und alle EntwicklerInnen abwechselnd an allen Programmteilen arbeiten geh rt der gesamte Code im XP Projekt allen EntwicklerInnen die ihn nicht nur lesen sondern auch ndern d rfen XP wird wegen dieses Konzepts und wegen der besonderen Bedeutung der direkten Kommunikation in erster Linie f r kleinere Projekte mit etwa 10 EntwicklerInnen empfohlen Beck00 Die Paararbeit hat sowohl auf der Informatica Feminale als auch im Software Praktikum wie auch bei Lippert LRWZOI1 gut geklappt obwohl einige m nnliche Studierende anfangs Vorbehalte u erten Auf der Informatica Feminale konnten wir beobachten dass ein Team das in Paararbeit arbeitet problemlos neue Mitglieder integrieren kann Unser XP Projektteam setzte sich t glich etwas anders zusammen Das Ausscheiden eines Mitglieds konnte leicht verkraftet werden da es keine ausgepr gten Spezialisten gab 1 Woche 2 Woche 3 Woche 80 8 60 6 EE Allein 40 4 C1 zu zweit Proze 20 2 E Zu aritt satz der Arbeits Im ganzen F Team zeit 0 0 XP Gr andere Gr XP Gr andere Gr XP Gr andere Gr Abb 1 Paararbeit versus Einzelarbeit Abbildung 1 zeigt als ein Ergebnis der Sopra Befragung dass die XP Gruppe berwiegend in Paararbeit gearbeitet hat w hrend die anderen Gru
44. ndern Die Ergebnisse der Anforderungsanalyse werden in einem Pflichtenheft festgehalten das vom Kunden akzeptiert werden muss Neben dem Pflichtenheft wird von den Studie renden auch die Abgabe eines realistischen Preisangebots f r das zu entwickelnde Sys tem verlangt Die Studierenden werden dadurch angehalten auch die wirtschaftlichen Aspekte zu ber cksichtigen und das Rollenspiel Firma Kunde wird belebt Begleitet wird das Fachpraktikum durch regelm ig stattfindende Seminare in de nen wichtige Hintergrundinformationen und theoretische Grundlagen vermittelt wer den Die Seminare werden von den wissenschaftlichen Mitarbeitern des Instituts ab gehalten und haben jeweils einen konkreten Aspekt der Softwaretechnik zum Thema der in unmittelbarem Zusammenhang mit anstehenden Aufgaben steht Aus organisato rischer Sicht stellen die Seminare die Rahmenveranstaltungen des Fachpraktikums dar die auch zur regelm igen Steuerung und berwachung des Praktikumsverlaufs dienen Den Studierenden wird im Rahmen der Seminare die M glichkeit gegeben Fragen zu stellen und unklare Punkte zu diskutieren Im Anschluss an ein Seminar werden den Studierenden Teilaufgaben gestellt Zweck dieser Teilaufgaben ist es den Studierenden einen groben zeitlichen Rahmen zur Durchf hrung wesentlicher Arbeitsschritte sowie eine Unterst tzung in der Aufteilung von Aufgaben im Team zu geben Der H hepunkt des Fachpraktikums ist ein Roboterwettrennen siehe Ab
45. nnen Zus tzlich wird an der FernUniversit t CodeBeamer dazu eingesetzt die Studieren den w hrend der Implementierungsphase zu unterst tzen Mit Hilfe der Tracker die in CodeBeamer zur Verf gung stehen k nnen sich die Studierenden einen berblick ber die aktuellen Aufgaben verschaffen und auch gegenseitig die Bugs aus den Programm teilen entfernen Mit Hilfe der automatischen Testfunktion von CodeBeamer ist es m glich das gesamte Projekt ber Nacht testen zu lassen Am n chsten Morgen werden dann die Tasks automatisch aktualisiert so dass jedes Teammitglied einen messbaren Fortschritt des Projekts erkennen kann Des Weiteren gibt es noch eine grafische Visua lisierung der Testergebnisse so dass sich jeder Studierende schnell einen berblick ber Probleme verschaffen kann Zur Verbesserung der Implementierungsphase sollen noch externe Werkzeuge wie JML eine Spezifikationssprache f r Java zur Verf gung gestellt werden Wir werden auch noch die Effekte von Code Checking Plug ins wie CheckStyle oder PMD sowie von Debug Hilfen wie DeltaDebugging Bou03 oder anderen Werkzeugen evaluieren Gefundene Bugs werden nat rlich im Bug Tracker von CodeBeamer verwaltet Phase 5 Abgabe und Benotung Wenn die Studierenden am Ende ihres Praktikums ihre Software zusammen mit den geforderten Dokumenten abgegeben haben ist es die Aufgabe der Betreuer die Studie renden zu beurteilen und zu benoten Es gibt verschiedene Kriterien zur Leistung
46. predictions and the analysis increases with the levels of PSP in seven steps ranging from PSPO to PSP3 In this way the student is expected to gain more understanding of his her own process to detect those phases of the process that are most time consuming or failure prone and hence to be able to improve his her personal process where it is most needed During the course the student also produces five reports that define standards to guide his her work and analyze the process The exercises process levels and reports in PSP are shown in Table 1 Table 1 Exercises process levels and reports in PSP Hum95 Exercise Process Report 1 Standard deviation PSPO 2 LOC counter PSPO 1 R1 LOC counting standard R2 Coding standard 3 LOC and object counter PSPO 1 R3 Defect analysis report 4 Linear regression PSP1 5 Numerical integration PSP1 1 6 Prediction interval PSP1 1 R4 Midterm report 7 Correlation PSP2 8 Sorting PSP2 1 9 Chi squared test PSP2 1 10 Multiple regression PSP3 R5 Final report Using Personal Software Process exercises to teach process measurement 107 The programs developed in the exercises are small statistical routines that can be used for analyzing the measurement data The students may use any programming language that they are familiar with They are advised to develop the software using their usual development process extended with the measurements required in ea
47. programmer has learned to make use of the tools Hum95 p 19 Students have reported frustration on the amount of bookkeeping Pre01 Abr02 During the PSP course students are just learning to use the process which means we should expect their productivity to decrease while they are adding new process elements to their work Surprisingly many sources report a basically unchanging average productivity over PSP courses Hay97 PreO1 Abr02 We formulated the following hypotheses of the expected results of our PSP course H1 Over the PSP course defect density decreases H2 The most important defect removal phase changes during the course In the beginning most defects are removed in compile Later on testing and reviews will account for removing the most defects H3 Over the course both size and effort prediction accuracy will increase H4 Despite the process changes productivity will stay roughly the same We analyzed the coursework reports of 36 students from our three first PSP courses 1999 2001 The data collected by students was of poor quality as has also been noted elsewhere Joh98 Before analyzing the data we manually corrected many obvious errors in the reports Using Personal Software Process exercises to teach process measurement 109 As expected in hypothesis H1 defect density decreased over the course We calculated the density in defects per KLoC Figure 1 Median defect density decreased constantly Strong decreas
48. r dieses Lernziel ein Teachlet entwerfen Die neuen Teachlets werden an den Teilnehmern der Werkstatt selbst ausprobiert und anschlie fend von den Teilnehmern analysiert und bewertet Eine Teachlet Werkstatt ist also deutlich gegen ber einer fiktiven Lehrveranstaltung beispielsweise zu Entwurfsmustern abgegrenzt in der der Dozent ausschlie lich mit bew hrten Teachlets arbeitet Der bereits hohe interaktive Anteil einer Teachlet Veranstaltung wird somit in einer Teachlet Werkstatt weiter gesteigert 5 1 Erstmalige Durchf hrung Die in Abschnitt 2 dargestellte Definition f r Teachlets wurde den Teilnehmern in der Einf hrungsveranstaltung vorgestellt An den folgenden beiden Terminen f hrte der Veranstalter zwei Teachlets selbst durch um das Konzept zu verdeutlichen Zu den restlichen Terminen f hrten die Teilnehmer nur noch Teachlets durch die sie selbst ausgearbeitet hatten Bei der Vorbereitung wurden sie hnlich intensiv betreut wie es in klassischen Seminaren oft der Fall ist Mindestens zwei Wochen vor dem Termin muss te dem Veranstalter ein Grobkonzept vorgestellt werden sp testens eine Woche vorher mussten alle statischen Teile des Teachlets pr sentiert werden Alle Moderationen wurden allein durchgef hrt Nach jeder Teachlet Einheit gab es intensives Feedback auf den unterschiedlichen Ebenen zum Lernziel selbst zum Teachlet sowie zur Moderation Sowohl die Teilnehmer selbst als auch der Veranstalter haben jeweils Feedba
49. und Entwurf OOD die UML Notation verwendet wird Die objektorientierte Implementierung OOP erfolgt wahlweise in den Programmiersprachen C oder Java Die Entscheidung ber die ein gesetzte Sprache wird den Teams berlassen Das Softwaresystem muss nicht komplett neu entwickelt werden Wie in den meis ten realen Softwareprojekten in der Industrie werden zum Teil vorgefertigte Software komponenten wiederverwendet Diese Softwarekomponenten sind zum Teil leicht feh lerbehaftet und nicht optimal dokumentiert Die Studierenden lernen mit derartigen Schwierigkeiten die nicht selten in realen Softwareentwicklungsprojekten auftreten umzugehen Gleichzeitig wird ihnen damit der Nutzen einer guten Projektdokumentati on vermittelt 4 4 Qualitatssicherung Um die Erf llung der vorgegebenen Anforderungen zu gew hrleisten werden Quali t tssicherungsma nahmen angewandt Softwarequalit t wird durch den Einsatz kon struktiver Qualit tssicherungsma nahmen erreicht wie z B die Gliederung des Ent wicklungsprozesses durch ein Vorgehensmodell sowie die Unterst tzung des Entwick lungsprozesses durch Methoden und Werkzeuge Diese Ma nahmen werden durch analytische Qualit tssicherungsma nahmen wie z B Reviews sowie Komponenten und Systempr fungen erg nzt vgl LaG 99 S 34 f Beide Arten von Ma nahmen sind Bestandteil der Ausbildung im Fachpraktikum Softwaretechnik F r die Komponenten und Systempr fung werden aus den Anforde
50. und Termin und Teamprobleme meist selbstst ndig erkannt und gel st werden Im Hinblick auf die Teilung des Angebots in interne und externe Projekte fassen wir zusammen e Unter direkter Anleitung und strikter Kontrolle durchgef hrte Projekte eig nen sich f r unerfahrene Entwickler d h f r die Mehrzahl der Studenten im Grundstudium Softwaretechnologie Praktikum im Grundstudium 133 e Reale st rker selbstverantwortliche Projekte im betrieblichen Umfeld stellen fiir die Gruppe der Studenten mit besserem softwaretechnischen Hintergrund eine interessante Herausforderung dar e Externe Projekte sind f r den Lehrstuhl in Vorbereitung und Durchf hrung aufw ndiger als interne Projekte e Die vorgesehene Semesterwochenstundenzahl wird k nftig von zwei auf vier SWS erh ht um dem Arbeitsaufwand und der Stellung des internen als auch des externen Praktikums besser gerecht zu werden Beide Konzepte lassen sich im Grundstudium erfolgreich durchf hren sofern geeignete Randbedingungen hergestellt werden Mit dem Angebot beider Alternativen k nnen wir auf die unterschiedlichen Interessen und Begabungen verschiedener Praktikumsteil nehmer eingehen Literatur Dem 99 B Demuth H Hu mann S Zschaler L Schmitz Erfahrungen mit einem frameworkbasierten Softwarepraktikum In SEU 99 iko 04 TU Braunschweig Institut f r Psychologie Initiative f r Kommunikation in der Softwarebranche ikoso http www ikoso de SEU 99 SEU
51. von den Studenten erkannt wird kann der Lerneffekt sogar h her ausfal len als im externen Praktikum wo durch den h heren Erfolgsdruck schnell gewohnte Vorgehensweisen bei der Programmierung adaptiert und dabei die Ziele eines sauberen Softwareentwurfs nicht verinnerlicht werden Eine Anforderung an die Studierenden aus dem letzten Praktikumszyklus die sich auch nach studentischen Aussagen sehr bew hrt hat ist dass jedes Teammitglied in der Entwurfsphase einen eigenen kleinen Prototypen schreiben muss Eine weitere wichtige Erfahrung bei der Durchf hrung des Praktikums sowohl f r universit re als auch f r reale Projekte ist die Durchsetzung eines festen Endtermins Im internen Praktikum kommt noch die konsequente terminliche Einhaltung von Mei lensteinen dazu Die teilweise geringe Motivation bzw fehlende softwaretechnische programmiertechnische und auch soziale Kompetenz der Studenten in den universit ren Projekten f hrt h ufig zu einer legeren oder sogar ablehnenden Haltung gegen ber dem Praktikum Dem ist durch den drohenden Ausschluss aus dem Praktikum von einzelnen Teammitgliedern oder eines gesamten Teams entgegenzuwirken Damit wird auch die Position der Betreuer gegen ber den Gruppen gest rkt und so die Durchsetzung soft waretechnischer Anforderungen gew hrleistet Im externen Praktikum ist die Aus bung von Druck auf die Studenten nicht oder kaum n tig da hier qualitativ hochwertige Ergebnisse aus eigenem Antrieb entstehen
52. wird Softwaretechnik live im Praktikum zur Projekterfahrung 53 f r die Zuschauer noch durch ein Wettb ro erh ht Die Zuschauer k nnen nachdem sich die Teams pr sentiert haben Tipps f r den Ausgang der Rennen abgegeben und kleine Sachpreise gewinnen F r Zuschauer aus aller Welt findet eine Live bertragung im WWW statt die auch live kommentiert wird Insbesondere f r Bekannte und Ange h rige ausl ndischer Studierender ist dies eine gute M glichkeit die Rennen zu verfol gen Die Studierenden wollen sich nat rlich vor den Zuschauern gut pr sentieren und sind besonders motiviert ein gutes und zuverl ssiges Softwareprodukt zu entwickeln Das Rennen wird mit einer Siegerehrung durch den Professor abgeschlossen 6 Wertvolle Erfahrungen Die Studierenden beurteilen die gewonnenen Erfahrungen in der Regel sehr positiv wie es die Ergebnisse der regelm ig durchgef hrten Umfragen zeigen oder Zeichen der Anerkennung der Art wie esin Abb 3 zu sehen ist Sa w gt on G Die Gruppe Robo2000 bedankt sich herzlich bei Prof Dr Ing P G hner und den Betreuern des Institutes f r Automatisierungs und Softwaretechnik Klaus Konrad Adam Moik Pablo Darscht und Michael Gunzert Die Organisation des Praktikums war hervorragend Es hat uns sehr viel Spa gemacht und wir hoffen daB es dem Institut auch weiterhin gelingt Ideen so gut umzusetzen Abb 3 Der Nutzen des Fachpraktikums wird von den Studierende
53. 4 15 14 turn right 8 15 move 8 11 Abb 2 Ein sehr einfacher Bug sucht erst Futter und dann sein Nest 74 Christian Lindig und Andreas Zeller Visualizer Formicidae Abb 3 736 100000 bogus 3 beetle 4 m gt m Simulator mit schwarzen und roten Bugs Futter und zwei Nestern Die Studierenden miissen einen solchen Simulator und einen erfolgreichen Schwarm entwickeln Die Aufgabe vereinigt Aspekte die unterschiedliche Kenntnisse und Talen te in einer Gruppe ansprechen Der Simulator ist eine klassische Aufgabe fiir einen objektorientierten Ent wurf GR83 DM91 Er l sst sich pr zise spezifizieren und validieren was ihn f r ein Praktikum gut geeignet macht Die Entwicklung der Strategie und ihre Kodierung als endlicher Automat hingegen bieten Raum f r Originalit t Die endlichen Automaten f r das Verhalten werden in einer maschinennahen Sprache formuliert In einem Turnier am Ende des Praktikums stehen die Gruppen im sportlichen Wettstreit um die besten Schwarm Strategien Dies stachelt Studenten zu Spitzenleistungen an und verhindert den allzu freien Austausch von Ideen und Code H95 Um eine gute Strategie zu entwickeln ben tigt man Werkzeuge zun chst einen korrekten und leistungsf higen Simulator was Testbarkeit und Quali t tssicherung motiviert Dar ber hinaus lassen sich intelligente Bugs leichter Ein Software Praktikum als Sommerkurs 75 in einer selbst entworfenen Hoch oder As
54. Abb 3 Schichtenarchitektur von Sysiphus UML Komponentendiagramm Die Kommunikations und Speicherschicht beinhaltet den ElementStore und das Pro jectDirectory Der ElementStore ist f r die Speicherung der Systemmodell und Kom munikationsdaten und f r die Kommunikationsinfrastruktur von Sysiphus verantwort lich Zur Authentifizierung von Benutzern und der Zuweisung von Benutzerrechten wird das ProjektDirectory verwendet In der Modellschicht sind die SWE Modelle und deren Beziehungen realisiert Dies sind unter anderem UML Elemente z B Anwen dungsf lle Klassen Komponenten Testf lle Elemente zur Modellierung von Doku menten und Modelle zur Kommunikation und Begr ndungserfassung Das Modell der Begr ndungserfassung basiert auf QOC Question Option Criteria Mec 99 Die Anwendungsschicht beinhaltet die Benutzeranwendungen REQuest RAT und die Lec tureAdmin Komponente Die Anwendungen basieren auf der Modellschicht welche eine Ortstransparenz der verteilten Architektur von Sysiphus realisiert Zus tzlich ha ben wir folgende Anforderungen an das System gestellt 1 Die Modellschicht und die Client Anwendungen sollen bei laufendem Server ver nderbar und austauschbar sein und 2 der Server soll parallel mit verschiedenen Versionen der Modellschicht und verschiedenen Versionen der Client Anwendungen arbeiten k nnen Durch die Realisierung dieser Anforderungen k nnen verschiedene Gruppen die gleichen oder unterschiedliche nderungen
55. Anforderungs nderungen nach der ersten Iteration Die Studenten hatten eine abweh rende Haltung gegen ber den nderungen eine konstruktive Diskussion wurde abge blockt indem auf den Mehraufwand verwiesen wurde Deutlich hat sich in der Analyse gezeigt dass ein externer Kunde nicht die Sprache der Entwickler spricht Dadurch tauchten nach der Analyserunde weitere Fragen auf die in einem zweiten Treffen gekl rt wurden W hrend die Erfahrung bei der Analyse gewollt ist sehen wir in den Schwierigkei ten der Angebotspr sentation ein Defizit der Lehre Nachgereicht wurde daher ein U berblick ber den typischen Ablauf der Angebotsphase in der Industrie und Hinweise zur erfolgreichen Angebotspr sentation Diese Inhalte werden wir in die begleitenden Vorlesungen f r kommende Studienprojekte einflie en lassen um die Studenten besser auf die Kundenkontakte vorzubereiten Au erdem wurden alle Projektergebnisse die die externen Kunden bekommen vorher vom internen Kunden und den Betreuern ge pr ft 144 Tilmann Hampp Stefan Opferkuch Rainer Schmidberger Das iterative Vorgehen sch tzen wir grunds tzlich positiv ein F r die Kunden hat es den Vorteil dass noch nderungen in das Endprodukt bernommen werden k nnen dass sie relativ fr h wieder in das Projekt eingebunden werden und dass sie eine lauff hige Version sehen Aber auch f r die Studenten ist eine lauff hige Version die den Kunden vorgestellt werden kann motivierend D
56. Computer Science J UCS www jucs org 8 6 44 54 Teamtraining fur Software Ingenieure Andreas Fleischmann Katharina Spies Institut f r Informatik Technische Universit t M nchen BoltzmannstraBe 3 85748 Garching b M nchen fleischa spiesk in tum de Katharina Neumeyer Institut fur Psychologie Technische Universitat Darmstadt HochschulstraBe 1 64289 Darmstadt training neumeyer kroeger de Zusammenfassung Die Notwendigkeit fiir die Ausbildung in Software Engineering passende Unter richtsformen zu entwickeln die es den Studierenden erm glichen praktische Er Jahrungen zu sammeln ist eine mittlerweile anerkannte Herausforderung bei der aktuellen Konzeption der Lehre von Software Engineering an der Hochschule Um den Studierenden solche Erfahrungen mitzugeben werden an vielen Hochschulen Projekte durchgef hrt in denen studentische Teams weitgehend selbstst ndig einen Software Engineering Prozess durchleben Aufgrund unserer Erfahrungen bei der Durchf hrung solcher Projekte an den TU s Darm stadt und M nchen ist festzustellen dass die gr ten Herausforderungen f r die beteiligten Studierenden dabei weniger in der Bew ltigung technischer oder fachlicher Fragestellungen liegen Diese Problematik ist ihnen aufgrund ihrer Lernerfahrung im Studienverlauf bereits gel ufig Vielmehr stellt der Umgang mit organisatorischen und sozialen Problemen eine viel gr ere Herausforde rung dar und f hrt daher oft zu f r die St
57. Darmstadt und M nchen hat gezeigt dass die gr ten Herausforderungen f r die beteiligten Studierenden dabei in der Bew ltigung organisatorischer sozialer Probleme liegen Die Ursache hierf r sollte darin zu finden sein dass einerseits das ben tigte Informatik Fachwissen in den Vorlesungen bereits hinreichend gut vermittelt wurde und anderer seits darin dass es den Studierenden aufgrund ihrer eigenen Lernerfahrung deutlich leichter f llt fachliche Defizite zu berwinden Aus unserer Einsicht heraus dass Studierende fr herer Projekte im R ckblick die sozialen und organisatorischen Probleme oft als entscheidend empfanden und w hrend des Projekts wenig Zeit und Bereitschaft besteht auf dieses unbequeme Thema in Ruhe einzugehen wurde an der TU M nchen ein Teamtraining konzipiert das die Studierenden vor Beginn des Projekts absolvieren und das sie auf die Zusammenarbeit 28 Andreas Fleischmann Katharina Spies Katharina Neumeyer im Projekt Team vorbereitet Damit werden die Studierenden bereits vor dem Start des fachlichen Projekts ohne Termindruck auf den Umgang mit den mit Sicherheit auf tretenden organisatorischen und sozialen Problemen vorbereitet und es werden ihnen Wissen und Techniken f r den Umgang und die Bew ltigung dieser Probleme an die Hand gegeben Im vorliegenden Artikel skizzieren wir zun chst kurz den organisatorischen und inhalt lichen Rahmen eines vor kurzem abgeschlossenen Softwaretechnik Praktikums
58. Diagramme Klassen und Sequenzdiagramme eingesetzt wenn wir gemerkt haben dass Abl ufe und Zusammenh nge nicht allen klar waren Wie weit man bei der Softwareentwicklung auf die Modellierung verzichten will und kann h ngt im Wesentlichen von der Erfahrung der EntwicklerInnen und von der Komplexit t des Problems ab Anf ngerInnen hilft ein wenig Modellierung beim Verst ndnis der Aufgabe und ihrer L sung 3 4 Codequalitat Es leuchtet ein dass der Qualit t des Codes eine besondere Bedeutung bei XP zukommt Der Code geh rt allen und muss jederzeit f r alle EntwicklerInnen verst ndlich sein Er ist bereits w hrend der Programmentwicklung einem st ndigen Wartungsprozess unterworfen Fester Bestandteil der XP Vorgehensweise ist das Refactoring die Verbesserung des existierenden Codes Es reicht nicht aus dass das Programm l uft und der erzeugte Code die Spezifikation erf llt vielmehr soll der erzeugte Code auch von hoher Qualit t sein Martin Fowler beschreibt in seinem Buch Fowl00 verschiedene Kategorien von schlecht riechendem Code und zeigt Wege wie die M ngel beseitigt werden k nnen Die Programmierausbildung an den Universit ten konzentriert sich im Wesentlichen darauf Sprachkonstrukte und ihre Anwendung vorzustellen und einzu ben Der erzeugte Code wird haupts chlich dahingehend beurteilt dass das Programm die funktionalen Anforderungen erf llt Die Qualit t des Codes bleibt weitgehend unber cksichtigt
59. Die drei Wochen Projektzeit wurden in drei Iterationen aufgeteilt Am Ende der ersten Woche existierte eine erste allerdings winzig kleine Version des Programms w hrend die anderen nur Diagramme vorzeigen konnten Die Entscheidung welche Stories sich sinnvoll in einer ersten Iteration realisieren lassen konnten die Studierenden in der XP Gruppe allerdings nicht ohne Hilfe treffen Sie hatte zu wenig Erfahrung die Konsequenzen einer Story Auswahl zu berblicken und die ben tigte Zeit daf r einzusch tzen Die UML Gruppen haben besonders zu Projektbeginn viel Zeit f r die Modellierung verwendet In den ersten beiden Wochen des Projekts wurden 42 bzw 29 Prozent der Arbeitszeit f r das Entwickeln der Diagramme aufgewendet In der letzten Woche haben sich die Gruppen fast ausschlie lich mit Implementieren und Testen besch ftigt Die XP Gruppe dagegen hat von Anfang an implementiert und getestet Der Aufwand f r die Tests war zumindest in den ersten beiden Wochen als das XP Vorgehen noch diszipliniert verfolgt wurde h her als f r die Implementierung Au erdem ist die Gefahr den berblick ber das entstehende Programmsystem zu verlieren bei XP ohne umfassendes Design relativ gro UML Diagramme k nnen durchaus helfen die Struktur des Systems und Abl ufe zu verdeutlichen W hrend wir auf der Informatica Feminale auf Wunsch der Teilnehmerinnen v llig auf UML Diagramme verzichtet haben haben wir im Software Praktikum bewusst UML
60. Experimentaufbau statistische Auswertung usw erl utert werden Die Konzeption dieser Vorlesung und Erfahrungen werden besprochen Methoden und Techniken zum Erreichen didaktischer Ziele in Software Engineering Praktika Robert Stoyan Martin Glinz Institut f r Informatik Universitat Z rich Winterthurerstr 190 CH 8057 Z rich Schweiz stoyan glinz ifi unizh ch Zusammenfassung Praktika an der Hochschule sind wirksamer Bestandteil der Software Engineering Ausbildung sie sind aber auch eine Ausbildungsform in der didak tische Herausforderungen und M glichkeiten besonders intensiv zusammentref fen Zu den didaktischen Zielen geh ren eine hohe Motivation der Studierenden und Tutoren eine wirksame und individuelle Leistungskontrolle Praxisbezug sowie ein erfolgreicher Umgang mit unterschiedlichen Vorkenntnissen Dieser Beitrag pr sentiert Methoden und Techniken um diese Ziele zu erreichen und erl utert sie anhand von Beispielen Aus diesen speziellen Ma nahmen werden Prinzipien f r den Unterricht des Software Engineering extrahiert 1 Einleitung Software Praktika in denen die Prinzipien des professionellen Software Engineering in Projektform erlernt werden sind seit l ngerem ein Standardbaustein in Informatik Curricula an Hochschulen In der SEUH Reihe wurden in der Vergangenheit mehrfach Berichte ber solche Praktika publiziert In diesem Beitrag destillieren wir aus eigenen Erfahrungen und denen anderer Autoren eine
61. Feinwerktechnik Informationstechnik eingef hrte Ingenieurstudiengang Medien technik bot die M glichkeit neu ber Innovation in der Software Engineering Ausbildung auf dem Gebiet elektronische Medien nachzudenken Der Studiengang ist eng verzahnt zum Studiengang Mediendesign konzipiert der im Fachbereich Gestal tung angesiedelt ist Das Konzept ist darauf ausgerichtet die Identit t der Disziplin Gestaltung bzw Technik zu erhalten jedoch die Sprachf higkeit durch Vermittlung der Eigenarten der jeweils anderen Disziplin herzustellen Auf diese Weise werden kompe tente Fachleute ausgebildet die sich im Team erfolgreich den Aufgaben der Praxis im Bereich elektronischer Medien stellen k nnen 2 Konzeption der Software Engineering Ausbildung Wie an Fachhochschulen blich ist ein praktisches Studiensemester in den Studien verlauf integriert Nach der theoretisch orientierten Grundausbildung soll mit dem prak tischen Studiensemester der industrielle Kontext erschlossen werden bevor im weiteren Hauptstudium die in der Praxis gewonnenen Erfahrungen in die Ausbildung einflie en und reflektiert werden k nnen Dazu dient das stundenm ig hervorgehobene Multime dia Design Projekt F r das Multimedia Design Projekt sind ber zwei Semester insge samt 18 SWS vorgesehen Die Projektarbeit vermittelt die erforderlichen Kenntnisse Methoden und Fertigkeiten anwendungsbezogen und problemorientiert Das Projekt integriert Lernen und Arbeiten nach
62. Gruppen etwa eine Stunde Befragungszeit hatte Es entwickelten sich sehr lebhafte Diskussionen Die Betreuer waren anwesend griffen in die Diskussion aber nur ein um eine gleiche Aufgabenstellung f r die insge samt sechs Teams sicherzustellen Die auf die Kundenbefragung folgenden Projektabschnitte Spezifikation Reviews der Spezifikation Entwurf Implementierung und Test waren von der Tatsache dass die Aufgabenstellung von einem externen Kunden stammte nicht signifikant betroffen Lediglich nach der Qualit tssicherung der Spezifikation durch Reviews mussten Un klarheiten bei der Aufgabenstellung erneut mit dem Kunden gekl rt werden Die Abnahme der Resultate fand als Pr sentation wieder mit Kundenbeteiligung statt 2 4 Qualit t der Abgaben Nahezu alle Gruppen erzielten vorzeigbare Ergebnisse Die Abschlusspr sentationen wurden berwiegend professionell vorgetragen und die gezeigten Ergebnisse hatten soweit es aus der Pr sentation erkennbar war Produktqualit t Bei etwa zwei Drittel der Abgaben wurde die Bedienbarkeit von den Kunden besonders gelobt Die besten zwei Abgaben je Komponente wurden schlie lich von den Betreuern ausgew hlt und auf weitere Produktqualit t wie Wartbarkeit speziell nderbarkeit und Lesbarkeit genauer untersucht Diese recht zeitintensive Untersuchung ergab dass na hezu alle Abgaben im Bereich der Wartbarkeit Schw chen hatten Die Lesbarkeit war z B durch ungeschickte Bezeichner f r Klas
63. Gruppen und Zwecke anlegen und die Besitzer eines Raums k nnen die Zugriffsrechte einschr nken Ein Raum besteht aus mindestens einer Seite die von jedem Benutzer mit den entsprechenden Rechten mit Hilfe einer einfachen Wiki Syntax editiert werden kann Es ist auch m glich TeX Kommandos in diese Seiten einzubinden um beispielsweise komplexe mathematische Formeln zu erzeugen Neben normalen Seiten kann ein Raum auch Datenseiten enthal ten auf denen ein Benutzer beliebige Dateien ablegen kann ber eine Anbindung von CURE an NetMeeting oder DyCE Tie01 ein komponentenbasiertes Groupware Framework ist auch eine synchrone Kooperation unter den Benutzern m glich AuBer dem kann ein Raum einen eigenen Chat und eine eigene Mailbox besitzen deren Daten jeweils persistent gespeichert werden Keine der Informationen die an einen Raum gesendet werden gehen verloren Sowohl die Diskussionsbeitr ge in den Mail Foren des Raums als auch die Eintr ge im Chat bleiben erhalten Bisherige Erfahrungen mit der CURE Umgebung haben gezeigt dass die Studie renden berwiegend die asynchronen Kommunikationsmechanismen von CURE benut zen Dies hat zwei Griinde Erstens kommt synchrone Kommunikation an der FernUni versit t selten vor wie oben bereits erl utert wurde und zweitens bevorzugen die Studierenden ihre eigenen gewohnten Instant Messaging Programme Die bekannten Instant Messaging Werkzeuge lassen sich noch zusammen mit der IDE der Studieren
64. H 99 Teubner 1999 Stp 04 TU Dresden Fakult t Informatik Softwaretechnologie Praktikum http www st inf tu dresden de Lehre praktikum htm Projekte der Lehre mit hochschulexternen Kunden Tilmann Hampp Stefan Opferkuch Rainer Schmidberger Abteilung Software Engineering Institut fur Softwaretechnologie Universitat Stuttgart Universitatsstr 38 70569 Stuttgart hampp opferkuch schmidberger infomatik uni stuttgart de Zusammenfassung Praktische Projektarbeit ist Teil vieler Informatik und Softwaretechnik Curricula Die Aufgabenstellungen die diesen Projekten zugrunde liegen ent stammen oft dem Themenkreis des betreuenden Instituts oder sind speziell von den Betreuern erdacht und f r keinen wirklichen Verwendungszweck vorgese hen Teilweise ist die Aufgabenstellung auch von den Studenten selbst festgelegt In allen drei F llen wird die Kundenrolle nicht realit tsnah im Projekt vertreten Dieser Artikel beschreibt am Beispiel zweier durchgef hrter Praktika wie exter ne Partner eine Kundenrolle in einem studentischen Projekt bernehmen k nnen und welche Schwierigkeiten und welcher Nutzen hierdurch entstehen 1 Einf hrung Immer h ufiger geh rt praktische Projektarbeit zum Curriculum des Informatik oder Softwaretechnik Studiums Die Projekte werden typischerweise ber einen l ngeren Zeitraum ein bis zwei Semester mit Beteiligung mehrerer Studenten typischerweise drei bis zw lf durchgef hrt Die geleistete En
65. Hay97 W Hayes J W Over The Personal Software Process PSP an empirical study of the impact of PSP on individual engineers Technical Report CMU SEI 97 TR 001 Carnegie Mellon University Software Engineering Institute 1997 Hum95 W S Humphrey A discipline for software engineering Addison Wesley 1995 Hum96 W S Humphrey Using a defined and measured Personal Software Process IEEE Software 13 3 77 88 1996 Hum99 W S Humphrey Introduction to the Team Software Process Addison Wesley 1999 Joh98 P M Johnson A M Disney The Personal Software Process a cautionary case study IEEE Software 15 6 85 88 1998 Joh02 P M Johnson H Kou J Agustin C Chan C Moore J Miglani S Zhen W E J Doane Beyond the Personal Software Process Metrics collection and analysis for the differently disciplined Proc 2003 International Conference on Software Engineering Portland Oregon 2003 Kam00 J Kamatar W Hayes An experience report on the Personal Software Process IEEE Software 17 6 85 89 2000 Mor00 M Morisio Applying the PSP in industry IEEE Software 17 6 90 95 2000 Pre01 L Prechelt B Unger An experiment measuring the effects of Personal Software Process PSP training IEEE Transactions on Software Engineering 27 5 465 472 2001 Ros03 R Rossi Adoption of the Personal Software Process in Finnish Technical Report C 2003 68 Department of Computer Science University of Helsinki 2003 Sa
66. P Mandl Striegnitz Qualifizierte Software Projektmanager durch simulationsbasierte Ausbildung In Lichter Glinz Hrsg Software Engineering im Unterricht der Hochschulen SEUH Z rich 2001 Mit03 R Mittermeir E Hochmiiller A Bollin S J ger M Nusser AMEISE Concepts the Environment and Initial Experiences In Auer ed Proc Internatl Workshop ICL Villach 2003 Das Software Engineering Praktikum SEP Konzept und Erfahrungen Peter Kaiser Sven Klaus Fachbereich Informatik Fachhochschule Mannheim Windeckstr 110 68163 Mannheim p kaiser s klaus fh mannheim de 1 Das Praktikum Im Bachelor Studiengang fiir Informatik der FH Mannheim stellt ein einsemestriges Software Engineering Praktikum im vierten Fachsemester einen wesentlichen Bestandteil dar Es hat das Ziel das praktische Wissen f r die erfolgreiche Entwicklung von Software zu vermitteln Dazu geh ren die Anwendung von Software Prozessen die Anwendung und das Verst ndnis von Software Engineering und Prozessmanagement Methoden das F hren kleiner Teams sowie Projektpr sentationen Das Praktikum baut auf den blichen Informatik Vorlesungen auf wobei dabei bereits ein Mini Software Projekt mit dem Fokus auf den Entwicklungsdokumenten durchgef hrt wird Im vierten Semester werden neben wenig anderen Vorlesungen Intensivkurse zu projektrelevanten Themen in Blockvorlesungen gehalten 12 SWS widmen die Studierenden der Praktikumsaufgabe Diese umfasst
67. Praktikumsleiter als Bad Guy bernimmt die Vertrauen mindernden Aufgaben wie das Stellen expliziter unangenehmer Kontrollfragen oder das Sanktionieren von Fehl verhalten Der Tutor als Good Guy sucht nach dem Positiven oder verh lt sich zumin dest unschuldig 4 Diskussion In den beschriebenen Methoden und Techniken f r Praktika lassen sich einige generelle Prinzipien des Unterrichts von Software Engineering an Hochschulen erkennen Praxisn he l sst sich auch in Lehrveranstaltungen an Hochschulen herstellen Ob die Teilnehmer eine Lehrveranstaltung als praxisnah empfinden h ngt unserer Erfahrung von folgenden Kriterien ab die sich in Praktika besonders gut umsetzen lassen e Lernhandeln Die Veranstaltung bietet viele M glichkeiten selber zu tun e berraschung M glichst viele dieser bungen sind ein neues oder im Ausbil dungskontext berraschendes Erlebnis f r die Teilnehmer Gegenbeispiel Pro grammieren w rde niemand als besondere Praxiserfahrung hervorheben e Authentizit t amp Nutzen Die jeweiligen Lerninhalte sind f r die Teilnehmer erkenn bar praxisrelevant Der Dozierende erkl rt welchen Nutzen das zu Lernende im sp teren Berufsleben haben wird Authentizit t entsteht insbesondere wenn Dozierende ber eigene Praxiserfahrung verf gen und ber diese berichten k nnen Letztlich kommt man um die Erkenntnis nicht herum dass nur solche Personen Software Engineering authentisch und praxisnah unterrichten k nn
68. Projektleiter geplant Dieser hatte die folgenden externen Meilensteine geplant MO Projektplan MI Spezifikation des Gesamtsystems M2 Entwurf f r die erste Iteration M3 Abnahme der ersten Iteration M4 Entwurf f r die zweite Iteration M5 Abnahme des Gesamtsystems M6 Projektende Die externen Pilotkunden waren nicht bei allen externen Meilensteinen beteiligt Pro jektplan und Entwurf wurden ausschlie lich vom internen Kunden und den Betreuern abgenommen Im Projekt wurden alle Anforderungen in der Spezifikationsphase der ersten Iterati on erfasst und dokumentiert Die Abnahme der Spezifikation erfolgte durch den inter nen Kunden dann wurde den externen Kunden ein Prototyp gezeigt F r die erste Iteration wurden die wesentlichen Anforderungen identifiziert damit ein einsatzf higes Produkt entstand F r diese Anforderungen wurde ein Entwurf er 142 Tilmann Hampp Stefan Opferkuch Rainer Schmidberger stellt der ausreichend erweiterbar fiir alle Anforderungen sein sollte Implementiert wurden fiir die erste Iteration nur diese wesentlichen Anforderungen Am Ende der ers ten Iteration wurde das lauff hige Produkt den Kunden pr sentiert und fiir den Einsatz zur Verfiigung gestellt In Analyserunden wurden weitere Anforderungen erhoben kleinere Korrekturen waren noch notwendig Mit dem internen Kunden wurden die neu erhobenen Anforderungen und die noch nicht realisierten Anforderungen priorisiert Anschlie end wurde der Entwur
69. Reaktio nen wurden von Assistenten den Spielern in definiertem Wochenraster berbracht Menschliche Betreuer als Informations berbringer f hrten offenbar zu einer st rkeren gef hlsm igen Identifikation mit dem simulierten Projekt und erh hten offenbar die Glaubw rdigkeit der simulierten Informationen aus Spielersicht Dagegen wirkt wieder nach Aussage der damaligen Studenten die reine Simulation am Rechner eher steril und unecht keine gute Voraussetzung f r authentische Gef hle oder Erfahrungen In den letzten Jahren hat SESAM hier sicher Fortschritte gemacht doch mir geht es hier um eine allgemeinere Beobachtung zu Simulationen Eine zu glatt und zu schnell laufende Simulation ist wohl generell eher kontraproduktiv f r die Erfahrungs vermittlung Wenn das simulierte Projekt in wenigen Minuten abgewickelt werden kann wird allein dadurch Planung fast unm glich und Situationen wie banges Warten werden verhindert Auch kann sich nicht in Minuten dieselbe Spannung aufbauen wie wenn man auf die Antwort drei Tage warten muss Spannung banges Warten und der gleichen br uchte man f r starke nach der obigen Definition vollwertige Erfahrungen Einen anderen Anspruch kann aber auch die schnell laufende Simulation durchaus ein l sen N mlich festzustellen ob man das gelernte Wissen des Projektleiters schnell re produzieren kann Damit kann man richtiges Verhalten ben und falsches erkennen 3 Erfahrung pur obwohl man etwas an
70. Sie sind eine pragmatische Art und Weise mit vielen parallel laufenden Projekten umzugehen von denen man sich nicht alle Details ansehen kann e Zeitgutscheine Die Zeit der Kunden ist knapp und wertvoll Dazu gibt es an der Hochschule h ufig keine Entsprechung Indem wir jedem Projekt nur sechs mal 15 Minuten f r die Kommunikation mit dem Kunden zusprachen f hlten sich alle Gruppen gefordert diese Zeit optimal zu nutzen Letztlich hat nur eine Gruppe berhaupt alle sechs Gutscheine verbraucht Fast alle anderen haben sogar noch Prototypen mit dem Kunden diskutiert in weni ger als insgesamt 90 Minuten pro Gruppe w hrend des ganzen Semesters 22 Kurt Schneider Erfahrung Gezielte Interventionen Abb 3 SWP04 Erfahrung wird durch gezielte Interventionen provoziert Wieder haben wir durch Befragung gezielte Erfahrungserfassung Sch 00 und durch Frageb gen die Sicht der Studierenden abgefragt Besonders bei den drei genannten Ma nahmen haben die Studierenden deutlich Gef hle gezeigt und auch ge u ert hier h tten sie unerwartete Erfahrungen gemacht Aber auch andere Entwicklungst tigkei ten in die wir nicht eingegriffen haben wurden als besonders realit tsnah eingestuft Die Durchf hrung der Projekte und die dabei verfolgten Zielsetzungen sind in L b 04 detaillierter beschrieben 5 Erfahrungen per Internet vermitteln Werkzeuge Der vierte Ansatz unterscheidet sich stark von den oben beschriebenen Hier
71. Software Engineering im Unterricht der Hochschulen Prof Dr Ing Klaus Peter L hr Professor f r Informatik an der Freien Universitat Berlin seit 1985 davor an der Universit t Bremen Promotion und Habilitation an der Technischen Universit t Berlin Fachgebiete Systemsoftware Softwaretechnik Middleware Projekte in den Bereichen nichtsequentielle und verteilte Programmiersprachen Sicherheitsmanagement f r verteilte Objektsysteme komponentenbasierte Entwicklung Prof Dr rer nat Horst Lichter hat Informatik an der Universit t Kaiserslautern studiert Anschlie end war er als wissenschaftlicher Mitarbeiter in der Abteilung Software Engineering der ETH Z rich und der Universit t Stuttgart t tig Von 1993 bis 1995 war er Mitarbeiter der Schweizerischen Bankgesellschaft Z rich und danach bis 1998 Mitarbeiter des ABB Forschungszentrums Heidelberg Seither ist er Professor f r Informatik an der RWTH Aachen mit dem Schwerpunkt Software Konstruktion und Qualit tssicherung Wir danken den Sponsoren der SEUH 2005 ABD BOSCH lowe sd amp m Klaus Peter Lohr Horst Lichter Hrsg Software Engineering im Unterricht der Hochschulen SEUH 9 Aachen 2005 re dpunkt verlag Klaus Peter Lohr lohr inf fu berlin de Horst Lichter lichter cs rwth aachen de Herstellung Birgit Bauerlein Umschlaggestaltung Helmut Kraus Dusseldorf Druck und Bindung Koninklijke W hrmann B V Zutphen Niederlande Bibliografische Infor
72. Studienprojekts ist mit externen Kunden aufw ndiger als ohne ex terne Kunden Der Aufwand f r die Rolle des Kunden f llt f r die Mitarbeiter nicht weg sondern bleibt bei vermutlich gleichem Aufwand als interner Kunde erhalten Zu s tzlich steigt der Aufwand f r die Vorbereitung deutlich Externe Kunden m ssen f r das Studienprojekt gewonnen und die Aufgabenstellung muss abgesprochen und ange passt werden W hrend des Studienprojekts m ssen Termine koordiniert werden F r die Industriepartner die als externe Kunden beteiligt sind f llt ebenfalls Auf wand an Bei fast allen Treffen waren zwei oder mehr Mitarbeiter jedes externen Kun den anwesend f r die Treffen ist damit pro Kunde ein Aufwand von rund 8 Arbeitsta gen angefallen ohne Anreise Der Nutzen ist daf r sehr hoch Der Kunde bekommt ein einsatzf higes Produkt das seine Anforderungen realisiert F r die Studenten die am Studienprojekt teilnehmen bedeuten externe Kunden eine gr ere Herausforderung Der Kontakt zu realen Kunden stellt sie vor eine neue Situa tion Schwierigkeiten zeigten sich darum besonders in der Angebotsphase Den Studen ten war zwar klar dass sie den Kunden f r ihr Angebot gewinnen m ssen aber nicht wie sie ihr Angebot so gestalten dass sich der Kunde darin wiederfindet Erschwert wurde diese Aufgabe durch die unterschiedlichen Erwartungen der beiden externen Kunden Schwierigkeiten beim Kundenkontakt zeigten sich auch bei der Analyse von
73. Teachlets in einer Teachlet Werkstatt selbst entwickelt und eingesetzt 1 Einf hrung Entwurfsmuster siehe unter anderem GHJV95 sind eine interessante Heraus forderung in der Informatik Ausbildung Der Raum der M glichkeiten zu ihrer Vermitt lung kann aufgespannt werden von einer reinen Vorlesung ohne bungen bis hin zu lose betreuten Aufgabenstellungen die den Einsatz von Entwurfsmustern nahe legen Da Entwurfsmuster eng mit praktischen Entwurfserfahrungen verkn pft sind birgt eine reine Vorlesung die Gefahr dass lediglich Schlagworte h ngen bleiben Immerhin kann in einer Vorlesung eine breite Abdeckung der wichtigsten Entwurfsmuster gew hrleis tet werden Eine lose Betreuung von Aufgaben mit hohem Praxisanteil hingegen also ein Praktikum hat den Vorteil der individuellen praktischen Erfahrung aber auch Nachteile Das individuelle Feedback zu einzelnen Entwurfsentscheidungen kommt meist zu kurz und nicht alle Teilnehmer kommen m glicherweise mit allen relevanten Entwurfsmustern in Kontakt Teachlets w hlen einen Mittelweg zwischen Frontalvermittlung und individueller Auseinandersetzung indem in einer speziell vorbereiteten Unterrichtseinheit alle Teil 94 Axel Schmolitzky nehmer gemeinsam an einer Aufgabenstellung arbeiten Der Ansatz tr gt unter anderem der nachdr cklichen Aussage von Vlissides in CHV00 Rechnung dass Entwurfsmus ter immer im Zusammenhang mit den Problemen die sie l sen betrachtet werden soll ten
74. Zeit ben tigen um es zu lesen und dann etliche Fragen haben die ihr mit den Kunden kl ren m sst Erstellt einen ersten vorl ufigen Zeitplan f r die Woche nach dem Kick off Um diese Aufgaben zu bearbeiten mussten die Studierenden selbst einen Zeitplan definieren kl ren wie sie die Aufgaben l sen wollen Ergebnissicherung betreiben usw W hrend die Studierenden selbstst ndig arbeiteten wurden sie von den Trainern beobachtet und etwa alle 30 Minuten unterbrochen um gemeinsam ber den Arbeitsstil und die erreichten Ergebnisse zu reflektieren und Tipps zu geben 38 Andreas Fleischmann Katharina Spies Katharina Neumeyer 3 7 Ablauf des Teamtrainings Das Teamtraining fand als dreit giges Blockseminar am ersten Semesterwochenende statt Beginn war jeweils um 9 Uhr Ende jeweils um 17 Uhr Der erste Tag begann mit einem ersten Kennenlernen der Teilnehmer es wurde ein wenig Theorie die Teamkurve vermittelt Thematischer Schwerpunkt waren die Strukturierung von Meetings Arbeitstechniken f r Teams und Umgang mit Kritik Am Vormittag des zweiten Tags standen effektives und kooperatives Diskutieren sowie Projektmanagement im Vordergrund Am Nachmittag begann das Miniprojekt Am dritten Tag wurde das Miniprojekt fortgef hrt und beendet Die Teilnehmer bekamen Hand outs mit Checklisten zu den wichtigsten Themen so wie ein Fotoprotokoll des Teamtrainings in dem alle Tafelanschriften etc abfoto grafiert waren 4 Beobacht
75. al Memories Lew 01 Lewerentz C and H Rust Die Rolle der Reflexion in Softwarepraktika Software Enginee ring im Unterricht der Hochschulen SEUH 2001 Z rich dpunkt verlag Lir 04 Liro T Konzept und Realisierung eines Werkzeugs zur Erhebung Verwaltung und Bewer tung von Erfahrungen Fachgebiet Software Engineering Hannover Universit t Hanno ver 40 LUb 04 L bke D T Flohr et al Serious Insights through Fun Software Projects EuroSPI 2004 European Software Process Improvement Conference Trondheim Norway Springer Mer 04 Merel P Extreme Hour http c2 com cgi wiki ExtremeHour Rod 04 Rodriguez D M Satpathy et al Effective software project management education through simulation models An externally replicated experiment International Conference on Product Focused Software Process Improvement PROFES Kansai Science City Japan Bomarius F Sch 94 Schneider K Ausf hrbare Modelle der Software Entwicklung Struktur und Realisierung eines Simulationssystemes Z rich vdf Sch 00 Schneider K LIDs A Light Weight Approach to Experience Elicitation and Reuse Product Focused Software Process Improvement PROFES 2000 Oulo Finland Springer Sch 01 Schneider K and T Schwinn Maturing Experience Base Concepts at DaimlerChrysler Software Process Improvement and Practice 6 85 96 Sch 02 Schneider K What to Expect from Software Experience Exploitation Journal of Univer sal
76. alit t und Wirksamkeit der Leistungskontrolle Die Leistung erfolgt im Team aber den Leistungsnachweis bekommt jeder Teilnehmer einzeln Das ist der voreingebaute Widerspruch von Unterrichtsformen mit Teamarbeit Die Ernsthaftigkeit des Problems der Leistungskontrolle zeigt Kerer2004 In dem berichteten Gro praktikum waren zwei Aspekte der Leistungskontrolle ersichtlich die Benotung und die Entlarvung von Betr gern zwei der drei gr ten Aufw nde des ge samten Praktikums Wie kann eine treffsichere individuelle Leistungskontrolle bei mo deratem Aufwand erfolgen Tutorenschulung Bei Kundengespr chen Reviews und Konzeptionsarbeiten mit viel Kommunikation merken Tutoren wer die aktiveren und wer die passiveren Teil nehmer sind und wer die Leistung grob verfehlt Sie haben jedoch in der Regel zu we nig Erfahrung und manchmal auch keinen Mut gen gende von nicht mehr gen gender Leistung zu trennen und auch nicht die F hrungsf higkeiten um auf mangelhafte Leis tungen richtig zu reagieren Sie m ssen jedoch die Aufgabe der Leistungsbewertung erf llen weil sie am Ort des Geschehens sind F r kommunikative Praktikumsaufgaben in der Pr senzzeit kann unserer Erfahrung nach eine gute Leistungskontrolle durch Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 11 Schulung der Tutoren und Aussprechen einer klaren Erwartungshaltung erzielt werden F r SoPra besteht diese Schulung aus einfachen Rol
77. along the lines of PSP This is offered as an alternative way of accomplishing the course Software Processes and Quality Sof04 where one of the main goals is to introduce the concepts of process quality and measurement The course gives a short introduction to PSP and TSP Team Software Process Hum99 as examples of process models that rely heavily on measurement The duration of the course is only eight weeks and accordingly a slightly modified set of PSP exercises is used consisting of seven programming exercises and four reports leaving out the original exercises 7 8 and 9 and report R4 see Table 1 During the years 1999 2003 a total of 164 students took the course and 75 of them accomplished it with the PSP exercises In the first year of the course only a few students finished their PSP exercises but we have gradually increased the amount of tutoring and recently about half of the students take the PSP exercises instead of accomplishing the course in the more traditional way of classroom exercises and exam It can be assumed that the PSP students are typically practically rather than theoretically oriented and experienced in programming 108 A Inkeri Verkamo Asko Saura 4 Experience In our study we were particularly interested in observing the effect that PSP might have on the quality of the students software process As a basis for our research hypotheses let us first give a brief overview of some previously reported res
78. an der TU M nchen Kapitel 2 Danach stellen wir Konzeption Lerninhalte und Ablauf des Teamtrainings vor Kapitel 3 Abschlie end pr sentieren wir unsere bisherigen Er fahrungen mit dem Teamtraining geben einen Ausblick auf die weitere Entwicklung dieses Trainingskonzepts Kapitel 4 und schlie en mit einem kurzen Fazit Kapitel 5 2 Das Softwaretechnik Praktikum AutoRAID i j l Abb 1 Das studentische Team von AutoRAID Am Lehrstuhl Broy werden seit einigen Jahren regelm ig Softwaretechnik Praktika STP angeboten in denen Studierende der Informatik im Hauptstudium ein Semester lang selbstst ndig ein Software Produkt entwickeln Aufgabe des STP im Sommer semester 2004 war die Entwicklung von AutoRAID einem prototypischen Werkzeug zur modellbasierten Anforderungsanalyse f r das Requirements Engineering eingebet teter Systeme Aut 04 Mit AutoRAID sollen verschiedene Forschungsergebnisse des Lehrstuhls praktisch demonstriert werden beispielsweise die Erfassung von Require ments durch direkte Eingabe oder Import aus bestehenden Dokumenten die Klassi fikation der Requirements in mehreren Dimensionen und deren anschauliche Darstellung in einem Werkzeug automatische Konsistenzanalyse und das in Beziehung Setzen von Requirements untereinander und zu Design Elementen Tracing inklusive der automatischen Erzeugung von Designelementen Teamtraining f r Software Ingenieure 29 Das Projekt wurde von wisse
79. anderer beurteilt werden SESAM Software Engineering Simulated by Animated Models http www iste uni stuttgart de se research sesam Stand November 2004 AMEISE A Media Education Initiative for Software Engineering gef rdert von bm bwk unter NML 1 77 2001 http ameise uni klu ac at Stand November 2004 146 J ger Hochm iller Mittermeir Bollin Wakounig 3 Erfahrungen mit dem Einsatz von AMEISE Eine Schulung besteht aus f nf Teilen Einf hrung in den Simulator erste Simulation Feedback Sitzung zweite Simulation Feedback Sitzung Der Lernerfolg zwischen den AMEISE Simulationen deckt sich mit dem in Man01 berichteten Allerdings haben die AMEISE Features doch zu neuen Erfahrungen gef hrt Jae04 So hat die neue Benutzungsschnittstelle den durchschnittlichen Zeitaufwand f r eine Simulation von 4 5 auf 3 5 Stunden reduziert Da zwischen der dritten und vierten Stunde deutliche Erm dungserscheinungen auftreten ist diese Verbesserung beachtlich Durchwegs positives Feedback erhielten wir f r die Hilfsmittelkomponenten Rat geber und Schutzengel Sie reduzieren die von SESAM geschaffene nicht fachliche Komplexit t und verringern den Betreuungsaufwand w hrend eines Spiels deutlich Mit Hilfe der Online Auswertung k nnen Studierende bereits am Ende der Simula tion eine Eigenanalyse ihres Projekts vornehmen und ggf reagieren Die mehrt gigen Wartezeiten auf Auswertungen entfallen nun Allerdings ist es dennoch s
80. anzufertigen ist Dabei erschlie t sich f r viele Studierende oft nicht der Zweck des jeweiligen Modellierungsschrittes f r den weiteren Verlauf des Projekts Das Malen von Diagrammen wird nur als Belastung empfunden Im externen Praktikum bekommen die Studenten zwar auch Hinweise auf die Verwendung von UML Modellen sie m ssen die Entscheidung ber deren sinnvol len Einsatz gr tenteils jedoch selber treffen Dabei erfolgt im positiven Fall eine st r Softwaretechnologie Praktikum im Grundstudium 129 kere Auseinandersetzung mit den Zielen und M glichkeiten der UML Modellierung und der Lernerfolg ist h her Beim Vergleich der Ergebnisse im externen und internen Praktikum lassen sich kaum qualitative oder quantitative Unterschiede feststellen Der Arbeitsaufwand ist f r die Studierenden sowohl im internen als auch im externen Praktikum wesentlich h her als die vorgesehene SWS Da die Firmen die im Praktikum entstandenen Anwendungen h ufig tats chlich verwenden oder als Basis f r weitere Entwicklungen nutzen besteht f r die Studenten eine hohe Motivation zur Erstellung eines qualitativ hochwertigen Produkts Aber auch innerhalb des internen Praktikums entstehen immer wieder interes sante und ausgereifte Softwarel sungen Die Motivation zur Anfertigung guter Ergeb nisse gr ndet sich dabei haupts chlich auf das Erlebnis systematisch und arbeitsteilig ein eigenes Produkt entstehen zu lassen und im Vergleich mit anderen Teams gu
81. artet unge f llten Seminartermin vor zwei Jahren vorschlug eine kleine interaktive Muster werkstatt durchzuf hren Literatur AIf03 Alfert K et al MuSofT Multimedia in der Softwaretechnik Proc Software Engineering im Unterricht der Hochschulen SEUH Berlin S 70 80 2003 BlueJ BlueJ The Interactive Java Environment http Avww bluej org CHV00 Chambers C Harrison B Vlissides J A Debate on Language and Tool Support for Design Patterns Proc 27th ACM SIGPLAN SIGACT symposium on principles of programming lan guages Boston MA S 277 289 2000 Eclipse Eclipse An Open Platform for Tool Integration http www eclipse org E1198 Ellis A et al Resources Tools and Techniques for Problem Based Learning in Computing Proc ITiCSE 98 Dublin Ireland S 46 50 1998 GHJV95 Gamma E Helm R Johnson R Vlissides J Design Patterns Elements of Reusable Object Oriented Software Addison Wesley Reading MA 1995 Jetbrains IntelliJ IDEA An Intelligent Java IDE http vww jetbrains com idea K B04 K lling M Barnes D J Enhancing Apprentice Based Learning of Java Proc SIGCSE 36 Norfolk Virginia S 286 290 2004 Using Personal Software Process exercises to teach process measurement A Inkeri Verkamo Asko Saura Department of Computer Science P O Box 68 FIN 00014 University of Helsinki verkamo cs helsinki fi as iki fi Abstract Softwa
82. b 1 in dem die Softwaresysteme der Studierenden in Wettbewerbsform gegeneinander antre ten Die dadurch entstehende Konkurrenz tr gt entscheidend zur Motivation der Studie renden bei und bereitet die Studierenden gleichzeitig auf industrielle Arbeitsbedingun 44 Peter G hner Friedemann Bitsch Hisham Mubarak gen vor Vor der Rennveranstaltung m ssen die Studierenden ihr Produkt dem Kun den pr sentieren und versuchen ihn von der Qualit t oder der Pfiffigkeit ihrer L sung zu berzeugen Abb 1 Beispiel Parcours und Besucheransturm beim Roboterwettrennen 2 2 Vorgehensmodell zur Steuerung und Kontrolle des Projektverlaufs Ein wichtiges Mittel zur Unterst tzung der zeitlichen Planung und Durchf hrung des Softwareprojekts ist die Vorgabe eines Vorgehensmodells das die Studierenden in der Praktikumsdurchf hrung anleitet und die Durchf hrung der Softwareentwicklung im Fachpraktikum systematisiert Dieses Vorgehensmodell wurde auf der Basis des V Modells BrDr95 des Entwicklungsstandards f r IT Systeme des Bundes entwickelt Ein Ziel bei der Entwicklung war die Einfachheit des Modells sodass es f r die Studie renden im Rahmen des Fachpraktikums berschaubar und leicht erlernbar ist W hrend das V Modell ein generisches Vorgehensmodell darstellt das weder eine spezielle Or ganisationsstruktur noch einen bestimmten zeitlichen Ablauf vorschreibt werden im Vorgehensmodell des Fachpraktikums alle f r die Projektbearbe
83. ben nicht umfangreicher gestaltet werden sollten Schlie lich wurde die spezielle Konstellation dieses Softwarepraktikums mit der Beteiligung eines externen Kunden und dem geplanten Einsatz der entwickelten Software von der Mehrheit der Studierenden 37 von 50 als positiv bewertet 2 6 AbschlieBende Bewertung Der Nutzen f r den externen Partner steht in einem guten Verh ltnis zu seinem Auf wand der f r Vorbesprechung Kundengespr che und Abnahme etwa 3 bis 4 Arbeitsta ge betrug Das Projektresultat konnte zwar nicht unmittelbar als Produkt eingesetzt wer den aber es stand f r interne Diskussionen als Prototyp bereit Der Nutzen f r die Studenten l sst sich aus den Resultaten der Untersuchung able sen Der subjektive Eindruck der Betreuer war dass der Lernerfolg der Studenten ber dem der Vorjahre lag Zudem war ein von den externen Partnern finanziertes Fest ein gelungener Abschluss F r die Betreuer bedeutet ein Praktikum mit externen Kunden einen erkennbar h heren Arbeitsaufwand Die einzelnen Aufw nde wurden zwar nicht genau erfasst wir sch tzen aber dass der Gesamtaufwand um etwa ein Drittel h her liegt als bei Projek ten ohne externen Partner Dies liegt an der Partner und Aufgabensuche im Vorfeld aber auch an den Aufw nden zur Koordination im laufenden Projekt Als besonders wichtig hat sich die einheitliche Fixierung der Schnittstellen zwi schen den Komponenten herausgestellt Hier ist auch eine gewisse Erfahrung
84. benutzen aber GForge ist nicht leicht in Eclipse integrierbar 88 Philipp Bouillon Jens Krinke Stephan Lukosch synchronisiert werden k nnen Zurzeit gibt es sogar zwei verschiedene Kalender in der Universit tsplattform einen in der Verwaltungs und E Learning Plattform und einen in CURE beide sind voneinander unabh ngig und k nnen nicht miteinander synchroni siert werden Phase 2 Anforderungsanalyse Zu Beginn eines jeden Projekts besch ftigen sich die Studierenden fast ausschlie lich damit Unklarheiten zu diskutieren und Anforderungen niederzuschreiben Um f r eine lebhafte Diskussion zwischen den Mitgliedern eines Teams zu sorgen muss sowohl synchrone als auch asynchrone Kommunikation m glich sein Weiterhin muss es in der gleichen Umgebung m glich sein das Anforderungsdokument zu erstellen ohne st n dig zwischen den Anwendungen zur Diskussion und zum Niederschreiben hin und her wechseln zu m ssen Somit ist die CURE Architektur mit den Wiki Seiten dem Chat und der Mail Funktion an dieser Stelle ideal Durch die Versionsverwaltung in CURE k nnen auch immer ltere Versionen der einmal erstellten Dokumente abgerufen wer den Das Team der Studierenden muss aus der Anforderungsanalyse heraus auch ein zelne Tasks erstellen und diese in ihren Trackern eintragen Die Studierenden m ssen ihr Projekt also planen sowie f r jede Anforderung und jede Aufgabe einen Tracker Eintrag erstellen Somit wird die Nachvollziehbarkeit
85. betreuten nach Lernzielen konzipierten Praktikums im Hochschulbetrieb mit einem normalen kommerziellen Kundenprojekt Erfolgreiche Modelle sind a Entwicklung f r Non Profit Kunden Bothe2001 Raasch1997 b kommerzielle Kunden kommen zur Abschlusslektion die als Wettkampfpr sentation durchgef hrt wird und haben so die Gelegenheit besonders gute Studierende kennen zu lernen SoPra c f r kommerzielle Kunden werden Aufgaben mit geringer Priorit t gel st Forbrig1997 Kundengespr che Ob echt oder gespielt vom Dozenten Kundengespr che sind ein Erlebnis im Vergleich zur blichen Stoffvermittlung an Hochschulen Zu einem wirklich wertvollen Lerninhalt werden sie jedoch dann wenn auch professionelle Ge spr chsstrategien gelehrt werden beispielsweise das schrittweise Durchgehen von Ge sch ftsabl ufen in einer Sprache welche der Kunde versteht das gezielte Nachfragen Habe ich richtig verstanden dass und nat rlich das Stellen der Kernfrage Wann werden Sie mit unserer Arbeit zufrieden sein Professionalit t in der Form In der Praxis m ssen Ergebnisse auch u erlich pro fessionell sein Dies wird im Hochschulbetrieb vielfach nicht verlangt In schriftlichen Pr fungen beispielsweise wird nur die Konzentration auf den Inhalt trainiert Solange die Abgabe gerade noch lesbar ist z hlt sie In der Praxis ist diese Denkweise ein ver h ngnisvoller Fehler Daher soll der Dozent diesen Unterschied hervorheben u
86. c at reports bin abstract pl report TUV 1841 2003 27 Lichter2003 H Lichter et al Erfahrungen mit einem Workshop Seminar im Software Engineering Unterricht In J Siedersleben D Weber Wulff Hrsg Software Engineering im Unterricht der Hoch schulen SEUH 8 Berlin 2003 Heidelberg dpunkt verlag S 89 100 Prechelt2002 L Prechelt G Malpohl and M Philippsen Finding Plagiarisms among a Set of Programs with JPlag Journal of Universal Computer Science 8 11 November 2002 p 1016 1038 Raasch1997 J Raasch A Sack Hauchwitz Kooperation Kommunikation Pr sentation Lernziele im Software Engineering Projekt In P Forbrig G Riedewald Hrsg Software Engineering im Unterricht der Hochschulen SEUH 97 Stuttgart Teubner S 34 44 Ryser1999 J Ryser M Glinz Konzipierung und Durchf hrung eines Software Praktikums Ein Erfah rungsbericht In B Dreher C Schulz D Weber Wulff Hrsg Software Engineering im Unterricht der Hochschulen SEUH 99 Stuttgart Teubner S 55 68 Stoyan2004 R Stoyan Hrsg Management von Webprojekten F hrung Projektplan Vertrag Berlin Springer Vier Formen der Erfahrungsvermittlung im Studium Kurt Schneider FG Software Engineering Universitat Hannover Welfengarten 1 30167 Hannover Kurt Schneider Inf Uni Hannover de Zusammenfassung Software Engineering ist eines der F cher in denen Wissensvermittlung nicht ausreicht Bei Software Qualit t oder im Software Entwur
87. ch step of PSP so that the measurements and predictions apply to their personal way of developing software However since the measured phases are those that are typical to the traditional waterfall model combining the measurements with a strongly iterative process like XP might require some redefining of phases and even adoption of more suitable measures e g number of iterations For a more detailed description of PSP see Hum95 Attempts to introduce PSP as an off the shelf process have been mixed successes Industry practitioners report that they see value in the ideas presented in PSP planning based on collected data error prevention etc but when they have the chance they either do not start using PSP in the first place or quickly cease to use major parts of the process Fer97 Mor00 If the data collection and analysis overhead and the context switches from development to process analysis hamper adoption it would be useful to integrate data collection with the development tools Joh02 It has even been suggested that existing team processes do not produce the kind of development tasks that are easily structured as PSP projects or measured by PSP measures Mor00 3 PSP exercises in the University of Helsinki In the University of Helsinki students majoring in computer science can select software engineering as their field of specialization As part of their specialization studies they can measure their own software process
88. che Erweiterungen AMEISE erlaubt SESAM in gr eren Lehrveranstaltungen einzusetzen SESAMs Aus wertungsengpass wurde durch einen Mechanismus zur Online Auswertung berwun den Die Benutzerschnittstelle wurde so gestaltet dass durch Auswahl aus entsprechen den Men s SESAM Befehle entstehen Die SESAM Grundidee blieb aber erhalten Zwei Hilfsmittelkomponenten Ratgeber Consultant und Schutzengel friendly peer reduzieren den Betreuungsaufwand des Lehrveranstaltungsleiters w hrend der Simulationsl ufe Sie erlauben den Simulator auch ohne Vor Ort Betreuung zu ver wenden Der Ratgeber kann vom studentischen Projektmanager konsultiert werden Der Schutzengel ist einem erfahrenen Kollegen gleichzusetzen der das studentische Han deln beobachtet und bei drohender Krise mit Tipps zur Seite steht Mit Hilfe des externen Software Hauses Partialspiel ist auch die Auslagerung von Aufgabenstellungen konkreter Projektphasen an Dritte m glich Dadurch kann die Simulation auf einzelne Entwicklungsphasen fokussiert werden ohne dabei die Gesamtperspektive zu verlieren Mittels Rollback kann man ein Projekt auf spezifische Entscheidungspunkte zur cksetzen So k nnen Effekte von Entscheidungen erprobt und analysiert werden ohne das gesamte Projekt nochmals von Anfang an simulieren zu m ssen Eine weitere berlegung war den Studierenden Vergleichsm glichkeiten an zubieten Mittels Gruppenvergleich kann das eigene Projekt relativ zu den Projekten
89. chen Wis senszuwachs st rker hervorzuheben und den Studenten h ufiger positive R ckmel dungen zu geben Zu Beginn des Praktikums ist die Demonstration eines vorbildlichen Projekts aus dem Vorjahr n tzlich Dem Bericht von Studenten wird erfahrungsgem eher Glauben geschenkt als dem von Lehrbeauftragten Das Stiften von Preisen f r die besten Praktikumsteams hat sich als weiteres Mittel zur Motivationssteigerung erwie sen Reale Projekte k nnen nur mit leistungsf higen und motivierten Studenten erfolg reich durchgef hrt werden Die Trennung des externen Praktikums vom universit ren Umfeld birgt Risiken in sich Die Firmen kennen den aktuellen Ausbildungsstand eines Studenten im Grundstudium unzureichend und stellen ggf gemessen an den F higkei ten der Studenten inad quate Anforderungen an den Verlauf der Arbeit und an das Ergebnis Au erdem wird in den Firmen meist zu wenig Wert auf die systematische Softwareentwicklung gelegt sondern der Fokus zu stark auf das Endprodukt gerichtet Das widerspricht den eigentlichen Zielen des Praktikums softwaretechnische Kompe tenzen zu f rdern F r beide Probleme stellt der Einsatz von studentischen Betreuern auch f r externe Praktikumsgruppen eine geeignete L sung dar Durch den intensiven Kontakt der Betreuer mit den Teams dem Lehrstuhl und den Firmenvertretern kann sowohl das Arbeitspensum immer wieder abgestimmt als auch das Einhalten eines sau beren Entwicklungsprozesses kontrolliert we
90. chgef hrt werden Kleine Modifikationen der Aufgabenstellung mit m glichst durchg ngigen Auswir kungen auf den Code helfen gegen das Kopieren von L sungen aus fr heren Semestern wer es dennoch tut hat zumindest eine herausfordernde bung zum Reengineering bew ltigt und damit ebenfalls f r seinen Leistungsnachweis gearbeitet Teamarbeit an sich ist auch bereits eine Methode um Teilnehmer vom Kopieren ab zuhalten hier wirkt soziale Kontrolle In den Untersuchungen von Kerer2004 hat sich die Anzahl der Plagiate verachtfacht w hrend die Anzahl der Abgaben sich nur vervierfacht hatte als von Teamarbeit auf Einzelarbeit umgestellt wurde Schlie lich gibt es gute Werkzeuge zur Erkennung von Plagiaten Prechelt2002 W hrend dies in der Literatur gerne empfohlen wird und technisch gut funktioniert ist es didaktisch gesehen eine Ma nahme die nur Verlierer kreiert gescheiterte Teilneh Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 13 mer sowie Dozenten die Aufwand und Unannehmlichkeit der Diskussion mit den Be troffenen tragen m ssen Zum berpr fen der Wirksamkeit der vorigen weichen Ma nahmen jedoch sehr zu empfehlen Good Guy amp Bad Guy Die Tutoren geraten durch die Notwendigkeit der Leis tungsbeurteilung zwangsl ufig in einen Konflikt zwischen zwei Rollen Coach vs Kon trolleur Dieser Konflikt l sst sich durch ein Good Guy Bad Guy System mildern Der
91. chieden sich gemeinsam welche sie einsetzen wollen sie verschafften sich einen bersicht ber ihre Stundenpl ne um herauszufinden wann sie in der Woche Zeit haben um gemeinsam zu arbeiten Das Team diskutierte auch welche Rollen man innerhalb des Teams vergeben will Projektleiter Verantwortliche f r verschiedene Tools Chefentwickler sie verschafften sich eine bersicht ber die fachlichen F higkeiten und Interessen der einzelnen Teammitglieder u a um einsch tzen zu k nnen wer f r welche Rolle am besten geeignet w re und einigten sich darauf wer welche Rolle bernehmen w rde 3 4 Als Team zusammenarbeiten Teamwork Im Vordergrund des Workshops stand die Vermittlung von Arbeitstechniken die das gemeinsame Arbeiten unterst tzen zum einen als ganzes Team effizient und kooperativ zusammenzuarbeiten zum anderen eine effektive Arbeitsteilung Dazu wurden den Studierenden verschiedene Techniken kurz vorgestellt die sie dann in einer bung selbst erprobten anschlie end wurden die Vor und Nachteile der Technik reflektiert Im Miniprojekt haben die Studierenden dann selbstst ndig Tech niken ihrer Wahl eingesetzt und bekamen zur Wahl und Durchf hrung einer Technik Feedback von den Trainern 34 Andreas Fleischmann Katharina Spies Katharina Neumeyer Sitzungen strukturieren Hier wurden folgende Grundlagen vermittelt F r die Struktur und Durchf hrung eines Meetings sollte eine Person verant wortlich sein d
92. chzeitig als Berater des Teams anzusehen und dadurch Teil des Teams Die T tigkeiten des Teams sind auf den Auftraggeber also den Kunden ausgerichtet Die Rolle des Kunden wird zusammen mit dem Professor von einem vierten wissenschaftli chen Mitarbeiter ausge bt Dieser vierte Mitarbeiter bernimmt auch gleichzeitig die Gesamtorganisation des Fachpraktikums 2 1 Organisatorischer Rahmen Das Fachpraktikum wird w hrend der Vorlesungszeit im Sommersemester durchge f hrt In den ersten Wochen des Praktikums m ssen die Studierenden die Anforderun gen an das zu erstellende Softwaresystem analysieren und definieren Den Studierenden wird hierzu keine exakte schriftliche Aufgabenbeschreibung vorgelegt Der Kunde u Bert den Wunsch nach einer Software die einen mobilen Fahrroboter so schnell wie m glich durch einen unbekannten Parcours an ein vordefiniertes Ziel steuert In Ge spr chen und Interviews mit dem Kunden m ssen die Studierenden die Anforderungen ermitteln Dabei lernen sie mit den oft vagen Vorstellungen ihres Kunden umzugehen und diese in einem iterativen Prozess zu konkretisieren Sie lernen auch den Kunden als Ressource anzusehen die nicht permanent zur Verf gung steht und nicht immer mal eben Zeit f r eine kurze Frage hat Die Terminplanung und einhaltung wird so mit von Beginn an vermittelt Wie auch im industriellen Alltag k nnen sich die Kun denw nsche und damit die Anforderungen an das zu entwickelnde System
93. chzuf hren Das JRefleX Projekt bietet sogar Eclipse Plug ins an die zur Analyse der Kollaboration im Team und zur Evolutionsanalyse des Programms herangezogen werden k nnen Um eine Plattform zu entwickeln die die Kooperation der einzelnen Teammit glieder verbessert mussten neue Plug ins entwickelt werden und bestehende so erwei tert werden dass sie besser mit anderen zusammenarbeiten k nnen Welche Plug ins das im Einzelnen sind wird im n chsten Abschnitt beschrieben 3 Softwaretechnik Lehre morgen Zu Beginn der Entwicklung einer neuen Plattform stellt sich die Frage welche Werk zeuge in die IDE integriert werden m ssen um das Teamwork unter den Studierenden zu verbessern obwohl sie so weit voneinander entfernt sind Die Frage ist recht einfach die Antwort hingegen nicht Studierende und auch professionelle Softwareentwickler haben alle ihre unterschiedlichen Arbeitsweisen und Methoden um ein Softwareprojekt voranzutreiben Einige arbeiten lieber nachts andere sind echte Fr haufsteher und erle digen einen Teil der Arbeit vor dem Fr hst ck Manche Programmierer tendieren dazu gt http www sourceforge org http www gforge org gt http www intland com Eine Plattform f r die Softwaretechnik Fernlehre 85 alles zun chst genau zu planen und dann zu implementieren andere hingegen program mieren zuerst und testen danach Wie also kann eine IDE dabei helfen die jeweils bevorzugte Arbeitsweise eines Entwi
94. ck gegeben 5 2 Beobachtungen Der Versuch eine Unterrichtseinheit zu einem Entwurfsmuster als Teachlet zu gestal ten f hrt tats chlich zu einer vertieften Besch ftigung mit dem Lernziel Alle studenti schen Teachlet Moderatoren haben ihren Stoff gut beherrscht Nicht jede Person ist unmittelbar zum Teachlet Moderator geeignet Voraussetzung ist unter anderem ein fl ssiger Vortragsstil bereits bei Folienvortr gen Diese Voraus setzung wurde nicht von allen Teilnehmern gleich gut erf llt Dar ber hinaus werden aber noch weitere Soft Skills ben tigt die st ndige Reflexion dar ber welcher Ein wand wie n tzlich f r das Vorankommen ist sowie wiederholtes Zusammenfassen des bisher Geschehenen denn der Moderator muss jederzeit den Ablauf im Blick haben Die F higkeit starke Pr senz in einer Diskussion zu zeigen denn der Moderator muss jederzeit den Ablauf unter Kontrolle haben Dies sind F higkeiten die jedem Software 102 Axel Schmolitzky techniker zugute kommen Bei der Moderation eines Teachlets wird schnell deutlich in welchen dieser Bereiche noch Defizite existieren und an welchen Stellen somit noch gearbeitet werden sollte Auf der Meta Ebene wurden etliche Diskussionen ber den Programmierstil aber auch tiber die jeweils verwendete Entwicklungsumgebung im Folgenden kurz IDE gef hrt Zum Einsatz kamen Eclipse Eclipse IntelliJ IDEA Jetbrains und BlueJ BlueJ Insbesondere ber die professionell ausgeric
95. cklers zu unterst tzen und ihn nicht dazu zu zwin gen eine vorgeschriebene Methode w hlen zu m ssen Die wichtigen Punkte auf die es dabei ankommt sind Kommunikation Koordination und Kollaboration Wie oben schon angedeutet wurde gibt es an der FernUniversit t zwei wichtige Systeme f r Soft wareprojekte CURE und CodeBeamer Beide unterst tzen Kooperation 3 1 Kooperation mit CURE CURE Haa04a Haa04b ist eine kooperative Lernplattform zur Unterst tzung kooperativer Lernsituationen ber das Web Benutzer k nnen unabh ngig von ihrem Standort gemeinsam auf Informationen zugreifen Verteilte Teams k nnen in CURE ihr gemeinsames Lernen selbst organisieren indem sie in gemeinsamen Arbeitsbereichen Lernmaterial kooperativ bearbeiten und synchron bzw asynchron miteinander kommunizieren Eine Gruppe ist dabei definiert als die Menge der Nutzer eines gemeinsamen Arbeitsbereichs Gemeinsame Arbeitsbereiche und deren Zugangsberechtigungen werden in CURE mit Hilfe der Raum Metapher modelliert Der Zugriff auf einen Arbeitsbereich wird durch die Schl ssel Metapher gesteuert Um Mitglied einer Gruppe auf einem Arbeitsbereich d h Raum zu werden muss man einen passenden Schl ssel f r den Raum besitzen Durch die Kombination von R umen und Schl sseln die an Schl ssel gekn pften Rechte und die auf Schl ssel definierten Operationen werden verschiedenste Formen der Gruppenbildung unterst tzt So kann jeder Benutzer R ume f r bestimmte
96. das zu testende System bereits vorhanden war wurden die Systemtestf lle sofort implementiert und ausgef hrt Top down Die nderungsaufgabe Nachdem die Studierenden das Sysiphus hinreichend gut kennen gelernt hatten erhiel ten sie die Aufgabe Sysiphus so zu erweitern dass ein Inspektor eines Anforderungs dokuments unterst tzt wird d h insbesondere syntaktische Probleme wie das Fehlen bestimmter Eintr ge oder Links von Sysiphus erkannt werden Um diese Aufgabe zu l sen mussten sie die erlernten Techniken in einem zusammenh ngenden Prozess an wenden Forward Engineering Diese Vorgehensweise ist typisch f r viele Praktika und soll hier nicht n her erl utert werden Um auch hier die Qualit tssicherung zu be tonen wurde nach jeweils zwei Wochen eine Meilensteinabnahme durchgef hrt zu der die Studierenden die Ergebnisse des jeweils anderen Teams inspizierten Hierbei lernten sie eine weitere Art der Inspektion kennen die perspektiven basierte Lesetechnik Vom Code zu den Anforderungen und wieder zur ck 65 4 Erfahrungen TeilnehmerInnen waren Studierende der Angewandten Informatik Computerlinguistik Mathematik und der Volkswirtschaftslehre Dementsprechend hatten die TeilnehmerIn nen sehr unterschiedliches Vorwissen insbesondere auch Programmiererfahrung Dies wurde bei der Gruppenzusammensetzung ber cksichtigt Eine Gruppe l ste sich nach wenigen Wochen aufgrund der hohen Arbeitsbelastung auf s u so dass eine Neuzu
97. dem Softwaretechnik Praktikum muss man eine Aufgabe finden die nur im Team bew ltigt werden kann Bei uns l sen alle Gruppen die gleiche Aufgabe In einer zwei dimensionalen Welt konkurrieren zwei Schw rme von Bugs um Futter Es gilt einen Schwarm zu entwickeln der mehr Futter in sein Nest tr gt als ein vorgegebener Schwarm Alle Bugs eines Schwarms werden durch denselben endlichen Automaten kontrol liert der in einem sehr einfachen Maschinencode spezifiziert wird Beispiel in Abbil dung 2 Bugs k nnen sich bewegen ihre Umwelt erf hlen und einfache Markierun gen hinterlassen etwa um Wege zu kennzeichnen Dieser Code wird von einem Simulator eingelesen der die Automaten zweier Bug Schw rme in einer gegebenen Welt ausf hrt und so bestimmt welcher Schwarm erfolg reicher ist Abbildung 3 Zustand Code Kommentar 0 sense ahead 1 3 food Wenn Futter voraus weiter bei 1 sonst bei 3 1 move 2 Gehe auf Futter weiter bei 2 sonst bei 0 2 pickup 8 Nimm Futter auf und weiter bei 8 3 flip345 Suchen M nzwurf weiter bei 4 oder 5 4 turn left Drehe nach links weiter bei 0 5 flip267 M nzwurf weiter bei 6 oder 7 6 turn right Drehe nach rechts weiter bei 0 7 move 3 Nach vorne gehen weiter bei 0 8 sense ahead 9 11 home R ckweg Wenn Nest voraus weiter bei 9 9 move 10 8 Gehe auf Nest 10 drop und lege Futter ab Neubeginn bei 0 11 flip 3 12 13 Wieder mit M nzwurf suchen wie 3 7 12 turn left 8 13 flip 2 1
98. den insge samt 12 Wochen zur Verf gung Au erdem ist strikt vorgegeben welche Ergebnisse in jeder Phase entstehen sollen wie diese anzufertigen sind Dieses Vorgehen bietet zwar wenig Raum f r eigene Experimente hilft aber den meisten Teams das Praktikum erfolgreich zu absolvieren Sie besitzen bis zu diesem Zeitpunkt oft keine Erfahrung mit der Durchf hrung von Softwareprojekten und ben tigen daher ausf hrliche Anleitung Ein gro er Vorteil des internen Praktikums ist in der umfangreichen Dokumentati on und den zahlreichen Hilfsangeboten seitens des Lehrstuhls zu sehen F r die Arbeit mit dem zur Wiederverwendung im universit ren Praktikumskonzept vorgeschriebenen Anwendungsframework SalesPoint steht vielf ltige Unterst tzung bereit ein vollst n dig implementiertes einfaches Beispiel Videoautomat zwei Kochb cher zu Imp lementierungsfragen Hooks und HowTos sowie das st ndig verf gbare Exper tenwissen der SalesPoint Entwickler ber ein Praktikumsforum Dar ber hinaus ist das Framework selbst gut dokumentiert Technischer berblick API Spezifikation Neben der eigentlichen Anwendung entstehen im Verlauf des Praktikums weitere Artefakte die von den Gruppen ausf hrlich zu dokumentieren sind Dazu ist von jedem Team eine Webseite zu entwerfen auf der alle Ergebnisse des Praktikums zum Zeit punkt ihrer Entstehung zu ver ffentlichen sind Diese Ma nahme dient haupts chlich der Kontrolle von Qualit t u
99. den lassen mit vielen studentischen TeilnehmerInnen nur unter unvertretbar hohem Aufwand durchf hren 3 7 Spezialistentum versus Wissenstransfer Bisher konnten wir in den Studenten Projekten ein ausgepr gtes Spezialistentum beobachten Aus der Sicht der Gruppe ist es u erst effizient Spezialisten z B f r das grafische User Interface auszubilden und den erfahrensten Programmierer m glichst ungest rt implementieren zu lassen w hrend andere das Benutzungshandbuch schreiben Aus der Sicht von Lehrenden ist hierbei problematisch dass sowohl die Arbeit als auch der Wissenserwerb ungleich verteilt sind Das Ziel einer Lehrveranstaltung im Grundstudium muss aber sein dass alle TeilnehmerInnen alle Inhalte zumindest ansatzweise lernen Bei XP ist die Gefahr des extremen Spezialistentums durch die Paararbeit bei st ndig wechselnden Partnern und Aufgaben nicht gro XP hat sich durchaus als sehr effizient erwiesen Das XP Team hat weniger Stunden als die brigen Gruppen gearbeitet aber bei k rzerem Code ein im Funktionsumfang vergleichbares Produkt entwickelt obwohl konsequent zu zweit an einem Rechner gearbeitet wurde In Paararbeit wird sehr konzentriert gearbeitet Beide Partner m ssen st ndig bei der Sache sein XP verlangt eine Vereinbarung von festen Arbeitszeiten damit Paararbeit im Team funktionieren kann Zurzeit f hren wir eine intensive Studie zur Paararbeit durch Dabei beobachten wir die gesamte Arbeit der Teams die sich un
100. der Kommunikation und der Erfassung von Entscheidungsbegr ndungen Design Rationale vereinigt Ab bildung 2 zeigt die Benutzungsoberfl che Auf der linken Seite k nnen Systemmodelle wie z B Anwendungsf lle erstellt und modifiziert werden Auf der rechten Seite k n nen Fragen verschiedene L sungsvorschl ge deren Evaluierungen Argumentationen und Entscheidungen zu jedem Modellelement erstellt werden Modellelemente und Rationalelemente sind miteinander verlinkt Sysiphus ist eine verteilte Client Server Anwendung und bietet mit REQuest Dut 02 eine Web basierte Benutzerschnittstellte sowie mit RAT Wol 04 eine Java Swing 60 Barbara Paech Lars Borner J rgen R ckert Allen Dutoit Timo Wolf basierte Benutzerschnittstelle als Client Anwendungen an Beide Client Anwendungen arbeiten mit dem gleichen Server und k nnen zeitgleich verwendet werden Im Gegen satz zu anderen CASE Tools unterst tzt Sysiphus eine enge Integration der Kommuni kation und Begr ndungserfassung in die Systemmodelle Auftretende Fragen und Kommunikationsstr me wie sie aus Newsgroups bekannt sind k nnen direkt zu ein zelnen Modellelementen wie z B Anwendungsf llen nichtfunktionalen Anforderun gen Klassen oder Testf llen erstellt werden siehe Abbildung 2 Somit werden die Modelle mit explizitem Wissen angereichert welches bei der Verwendung von her k mmlichen Kommunikationsmedien wie E Mail oder Telefon verloren gehen kann oder nicht f r alle Proj
101. deres tut Agile Hour Agile Methoden sind in den letzten Jahren viel diskutiert worden Besonders eXtreme Programming von Kent Beck hat gro en Zuspruch aber auch extreme Ablehnung aus gel st Bec 00 Inzwischen hat die Kontroverse an Sch rfe verloren man versucht nun die St rken von agilen und anderen Ans tzen zu verbinden Dazu gibt es interessante B cher zum Beispiel Boe 03 F r viele Hochschulen geh rt Grundwissen ber agile Methoden heute zum Handwerkszeug des Software Ingenieurs Aber wieder reicht es nicht etwa die XP Praktiken aufzulisten und zu definieren was dabei getan wird Wie der fehlen Erfahrungen mit ihren drei Aspekten eigene Beobachtung Gef hl und abge leitete Schlussfolgerung Gerade Verfahren wie agile Methoden die so stark auf die gute Zusammenarbeit von Entwicklern und Kunden im Team bauen brauchen dort eine breite gemeinsame Erfahrungsbasis auf die sie sich abst tzen k nnen Offenbar wurde dieses Defizit auch von anderen empfunden denn schon seit einiger Zeit gibt es einen interessanten Ansatz der gezielt die Vermittlung von Erfahrungen zu einem Ausschnitt von agilen Methoden zum Ziel hat die Extreme Hour Mer 04 von Peter Merel wir nennen sie Agile Hour weil es uns nicht nur um XP geht Das Prinzip lautet Es werden zwei Iterationen eines Konstruktionsprojekts durchgespielt Insgesamt 20 Kurt Schneider werden sieben Schritte unterschieden 1 Erkundung durch Prototypen Spikes ge nannt
102. des Teachlet Konzepts Ein Teachlet ist eine interaktive Lehreinheit in der ein lauff higes St ck Software um eine klar definierte Funktionalit t erweitert werden soll um ein Entwurfsmuster oder ein Programmiersprachkonzept zu veranschaulichen Ein Moderator motiviert mit Hilfe eines Rechners und eines Beamers das Ausgangssystem sowie die vorzunehmende Er weiterung und l sst sich dann von den Teilnehmern anleiten die dazu notwendigen nderungen am Quelltext vorzunehmen Die Grundidee eines Teachlets ist somit dass durch den praktischen Umgang bei den Teilnehmern ein gr erer Lerneffekt als mit rein theoretischen Diskussionen erzielt werden soll Eine Betonung liegt hier auf dem Wort interaktiv denn der Moderator ei nes Teachlets demonstriert nicht einfach nur eine praktische Realisierung sondern mo tiviert die Teilnehmer zur aktiven Gestaltung einer L sung 2 1 Statische Struktur eines Teachlets Die folgende vier Bestandteile sind unabdingbare Voraussetzung f r ein erfolgreiches Teachlet und sollten explizit bei der Vorbereitung ber cksichtigt werden Eine Werkstatt f r Teachlets 95 e Ein Ausgangssystem eine m glichst kleine lauff hige Anwendung die im Quelltext vorliegt e Ein Lernziel Kenntnis eines Entwurfsmusters oder eines Programmier sprachenkonzepts das praktisch kennen gelernt und verstanden wurde e Eine oder mehrere Aufgaben Sie implizieren eine Erweiterung nderung am Ausgangssystem beim L se
103. die Erstellung der Kooperationsvertr ge sowie die Einarbeitung in jeweils neue The menstellungen und in die konkreten organisatorischen und technischen Rahmenbedin gungen bei der jeweiligen Firma 128 Birgit Demuth Lothar Schmitz Barbara Wittek F r das externe Praktikum wird ein hnlicher Ablauf angestrebt wie f r das interne jedoch wird hier von den Studierenden eine gr ere Eigenverantwortung erwartet Insbesondere k nnen sie in Absprache mit ihren Betreuern den im internen Praktikum vorgeschriebenen Softwareentwicklungsprozess an ihre Situation anpassen Die Firmen des externen Praktikums betreuen ihre Teams autonom Wenn es jedoch gew nscht wird stellt der Lehrstuhl ebenfalls einen studentischen Betreuer zur Verf gung der die softwaretechnische Seite des Praktikums berwacht w hrend die Firma die Kundenrol le bernimmt Diese Praxis hat sich als g nstig erwiesen da so die Einheitlichkeit der Anforderungen im internen und externen Praktikum besser gew hrleistet ist K nftig wollen wir daher regelm ig so vorgehen Im externen Praktikum verwenden die Teams verschiedenste Technologien Fra meworks und Softwarekomponenten wieder zum Teil Open Source Software zum Teil firmeninterne Entwicklungen zum Teil kommerzielle Produkte Die Dokumentation dazu ist oft unzureichend und Expertenwissen gar nicht oder nur ber Umwege erh lt lich Die Studenten m ssen st rker auf eigene Recherchen und Experimente setzen was oft eine
104. dustrie ist man sich der Be deutung von Erfahrung sehr bewusst Es gibt in vielen groBen Firmen Initiativen die den Wissens aber auch Erfahrungsaustausch explizit anstreben und durch Projekte unterst tzen Joh 99 Con 00 Din 00 F r DaimlerChrysler war ich am SEC Projekt beteiligt in dem auf mehreren Ebenen der Austausch und die Nutzung von Erfahrungen betrieben wurde Lan 99 Unsere Definition fiir Erfahrung war Erfahrung per Beobachtung Gef hl Schlussfolgerung Eine Beobachtung kann nur machen wer an einem Vorgang beteiligt ist oder ihm zu mindest beiwohnt Erfahrung kann nicht aus der Theorie abgeleitet werden Wichtig ist dabei das Gef hlsmoment Wird die Beobachtung durch Euphorie oder aber durch ein Gef hl der Entt uschung der Frustration oder des Argers begleitet so pr gt sich die Beobachtung tiefer ein und wird mit Assoziationen angereichert Die Schlussfolgerung oft mit sehr hypothetischem Charakter macht aus dem Eindruck des Erlebten eine Lehre die sich in der Zukunft wiederverwenden l sst Wird Erfahrung weitergegeben so wird sie h ufig auf diese Schlussfolgerung als Verhaltensregel oder Mahnung ver k rzt dann fehlen ihr aber die Einpr gsamkeit des Gef hls und die Authentizit t einer konkreten Beobachtung 18 Kurt Schneider Wie gibt man aber vollwertige Erfahrungen im Studium weiter An der Hochschu le wird die Wissensweitergabe ja ber Vorlesungen bungen und Seminare bew
105. e Studierenden die gelernten Techniken umsetzen und haben die Gelegenheit durch situationsbezogene Tipps zu korrigieren und zu erg nzen Das Miniprojekt sollte den bergang markieren vom gesch tzten Raum des Teamtrainings zum Praktikum Es gab erste echte Aufgaben die von Relevanz f r das Praktikum waren z B Rollenverteilung Entscheidung des Teams wen sie zum Projektleiter bestimmen Teamtraining f r Software Ingenieure 37 e Die Studierenden sollten sich durch die gemeinsame selbstst ndige Arbeit an den ersten echten Aufgaben des Praktikums besser kennen und einsch tzen lernen siehe Abschnitt 3 3 Teambuilding Die Aufgabenstellung f r das Miniprojekt lautete in geraffter Form Werdet euch klar ber St rken F higkeiten Wissen der einzelnen Teammitglieder Bestimmt wer von euch Projektleiter und wer Webmaster wird berlegt euch ob ihr noch weitere feste Rollen im Projekt festlegen wollt und wer sie einnehmen soll Ihr werdet mit Tools wie Java Eclipse CVS ArgoUML UML Sequenz Diagram men Latex und AutoFocus arbeiten m ssen berlegt euch wer sich bereits damit aus kennt und wie ihr am besten erreichen k nnt dass sich alle damit auskennen Verschafft euch einen berblick wer wann in der Woche Zeit hat und was geeignete Termine f r regelm ige Treffen sind Ihr werdet beim Kick off ein etwa 5Oseitiges Pflichtenheft mit der Aufgabenbe schreibung berreicht bekommen ihr werdet einige
106. e Vorstellung wie man systematisch an ein gr eres Programmierprojekt herangeht Aus diesem Grund haben wir den Lernblock Projektmanagement f r Software Entwicklung dem Teamtraining hinzugef gt Als Einstieg diskutierten wir mit den Studierenden anhand der beiden exemplari schen Vorgehensmodelle des Rational Unified Process RUP und des eXtreme Pro grammings XP die grundlegend gemeinsamen Elemente von solchen Vorgehens modellen Im Anschluss an die Diskussion bekamen die Studierenden von uns ein begr ndetes verbindliches Vorgehensmodell vorgegeben das angesichts des kurzen Zeitrahmens des Projekts relativ simpel ist Es handelt sich im Wesentlichen um ein aufgebohrtes Wasserfall Modell das aus drei Phasen besteht Analyse Design und Implementierung 36 Andreas Fleischmann Katharina Spies Katharina Neumeyer In der Analyse wird haupts chlich das Benutzerhandbuch erstellt Gleich zeitig sollen die Studierenden aber auch schon einen Oberfl chenprotoyp und ein logisches Datenmodell entwerfen Im Design wird schwerpunktm ig die Systemarchitektur entworfen Gleich zeitig sollen die Studierenden aber anhand eines funktionalen Prototyps wichtige fachliche und technische Aspekte ausprobieren In der Implementierung werden das ausf hrbare Programm und die Doku mentation erstellt Zus tzlich zu diesem Vorgehensmodell das ein Software Projekt in einzelne definierte Phasen segmentiert schlugen wir ein allgemeines Vorgehe
107. e in defect density occurred at exercises 4 and 10 Exercise 4 was the first exercise to use PSP1 and exercise 10 was the first and only exercise to use PSP3 However as PSP1 only adds the size estimation tool PROBE Hum95 to the process it is unlikely that the decrease of defect density in exercise 4 was caused by this process change We suspect that the very sharp drop on exercise 10 may result from it being a very big exercise and the last one so that the students were just tired of the whole thing Another explanation is that they used the reviews adopted in exercise 6 to avoid some defect types Defects KLoC 120 100 80 Q3 60 i KAA ay Qt 0 1 2 3 4 5 6 10 Exercise Figure 1 Defect density by exercise in defects KloC Surprisingly hypothesis H2 proved to be false Contrary to the previous reports the compile phase accounted for about half of all removed defects during the entire course Figure 2 Introducing reviews in exercise 6 sharply decreased the amount of compile defects but the compile phase still remained on top At the same time defects found in testing were noticeably less Perhaps our students would require more coaching on review methods A Inkeri Verkamo Asko Saura Percentage of defects removed in phase Compile Test Reviews 7 1 2 3 4 5 6 10 Exercise Percentage of defects removed by phase Both effort and size e
108. eachlet Einheit somit meist wieder zu einer klassischen Pr sentation Idealerweise sollten allen Teilnehmern nach einer Teachlet Einheit die Quelltexte der gemeinsam erarbeiteten L sung zur Verf gung gestellt werden damit sie bei Bedarf die M glichkeit haben sich noch einmal individuell mit dem Gelernten auseinander zu setzen 3 Ein Beispiel Um die theoretische Darstellung des letzten Abschnitt zu verdeutlichen wird in diesem Abschnitt ein Beispiel beschrieben Es handelt sich um ein Teachlet f r die Vermittlung des Befehlsmusters Es wurde in der in Abschnitt 5 beschriebenen Musterwerkstatt ent wickelt und bereits einmal au erhalb dieser Veranstaltung eingesetzt Eine Werkstatt f r Teachlets 97 3 1 Die Exposition Die Teachlet Einheit beginnt mit der Vorf hrung des Ausgangssystems Abbildung 1 zeigt seine grafische Benutzungsoberfl che Es handelt sich um ein sehr einfaches Sys tem zum ben der vier Grundrechenarten das in dieser Form beispielsweise f r Kinder im Grundschulalter geeignet sein k nnte Die Oberfl che besteht aus einem Fenster das in der oberen Zeile f nf Kn pfe ent h lt die Symbole der vier Grundrechenarten sowie das Gleichheitszeichen In der zwei ten Zeile folgt die Anzeige eines so genannten Ausgangswertes zu Beginn 1 sowie eines zuf llig gew hlten Operanden Es folgen zwei anfangs funktionslose Kn pfe Der erste ist mit einem Undo Pfeil unterlegt w hrend der zweite die Anzeige eines Proto ko
109. eantwortete negative Gefiihle Wer motivierte Teilnehmer will sollte sich nicht darauf beschr nken Probleme zu l sen wenn darum gebeten wird oder diese offensichtlich werden Das ist die zu erwartende Minimalleistung Sie kostet jedoch keineswegs mi nimale Arbeit weil gerade zum Beispiel Teamprobleme nur so lange einfache und gute L sungen haben wie sie nicht offensichtlich oder extrem st rend sind Stoyan2004 Bew hrt hat es sich hier den Teilnehmern klar zu zeigen Probleme sind willkommen bitte berichten dies jedoch kombiniert mit Einhaltung der Eskalationshierarchie dass also der Ansprechpartner zuerst immer der Tutor und nicht der Praktikumsleiter ist Indem dies im Laufe der Veranstaltung gelegentlich wiederholt wird aber auch indem die Teilnehmer zur Halbzeit einen Feedbackbogen ausf llen werden negative Gef hle abgesch pft sodass sie nicht weiter wachsen Eine typische Ursache f r sich anstauende negative Gef hle sind mangelnde Leistungen bei Kommilitonen wenn diese ohne Reaktion akzeptiert werden Wozu bem he ich mich dann Siehe hierzu den Absatz Teamleistung im Abschnitt Leistungskontrolle Permanentes Feedback Besonders motivierend wirkt es sich hier aus wenn zu s tzlich zum beschreibenden Feedback m ndlich bei m ndlichen Leistungen schrift lich bei schriftlichen jede Abgabe benotet wird Sinnvollerweise sollen die Noten auch in das Abschlussergebnis des Praktikums eingehen So se
110. easurement data collected during the exercises represent the student s process in a learning phase rather than in actual use When predictions of future performance are based on this data the result may be haphazard As we observed some students grasp the new concepts quickly and have stable results while others may have one or several exercises that are too much influenced by transient difficulties to be useful at all The small number of measurements emphasizes this problem since there is little room for discarding even obvious outliers from the small collection of historical data To be useful for collecting historical data the process should be the same from one measurement to the other Hence we plan to change our set of exercises to use only two processes In the first 4 exercises the students use their own basic process with added measurements for size time and defects The measurements on these exercises form the historical data that is analyzed to define a basis for process improvement The analysis should reveal the most time consuming and or most error prone phases of the process and the student can then choose one of several strategies to improve his her process The last 3 exercises are then performed using the modified process and again the collected measurement data can be used to analyze the effect of the change A second source of dissatisfaction was the content of the programming exercises The software produced in the exercises co
111. eclipse In Proceedings of the 2003 OOPSLA Workshop on Eclipse TechnologyeXchange S 1 5 2003 Bou04 N Boulila A H Dutoit B Br gge Scoop A framework for supporting synchronous collaborative object oriented software design process In Proceedings of the 2004 ASE Workshop on Cooperative Sup port for Distributed Software Engineering Processes S 39 53 2004 Che03 L T Cheng S Hupfer S Ross J Patterson Jazzing up eclipse with collaborative tools In Proceedings of the 2003 OOPSLA Workshop on Eclipse Technology eXchange S 45 49 2003 Gre02 S Greenberg M Roseman Using a room metaphor to ease transitions in groupware In Beyond Knowledge Management Sharing Expertise Cambridge MA 2002 MIT Press Haa04a J M Haake T Schiimmer M Bourimi B Landgraf A Haake CURE Eine Umgebung f r selbstorganisiertes Gruppenlernen i com Zeitschrift fiir interaktive und kooperative Medien September 2004 Haa04b J M Haake T Schiimmer M Bourimi B Landgraf Supporting flexible collaborative distance learning in the CURE platform In Proceedings of the Hawaii International Conference On System Sciences HICSS 37 2004 Leu01 B Leuf W Cunningham The WIKI way Addison Wesley Boston MA USA 2001 Pfi98 H Pfister C Schuckmann J Beck Wilson M Wessner The metaphor of virtual rooms in the cooperative learning environment CLear In Cooperative Buildings LNCS 1370 S 107 113 Springer Verlag Berlin Heide
112. edemann Bitsch Hisham Mubarak 5 4 Angemessene herausfordernde und interessante Aufgabenstellung Die Wahl der Aufgabenstellung ist von gro er Bedeutung insbesondere beim Softwaretechnikunterricht fiir Ingenieure Die Aufgabenstellung muss zum einen interessant und anspruchsvoll genug sein um die Teams tiber die Praktikumsdauer zu besch ftigen und die Lernziele zu vermitteln Zum anderen darf sie nicht zu schwer sein da sonst Resignation unter den Studierenden hervorgerufen wird Auch sollte die Aufgabenstellung einen klaren Bezug zum sp teren Berufsbild des Ingenieurs haben und nicht Softwareentwicklung um deren selbst vermitteln Die Realisierung einer Softwaresteuerung f r mobile Roboter und die damit ver bundene Besch ftigung mit der Hardware stellt f r die meisten Studierenden eine span nende und anspruchsvolle technische Aufgabe dar Sie sehen sich vor der Herausforde rung nicht nur die Software des Systems sondern auch Eigenheiten der Hardware zu beherrschen Am IAS wird immer wieder die Erfahrung gemacht dass der Schwierig keitsgrad von den Studierenden meist untersch tzt wird sodass die technische Heraus forderung aus Sicht der Studierenden im Verlauf des Praktikums anw chst 5 5 Soziale Veranstaltungen Soziale Veranstaltungen wie beispielsweise ein Gesch ftsessen sind Teil des Berufsle bens Im Rahmen des Fachpraktikums finden daher zwei Veranstaltungen statt welche die sozialen Kontakte zwischen den Studierenden
113. ee ist eine Kombination von Reverse und Forward Enginee ring Nach unserer Erfahrung k nnen Studierende den Nutzen von Modellierung Qualit tssicherung und wartbarem Code nicht erkennen solange sie nicht mit wirklich gro em Code in Ber hrung gekommen sind Daher entstand die Idee die praktischen bungen mit dem Kennenlernen eines gro en Systems zu beginnen und darauf aufbau end nacheinander die h heren Abstraktionsebenen einzuf hren Dieses Vorgehen hat insbesondere den Vorteil dass Testtechniken schon fr h einge bt werden k nnen da von Anfang Code zur Verf gung steht Weitere Vorteile eines Reverse Engineering orientierten Vorgehens sind in Bot 01 zusammengestellt Genauso wesentlich ist aber dass die Studierenden dann die erlernten Methoden selbstst ndig bei der Entwicklung anwenden Deshalb erhalten die Studierenden in der zweiten H lfte des Semesters die Aufgabe das System um einige Funktionalit ten zu erweitern Die Vorlesung liefert begleitend dazu die notwendigen Inhalte Insbesondere werden in der ersten H lfte die Modellierungstechniken UML und Qualit tssicherungstechniken Review Testen bungswochen Wiederholung Systemtest E Anforderungen f r Erweiterung Inspektion 2 von REQuest Use Cases und Systemfunktionen _ Requirement Engineering Systemtestplan 8 Inspektion E R Diagramme Meilenstein 1 Architektur lt Architektur Architekturdefinition Zustandsdiagramme
114. einer IDE samt Folien und Beamer vor einer Gruppe dabei werden diverse Soft Skills trainiert Und schlie lich besteht die Aussicht dass das Ergebnis einem gr eren Kreis zug nglich gemacht werden k nnte Entsprechend hoch war die Motivation der Teilnehmer an der Teachlet Werkstatt 104 Axel Schmolitzky Ausblick Eine Wiederholung der Veranstaltung ist fiir das Sommersemester 2005 geplant Einige der Teachlets der ersten Veranstaltung werden dabei in berarbeiteter Form erneut zum Einsatz kommen Das Bedienen eines Rechners mit Folien und IDE erfordert viel Aufmerksamkeit die Moderation der fachlichen Diskussion in einer gr eren Gruppe ebenfalls Es w re deshalb denkbar die Moderation im Paar durchfiihren zu lassen Fiir den breiten Ein satz von Teachlets in Lehrveranstaltungen ist dies vermutlich nicht tragf hig f r eine Lehr Werkstatt hingegen schon In einer ersten Runde k nnten die Studierenden neue Teachlets in Paaren ausarbeiten und moderieren und erst bei ihrem zweiten Teachlet allein moderieren 7 Danksagungen Ich danke allen Teilnehmern der ersten Teachlet Werkstatt f r ihre engagierte Mitar beit die das Konzept weiter best tigt hat Meinen Kolleginnen und Kollegen im Ar beitsbereich Softwaretechnik an der Universit t Hamburg danke ich f r einige fruchtba re Diskussionen ber Teachlets und gute Anregungen f r Abwandlungen Den Ansto zur Teachlet Idee verdanke ich Heinz Z llighoven der mir f r einen unerw
115. ektmanagers Er ist ver antwortlich f r die Planung der Ressourcen Studierende Zeit Rechner Systemumgebung Teambetreuer f r die Koordination und f r die Kosten und Zeiterfassung 2 Vier bis f nf Studierende bernehmen die Aufgabe der Entwickler Diese Un tergruppe f hrt haupts chlich die Anforderungserfassung die Systemanalyse den Entwurf die Implementierung und die berarbeitung des Softwaresystems durch 3 Zwei Studierende bernehmen die Aufgabe der Qualit tssicherung Neben der Planung und Durchf hrung von Qualit tssicherungsma nahmen testet die se Untergruppe das Softwaresystem 48 Peter G hner Friedemann Bitsch Hisham Mubarak 4 Ein Studierender bernimmt als Nebenaufgabe die des Schnittstellen verwalters Er hat die Aufgabe f r konsistente Schnittstellen zwischen ver schiedenen Softwaremodulen w hrend der gesamten Projektlaufzeit zu sorgen Die Ergebnisse der Teammitglieder m ssen zusammenpassen Aus diesem Grund ist eine sorgf ltige Schnittstellendefinition zwischen den zu entwi ckelnden Modulen von gro er Bedeutung 5 Ein Studierender ist neben seiner Hauptaufgabe f r das Konfigurations management zust ndig Der Konfigurationsmanager ist f r die Archivierung und die Versionsverwaltung der Dokumentation sowie der Produkte der ein zelnen Entwicklungsphasen verantwortlich Je nach ausge bter Rolle machen die Studierenden sehr unterschiedliche Erfahrungen Da das Fachpraktikum auch von Stud
116. ektplan der drei Phasen vorsah Analyse Designs und Implementierung Abb 2 Projektplan f r das Projekt AutoRAID Abbildung 2 zeigt den Projektplan der den Studierenden vorgeschlagen wurde Die Studierenden orientierten sich an diesem Projektplan und schafften es ihn einzuhalten allerdings mussten sie nach der Abschlusspr sentation noch drei Wochen l nger arbeiten um die Dokumentation nachzureichen Das Team erstellte innerhalb des vorgegebenen Zeitrahmens das fertige Require ments Engineering Werkzeug AutoRAID Aut 04 Das Werkzeug ist integriert in ein am Lehrstuhl entwickeltes Design und Simulationswerkzeug AutoFOCUS Aut 02 das am Lehrstuhl verwendet und best ndig weiterentwickelt wird eine Fallstudie mit AutoRAID in der Industrie ist f r Anfang 2005 geplant 30 Andreas Fleischmann Katharina Spies Katharina Neumeyer 3 Konzeption Lerninhalte und Ablauf des Teamtrainings In diesem Abschnitt stellen wir die Konzeption die Lerninhalte und den Ablauf des Teamtrainings vor 3 1 Konzeption Unsere Zielsetzung bei der Konzeption des Teamtrainings bestand vor allem darin die Bew ltigung der tats chlichen fachlichen Aufgabe Entwicklung von AutoRAID mit dem vorgegebenen Projektplan von Beginn an zielgerichtet zu erm glichen Die Stu dierenden sollten mit Beginn der fachlichen Aufgabe bereits als Team agieren und ber die n tige Zusatzqualifikation speziell zur gemeinsamen z
117. ektteilnehmerInnen erreichbar ist Die EntwicklerInnen sind jederzeit in der Lage von den Modellelementen zu den Kommunikationsstr men und Begr ndungserfassungen zur ck zu navigieren Die Nutzung der Verzahnung von Do kumentenentwicklung und Rational in der Lehre ist beschrieben in Dut 04 Sysiphus wurde f r die Durchf hrung von Softwareentwicklungsprojekten ARENA Cargo Logistic sowie f r die SWE Lehre entwickelt Des Weiteren dient Sysiphus als Grundlage von einzelnen studentischen Praktika und Projekten Da die Project Sysiphus Projects ReqSpec SDD ODD TS Questions Help About REQuest Leaf Section Use Cases sure minimem risk of data 29 04 10 14 AM 2904 10 08 AM 3 26 04 N Abb 2 Screenshot des bearbeiteten Systems studentischen Projekte zeitlich sehr begrenzt sind ist im Allgemeinen eine lange Einarbeitungszeit in das System nicht m glich Deswegen sollten die Studierenden in der Lage sein einzelne Teile des Systems ver ndern zu k n http arena globalse org http wwwbruegge in tum de SeP rakt03 Vom Code zu den Anforderungen und wieder zur ck 61 nen ohne das gesamte System verstehen zu m ssen Dies f hrte zu folgender Schichtenarchitektur siehe Abbil dung 3 REQ RAT LectureAdmi A d wae uest ectureAdmin nwendungsschicht 1 Ss C Swot Modellschicht Y OUa L Element __ GJ Project Kommunikations und e Store U Directory Speicherschicht
118. en In SEUH 01 dpunkt verlag 2001 S 99 108 Lew 01 C Lewerentz H Rust Die Rolle der Reflexion in Softwarepraktika In SEUH 01 dpunkt verlag 2001 S 73 86 Lic 03 H Lichter R Melchisedech O Scholz T Wiler Erfahrung mit einem Workshop Seminar im Soft ware Engineering Unterricht In SEUH 03 dpunkt verlag 2003 S 89 100 Mec 99 A MecLean R M Young V Bellotti T Moran Questions options and criteria Elements of design space analysis Human Computer Interaction 6 11 201 250 1999 Met 03 A Metzger Konzeption und Analyse eines Softwarepraktikums im Grundstudium In SEUH 03 dpunkt verlag 2003 S 41 48 Pae 03 B Paech K Kohler Task driven requirements in object oriented development In J Leite J Doorn eds Perspectives on Requirements Engineering Kluwer Academic Publishers 2003 Rys 99 J Ryser M Glinz Konzipierung und Durchf hrung eines Software Praktikums Ein Erfahrungsbe richt In SEUH 99 Teubner 1999 S 55 68 Spi 01 A Spillner Erfahrung mit einem Werkzeug zur Projektunterstiitzung In SEUH 01 dpunkt verlag 2001 S 45 54 Sys 04 Sysiphus hrtp wwwbruegge in tum de Sysiphus 2004 Wol 04 T Wolf A H Dutoit A Rationale based Analysis Tool In 13th International Conference on Intelli gent amp Adaptive Systems and Software Engineering 2004 IASSE 04 p 209 214 Ein Softwaretechnik Praktikum als Sommerkurs Christian Lindig Andreas Zeller
119. en eine m glichst praxisnahe Projektumgebung zu schaffen die Veranstalter wie echte Kunden auf Hierzu geh ren auch die Abgabe unvollst ndiger Aufgabenbeschreibungen das Setzen von Deadlines und die Forderung nach zus tzlichen Funktionalit ten im fortgeschrittenen Verlauf des Projekts Durch die B ndelung solcher Herausforderungen und die Gr e der Aufgabe entsteht eine vergleichsweise realit tsnahe Situation vgl Tau O1 Gna 03 in der die Studierenden anschaulich die Vielseitigkeit des Berufsbildes eines Software Ingenieurs erleben Verhandeln Diskutieren Organisieren Design Implementieren Testen Dokumentieren Pr sentieren Folglich m ssen die Studierenden neben technischen und fachlichen Herausforderungen auch organisatorische und soziale Probleme meistern Beispiele f r diese unterschiedlichen Probleme sind e Ein technisches Problem ist beispielsweise Wie spielen die Entwicklungs umgebung Eclipse und die Versionsverwaltung CVS zusammen e Ein fachliches Problem ist beispielsweise Soll das Programm in der Situation X mit der Aktion A oder B reagieren Ein organisatorisches Problem ist beispielsweise Ist es m glich die anste henden Aufgaben im Team sinnvoll aufzuteilen e Ein soziales Problem ist beispielsweise Wie gehen wir als Team damit um dass Person X die ihm zugewiesene Teilaufgabe unbefriedigend gel st hat Die Durchf hrung und Betreuung solcher Projekte an den TU s
120. en die der Wieder Nutzung von Erfahrungen im Wege stehen Werk zeuge helfen dabei kaum Dies deckt sich mit Erkenntnissen bei DaimlerChrysler und hat wiederum Konsequenzen auf die Gestaltung dennoch n tzlicher Werkzeuge Sch 01 Wir sehen Werkzeuge nur als einen eher kleinen Mosaikstein im gr eren Zusam menhang der systematischen Erfahrungsnutzung Sie werden hier haupts chlich er w hnt um auf diese Tatsache hinzuweisen 6 Diskussion und Schlussfolgerungen In diesem Beitrag habe ich vier unterschiedliche Verfahren vorgestellt um im Rahmen des Informatik Studiums gezielt und ausdr cklich Erfahrungen nicht Wissen zu ver mitteln W hrend SESAM die Agile Hour und das Software Projekt mit gezielten In terventionen auch dazu beitragen Erfahrungen aufzubauen erheben wir mit dem Werk zeug diesen Anspruch nicht Hier geht es nur um die Verteilung von bestehenden Erfahrungspaketen Da Erfahrung nach der obigen Definition aber eigene Beobachtung Gef hle und Hypothesen einschlie t kann das Werkzeug kaum Mehrwert stiften alles h ngt von den Erfahrungspaketen selbst ab In Tabelle 1 ist gegen bergestellt ob und wie die vier Ans tze die drei Definitionsbestandteile von Erfahrungen an die Teilneh mer vermitteln Tab 1 Vergleich der vier Verfahren Wodurch werden die Erfahrungsaspekte umgesetzt Erfahrungsaspekt SESAM Agile Hour SWPO4 Werkzeug Eigene Beobach Reaktion des simu Verhalten der Besonders bewusst entf l
121. en die selbst in der Praxis Software Engineering betrieben haben oder betreiben Eine Umsetzung dieser Kriterien ist nicht nur in Praktika m glich Ein sch nes Beispiel ist das von Lichter beschriebene Workshop Seminar Lichter2003 Mit der Praxisn he ergeben sich auch viele M glichkeiten der Motivation Wenn zudem das Lernziel professionelle Softwareentwicklung ist liegt es nahe auch die dort ange wendeten Managementtechniken zu Motivation und F hrung in der Lehre einzusetzen Mangelnde oder heterogene Vorkenntnisse sind in jeder Lehrveranstaltung problema tisch Bei Ausbildungsformen mit Teamarbeit ist das Problem einerseits versch rft indem fehlende Vorkenntnisse einzelner Studierender den Erfolg ganzer Teams gef hr den k nnen Andererseits besteht speziell im Software Engineering das st rendste Defi zit zumindest nach unseren Erfahrungen in Z rich meist bei den Programmierkennt nissen Da Programmierung im Softwareentwicklungsprozess erst weiter hinten kommt 14 Robert Stoyan Martin Glinz er ffnet sich die M glichkeit fehlende Programmiervorkenntnisse gezielt auszuglei chen Gleichzeitige Vermittlung von Theorie und Praxis tr gt ebenfalls zum Ausgleich fehlender oder heterogener Vorkenntnisse bei Leistungskontrolle birgt im Software Engineering eine besondere Herausforderung da unterschiedlichste F higkeiten gelehrt werden in denen die Leistung nicht auf dieselbe Art gepr ft werden kann Theoretisches Wisse
122. en wie sie typischerweise heute an den Universit ten gelehrt und gelernt wird W hrend die iterative und inkrementelle Vorgehensweise XP weitgehend auf Dokumentation verzichtet soll in der konventionellen Vorgehensweise das Verst ndnis des Entwicklerteams von der Aufgabe und ihrer L sung durch ein gemeinsam erstelltes ausf hrlich dokumentiertes Modell erreicht werden das heute meist in UML BRJ99 notiert wird Bei XP dient der Code selbst als Dokumentation Dem UML basierten Vorgehen liegt die Vorstellung zugrunde dass wenn man das Problem nur gut genug analysiert und die L sung genau genug spezifiziert die Umsetzung des Modells in ein Programm ganz einfach wird und sich fast von allein ergibt Es werden m chtige Werkzeuge eingesetzt die aus Modellen Code Rahmen erzeugen in denen nur wenige Zeilen Code erg nzt werden m ssen Bei XP dagegen ist der Stellenwert der Programmierung als Entwicklungst tigkeit und die Qualit t des erzeugten Codes besonders hoch Gute Teamarbeit und die Integration des Kunden in den Entwicklungsprozess werden als Grundlage f r erfolgreiche Projekte angesehen Erfahrungen mit XP 115 Um die Vor und Nachteile alternativer Vorgehensweisen bei der Softwareentwicklung klarer erkennen zu k nnen wurde in studentischen Projekten im Rahmen des Software Praktikums SoPra an der Universit t Dortmund und auf der Informatica Feminale IF der Bremer Sommerschule f r Informatikerinnen www informatica feminale de
123. en Teil der Arbeit automatisieren konnten bleibt die Organi sation eines solchen Praktikums nicht trivial Neben den Tutoren waren Dozent und drei wissenschaftliche Mitarbeiter ber zehn Wochen Vollzeit eingespannt und das bei weitgehend vorgegebener Aufgabenstellung Die sechsw chige Durchf hrung ben tigt eine fast ebenso lange Vorbereitungsphase in der die Aufgabenstellung geschrieben 78 Christian Lindig und Andreas Zeller eine oder zwei Referenzimplementierungen erstellt und die technische organisatorische Infrastruktur Praktomat Tutorials Installation von Software vorbereitet wird Tutoren sollten keinen Einfluss auf die Benotung haben So k nnen sie allein mit ih rer Erfahrung Ratschl ge geben die von den Gruppen besser angenommen werden 8 Evaluation Trotz der Umstellung lief das Praktikum problemlos Wir freuen uns dass wir die Risi ken eines 6 Wochen Praktikums erfolgreich reduzieren konnten und das bei hoher Erfolgsquote e Alle Gruppen haben fristgerecht den Meilenstein der Entwurfsphase erreicht und einen tragf higen objektorientierten Entwurf abgeliefert e Alle Gruppen haben fristgerecht den Meilenstein der Implementierungsphase erreicht und eine Implementierung abgeliefert die alle Tests bestanden hat e Alle Gruppen hatten bereits f nf Tage vor Praktikumsende den Meilenstein der Einsatzphase erreicht und somit das Praktikum erfolgreich abgeschlos sen Alle Gruppen bedeutet nic
124. er Demo Steuerung per Tastaturbefehle gesteuert werden Ein Simulator erlaubt das Testen der Software ohne Einsatz der realen Roboter Die Robo ter des Simulators verhalten sich im Gegensatz zu den realen Robotern weitgehend ide al Dadurch lernen die Studierenden m gliche Unterschiede von Simulationen und rea len technischen Prozessen sowie dadurch entstehende Probleme kennen 4 Aspekte der Projektarbeit als Lernziele Die Lernziele des Fachpraktikums gliedern sich in folgende Bereiche e Teamarbeit Gebrauch von Englisch zur Kommunikation in der Teamarbeit Zusammenarbeit in multikulturellen Teams e Projektmanagement e Methodische Softwareentwicklung e Qualit tssicherung e Konfigurationsmanagement e Zeitmanagement Softwaretechnik live im Praktikum zur Projekterfahrung 47 4 1 Teamarbeit Das Hauptlernziel des Praktikums ist das Erlernen und Erleben von Teamarbeit vor dem Einstieg in das Berufsleben F r die Teilnehmer am Fachpraktikum ist Gruppenarbeit vielfach ein neues Thema Die Studierenden m ssen die Zusammenarbeit im Team selbstst ndig organisieren Sie sollen lernen mit Problemen umzugehen die sich bei der Teamarbeit ergeben und ein effizientes Zusammenarbeiten ein ben Problematisch kann beispielsweise die Kommunikation im Team sein Zum einen haben die einzelnen Gruppenmitglieder einen unterschiedlichen Kenntnisstand Zum anderen kann es per s nliche Zuneigungen und Abneigungen geben Auch muss die Frage nach d
125. er Seminar teilnehmer ber Beurteilungsb gen erfragen Die Teilnehmer f llen in beiden H usern nach Seminarende diese Papier B gen aus der Dozent sammelt sie anschlie end ein Verdichtungen der Abgaben oder statistische Trends k nnen nur mit hohem manuellem Aufwand erstellt werden Aus dieser Problemstellung heraus entstand nun die Idee f r ein System das online die Erfassung des Fragebogens f r die Seminarteilnehmer er m glicht Die ausgef llten Frageb gen werden in einer Datenbank gespeichert und k nnen dort f r verschiedene Abfragen genutzt werden Systeme dieser Art waren am Markt praktisch nicht verf gbar oder hatten deutliche M ngel Nachdem die Idee grob fixiert war wurden die wesentlichen Anforderungen an ein solches System vergleichbar einem Lastenheft gemeinsam mit den Kunden erhoben Es wurde eine Grob Architektur entworfen und eine Aufwandssch tzung vorgenom men In dieser Phase waren noch keine Studenten beteiligt Es zeigte sich schnell dass der Aufwand zur Realisierung deutlich ber dem vorgesehenen Rahmen des Software praktikums lag Aus diesem Grunde wurde das Gesamtsystem in drei Komponenten aufgeteilt eine Komponente zur Erfassung der Fragebogen Schablone eine Web Server Komponente zur Anzeige und Erfassung der Frageb gen und eine Auswertungs Komponente Damit hatten nicht alle Gruppen des Softwarepraktikums die gleiche Auf gabenstellung der Umfang war aber in etwa gleich 2 3 Durchf hrung
126. er Zeitplan f r das Projekt wird durch die zwei Iterationen allerdings knapp ein Vorgehen mit mehr als zwei Iterationen hal ten wir daher unter diesen Rahmenbedingungen f r nicht durchf hrbar Ein externer Kunde wirkt auf die Studenten stark motivierend Sie erfahren dass ih re Arbeit gebraucht wird und gute Ergebnisse gesch tzt werden Dazu geh rt auch dass das Produkt tats chlich eingesetzt und gewartet wird 4 Zusammenfassung Zusammenfassend ergibt sich f r die externen Partner ebenso wie f r die Studenten eine win win Situation F r wenig Aufwand und Kosten erh lt der externe Partner ein ma geschneidertes Produkt Die Studenten erleben echte Kundengespr che und sind durch die Perspektive dass ihre Ergebnisse verwendet werden angespornt Wich tig ist auch der Spa faktor den die Studenten berwiegend in den Befragungen an gegeben hatten Die Betreuer haben zwar einen etwas h heren Aufwand daf r entstehen aber Kon takte in die Industrie die vielf ltig weitergenutzt werden k nnen Als notwendig erach ten wir ausreichend Vorlaufzeit um die externen Kunden zu gewinnen und die Aufga benstellung zu kl ren Die Erfahrung mit den Resultaten aus Grundstudiums und aus Hauptstudiumspro jekten sind unterschiedlich Die Ergebnisse aus den Grundstudiumsprojekten k nnen als Prototyp oder f r einen Testbetrieb durchaus dienen die Codequalit t wird aber f r eine l ngerfristige Investition nicht tragf hig sein
127. er der Wissens vermittlung ist f r SWE unverzichtbar da SWE sich nur durch praktische Anwendung der Methoden und Techniken erlernen l sst vgl Ble 99 Rys 99 Um den Studierenden einen gewissen wenn auch k nstlich erzeugten industriellen Projektkontext zu geben wurden die Aufgaben in kleine Szenarien eingebettet Die Szenarien beschreiben einen Katastrophenfall in einer Softwarefirma bei dem aufgrund eines Hardwareproblems die wichtigsten Entwicklungsdokumente zerst rt worden sind und nachtr glich wieder erzeugt werden m ssen Dabei schl pften die Studierenden in Vom Code zu den Anforderungen und wieder zur ck 63 die Rolle neuer Angestellte in einer Softwarefirma die sich in das bereits vorhandene System Sysiphus einarbeiten m ssen Nachfolgend ist ein Beispiel einer solchen Szena riobeschreibung aus dem bungsblatt zum Thema Entwurfsmuster eingef gt Um einige wichtige Dokumente aus dem Projekt nachtr glich wieder erzeugen zu k n nen hatte unsere Firma eine Gruppe von Fachinformatikern in Ausbildung zu uns eingeladen Die Aufgabe dieser Gruppe war es aus den wichtigsten Quellcodestellen einige Klassendiagramme zu erzeugen Die Fachinformatiker waren zwar alle Experten auf dem Gebiet der Programmiersprache Java aber leider hatten sie sehr wenig Erfah rung mit Klassendiagrammen Sie kannten kaum Entwurfsmuster die h ufig in unserer Firma eingesetzt werden Daher waren die Diagramme inhaltlich korrekt aber die Entwurfs
128. er im Team verwendeten Sprache gekl rt werden Nicht immer sprechen alle Teammitglieder eine gemeinsame Muttersprache Den Studierenden wird vermittelt dass f r eine gute Teamarbeit das Arbeitsklima entscheidend ist welches wiederum durch die Gruppenmitglieder gepr gt wird Eine gewisse Kritikfestigkeit wird von jedem Gruppenmitglied gefordert ebenso wie Sensibi lit t beim Kritik ben Eine weitere Schwierigkeit mit der die Studierenden konfrontiert werden ist bei wichtigen Fragestellungen in der Projektorganisation oder Entwicklung gemeinsame Entscheidungen zu treffen Dabei m ssen unterschiedliche Ansichten zun chst toleriert werden In der Diskussion m ssen die Teammitglieder dann eine L sung finden die f r das Team annehmbar ist Viele der Studierenden bewerten die dabei gewonnenen Er fahrungen als u erst wertvoll da die Auseinandersetzungen im Team zu einer sehr intensiven Befassung mit Gruppenarbeit und der Aufgabenstellung f hrt Die Studierenden sollen lernen selbstst ndig zu handeln und Ideen sowie Vorschl ge in ihr Team einzubringen Bevor die Betreuer um Hilfestellung gebeten werden versuchen die Teams Fragen und Probleme alleine zu kl ren und zu bew ltigen Die Teams definieren zu Beginn des Fachpraktikums die Rollen mit den zugeh ri gen Aufgabenbereichen Als Hilfestellung wird den Studierenden folgende Rollenver teilung empfohlen vgl LaG 99 S 13 1 Ein Studierender bernimmt die Aufgabe des Proj
129. er semesterbegleitenden Form mit diversen Kunden und Aufgaben und einem sechsw chigen Kurs ohne Kunden und ein heitlicher Aufgabe ist gewaltig Deswegen ist es nicht immer einfach die Faktoren fiir den Erfolg der neuen Form zu benennen Einen interessanten Vergleichspunkt zwischen diesen Extremen bietet das Softwarepraktikum der TU Kaiserslautern M04 Das Praktikum in Kaiserslautern ist semesterbegleitend hat aber ansonsten viele Merkmale unseres neuen Praktikums eine einheitliche Aufgabe Ampelsteuerung eine Modellierungsphase mit UML die fr he Erstellung von Testf llen Gruppen von 6 Stu dierenden und ein abschlieBender Wettbewerb Metzger berichtet in M04 von einem insgesamt erfolgreichen Verlauf gegen ber einem fr heren Praktikum einem engeren und besseren Notenspektrum und einer positiven Evaluierung Dies deckt sich mit unse rer Erfahrung dass eine einheitliche Aufgabe die Vergleichbarkeit von Leistungen f r dert und der risiko rmere Verlauf zu gr eren Erfolgen der Teilnehmer f hrt Wegen der hnlichkeit zu unserem Praktikum sind die von Metzger beobachteten Probleme interessant 45 der Teilnehmer klagten ber einen sehr hohen Arbeitsauf wand au erdem sahen sich die Organisatoren gezwungen Pr senzzeiten einzuf hren da Studierende dazu neigten zu Hause zu arbeiten und dort nicht zu betreuen waren Das Problem der Arbeitsbelastung durch Konflikt mit anderen Verpflichtungen deckt sich mit unseren fr heren Erfahru
130. erenden dass sie das System was sie weiterentwickeln auch selbst anwenden und umgekehrt Dies hat den Vorteil dass sie sich gut in die Rolle der Nutzer versetzen k nnen und aufgrund ihrer Erfahrungen motiviert sind das Sys tem kennen zu lernen und weiterzuentwickeln Der Nachteil ist allerdings dass sie diese Nutzerrolle erst im Laufe der Vorlesung durch die Behandlung der einzelnen Techniken wirklich kennen lernen d h dass die Anwendungsdom ne nicht von Anfang gut be kannt ist Dar ber hinaus besteht die Gefahr der Verwirrung da die Ebene der Anwen dung d h das Ein ben des Werkzeugumgangs nicht klar getrennt ist von der Ebene der Entwicklung d h das Ein ben der SWE Techniken Die Erfahrungen dazu werden im Abschnitt 4 diskutiert Um den Studierenden den Einstieg in die Programmiersprache Java zu erleichtern setzen wir das IDE Eclipse Ecl 04 ein Weiterhin wird JUDE Jud 04 f r die Erstel lung von UML Diagrammen verwendet Verteiltes Arbeiten wird durch CVS erm g licht Als Kriterien f r die Auswahl sind insbesondere die freie Verf gbarkeit und die Plattformunabh ngigkeit der einzelnen Werkzeuge zu nennen 3 Ablauf Das SWE Fachwissen wurde den Studierenden in einer w chentlich stattfindenden Vorlesung am Montagvormittag 2 SWS vermittelt Die Anwendung des dort erworbe nen Wissens stand im Mittelpunkt der bungsstunden am Montagnachmittag 2 SWS und Dienstagmittag 2 SWS Dieser hohe Anteil der Praxis gegen b
131. ersichtlich sein was als N chstes zu erledigen ist Wir werden im Folgenden Kooperation als Oberbegriff f r diese drei Begriffe benutzen Um die genannten Probleme in den Griff zu bekommen haben wir eine einheitliche Entwicklungsplattform auf der Grundlage von Eclipse entwickelt Diese beinhaltet s mtliche Werkzeuge die f r die entfernte Entwicklung von Softwareprojekten n tig sind Dazu wurden bestehende Werkzeuge in die Eclipse Plattform integriert und einige weitere Programmteile hinzugef gt die daf r sorgen dass das Konglomerat verschie denster Werkzeuge reibungslos zusammenarbeiten kann Von unserer Plattform k nnen auch Pr senzuniversit ten profitieren da die meisten der hier genannten Probleme der Softwaretechnik Lehre auch dort auftreten Der Rest dieser Diskussion ist wie folgt aufgebaut Abschnitt 2 stellt einen ber blick ber die aktuelle Situation in der Softwaretechnik Lehre dar Es wird dabei beson Eine Plattform f r die Softwaretechnik Fernlehre 83 ders auf die Probleme eingegangen die wir mit unserer Plattform l sen In Abschnitt 3 werden die Komponenten unserer Plattform genauestens beschrieben Abschnitt 4 gibt einen Ausblick ber die Dinge die noch zu erledigen sind w hrend der Artikel schlie lich mit Abschnitt 5 zusammengefasst und abgeschlossen wird 2 Softwaretechnik Lehre heute Studierende der Informatik erlernen heutzutage bereits im Grundstudium das Schreiben eines Programms in mindestens e
132. erung Entwurfsmuster Archi tekturmuster und Dokumentation Ab der zweiten Woche fand die begleitende Vorle sung zweimal w chentlich statt mit dann implementierungsorientierten Themen wie Unit Tests Refactoring Qualit tssicherung oder Fehlersuche Zum Ende des Prakti kums war keine Vorlesung mehr n tig Man bemerke dass solch unregelm ige Vorle sungstermine in der Vorlesungszeit nur schwer durchzuf hren sind so ist es kaum m glich den gr ten H rsaal f r alle Vormittage der ersten Semesterwoche zu requi rieren Insgesamt haben wir die Vorlesung auf den Fortschritt im Praktikum abgestimmt einerseits zeitlich aber auch inhaltlich Wir vermitteln das Material was die Studieren den f r das Praktikum brauchen und sonst nichts Anders gesagt Die Vorlesung richtet sich nach dem Praktikum und nicht umgekehrt Anforderungsanalyse Prozessmodelle Spezifikation Zertifizierung nach ISO 9000 Management von Softwareprojekten all dies sind wichtige Themen der Softwaretechnik aber in unseren Augen erst dann gut vermittelbar wenn die Teilnehmer die Probleme des Programmierens im Gro en selbst erlebt haben Daher behandeln und ben wir diese Stoffe in einer Stammvorlesung Softwaretechnik ab dem 4 Semester In einem kurzen Praktikum muss man genau das unterrichten was die Studierenden zum Erf llen der Aufgabe ben tigen Ein Software Praktikum als Sommerkurs 73 5 Eine spielerische Aufgabenstellung In je
133. erung erstellt wurde Einheitliche testbare Erfolgskriterien Es muss ein faires und weitgehend automatisierbares Verfahren geben um den Erfolg festzustellen Dies be stimmt maBgebend die Wahl der Aufgabenstellung Inhalt statt Oberfl chen Gut gestaltete grafische Oberfl chen GUIs k n nen mehr als die H lfte der Implementierungsarbeit ausmachen sind aber gleichzeitig schwer zu testen und im Hinblick auf Ergonomie nur aufw ndig zu bewerten F r ein 6 Wochen Praktikum k nnen GUIs daher nur optionale Teile sein Ein einheitlicher detailliert geplanter Praktikumsablauf minimiert Risiken 4 Ablauf des Praktikums Um die in Abschnitt 3 aufgef hrte Struktur umzusetzen haben wir das Praktikum in drei Phasen aufgeteilt dargestellt in Abbildung 1 Zu Beginn erhalten die Studierenden ein einheitliches fertig ausgearbeitetes Pflichtenheft mit vollst ndig automatisch testbaren Anforderungen In den ersten zwei Wochen soll das System entworfen werden Bereits nach einer Woche muss das UML Objektmodell Klassen und ihre Beziehungen stehen Meilenstein nach einer weiteren Woche ist der vollst ndige Entwurf der neben einem berarbeiteten Objektmodell eine Reihe von Standard Szenarien mit Sequenzdiagrammen und Unit Tests beschreibt Alle Entw rfe werden in Kolloquien mit den Gruppen durchgesehen Nach abgeschlossenem Entwurf wird ein berarbeitetes Pflichtenheft ausge geben in dem sich einige Details ge ndert haben
134. etzt ber Test First hatten wir einen kurzen Vortrag vorbereitet danach haben wir es gemeinsam am Beamer ausprobiert Auch dabei haben wir mit Tool Unterst tzung gearbeitet JUnit und Refactorlt lassen sich in die eingesetzte Entwicklungsumgebung Together integrieren 3 Erfahrungen mit XP im Gegensatz zum UML basierten Vorgehen Wir stellen einige unserer Erfahrungen vor die wir bei Beobachtungen und bei Befragungen der TeilnehmerInnen mit Hilfe von Frageb gen gewonnen haben Dabei wurden wir von der Abteilung Organisationspsychologie der Universit t Dortmund unterst tzt Besonders interessierte uns in unseren Experimenten der Einfluss bestimmter Konzepte die teilweise im Gegensatz zu der bisher praktizierten UML basierten Vorgehensweise Schm01 stehen auf den Lernprozess In der Industrie werden auch viele andere Vorgehensmodelle z B das V Modell erfolgreich eingesetzt die mit dem hier beschriebenen UML basierten Vorgehen die zentrale Stellung des Modells und die Wichtigkeit der erzeugten Dokumente gemeinsam haben Erfahrungen mit XP 117 3 1 Paararbeit Bei der Paararbeit wird immer zu zweit an einem Rechner gearbeitet eine tippt ein anderer kontrolliert fragt nach und liefert Ideen Bereits w hrend der Implementierung findet ein erstes Code Review statt So sollen Fehler vermieden und durch bessere Lesbarkeit und Verst ndlichkeit soll die Qualit t des Codes gesteigert werden In einer Lehrveranstaltung f rdert Paararbeit
135. f angepasst erweitert und dann implementiert Das Handbuch wurde w hrend der zweiten Iteration erstellt Die Qualit tssicherung erfolgte durch interne Reviews aller Dokumente einschlie lich Codeaudits Reviews mit dem internen Kunden und den Betreuern und durch Test des Systems Codeaudits wurden eingesetzt weil sich Schwierigkeiten beim Unit Test herausstellten Ein umfangreicher Systemtest wurde vor dem Ende jeder Iteration durchgef hrt Die Abnahme erfolgte jeweils zuerst durch den internen Kunden und die Betreuer dann durch die Pilotkunden 3 6 Ergebnisse des Projekts Das Projekt wurde erfolgreich durchgef hrt Alle Meilensteine wurden zum geplanten Termin erreicht Der Aufwand lag um rund 20 ber den vorgesehenen 4000 Entwick lerstunden aber im Rahmen des durch Kostensch tzung ermittelten und geplanten Auf wands Bereits nach der ersten Iteration zeigte sich eine hohe Brauchbarkeit des Produkts diese Einsch tzung best tigte sich bei Projektende Beide externen Kunden setzen das Produkt derzeit ein Das System wurde bereits erweitert die Wartbarkeit des Produkts wurde dabei vom Wartungsentwickler als sehr gut eingesch tzt 3 7 Einsch tzung des Projekts durch die Studenten Im Anschluss an das Studienprojekt wurde ebenfalls eine empirische Untersuchung ber die Einsch tzung des Projekts durch die Studenten durchgef hrt Es konnten 9 von 10 am Projekt beteiligte Studenten befragt werden Alle befragten Studenten machte
136. f ist dar ber hinaus Erfahrung erforderlich und Erfahrung schlie t eigenes Erleben und dadurch erzeugte Gef hle ein Wie kann aber Erfahrung in diesem Sinne vermittelt werden Schon lange werden verschiedene Praktikumsformen diskutiert die dies leisten sollen Im vorliegenden Beitrag stelle ich vier Ans tze zur gezielten Vermittlung von Erfah rungen kurz vor Sie werden danach verglichen und auf ihre Tauglichkeit f r die Software Engineering Lehre hin diskutiert 1 Einf hrung Im Software Engineering gibt es zahlreiche Techniken und Methoden die Studenten einfach kennen m ssen Dieses Wissen zu vermitteln ist eine Aufgabe der Software Engineering Lehre Aber solches Wissen reicht bekannterma en nicht aus um prakti sche Projekte zu bearbeiten Vielmehr sind Fertigkeiten und Erfahrungen erforderlich die das Wissen erg nzen m ssen Software Engineering insgesamt und mehrere seiner Teilgebiete haben einige Ei genschaften die f r besonders erfahrungslastige Disziplinen typisch sind Sch 02 e Technisches Wissen und wirtschaftlich pragmatisches Urteilsverm gen m s sen zusammenkommen e Die Rahmenbedingungen und Traditionen der Anwender sind zu beachten Das scheinbar Optimale ist nicht immer vermittelbar e Es gibt keine klaren Kriterien f r eine beste L sung Gangbare L sungen m ssen in der Diskussion erarbeitet werden Vier Formen der Erfahrungsvermittlung im Studium 17 Zum Beispiel braucht ein Software Arc
137. fehlendes Vorwissen aufgearbeitet wird Pairprogramming Dieses Prinzip vom eXtreme Programming Beck2000 sieht vor dass zwei Entwickler gemeinsam an einem Rechner programmieren Der eine hat die Tastatur und erkl rt was er tut der andere fragt nach und gibt Feedback Ein Se mester lang angewendet wird es helfen Unterschiede auszugleichen ein bis zwei Pairprogramming Sitzungen haben eine normierende Wirkung Jeder wei nachher wo das Gruppensoll liegt Im SoPra war die Reaktion der Teilnehmer auf Pairprogramming leicht positiv Schlechte Programmierer sind interessiert daran einzelne gute haben Spa am Lehren Die Mehrheit der guten empfindet es als kleine Last Theorie und Praxis zusammen lehren Bei theoretischen Kenntnissen ist es das Beste diese gleichzeitig mit dem Praktikum zu bieten so werden zum Beispiel bei Kerer2004 Praktikum und Vorlesung zum selben Thema im gleichen Semester gehal 10 Robert Stoyan Martin Glinz ten Oft geht dies jedoch aus stundenplantechnischen Griinden nicht Ein weiteres Prob lem ist dass zu Beginn noch zu wenig des erforderlichen Basiswissens verfiigbar ist An der Universit t Z rich erwerben die Studierenden das Grundwissen in Form ei ner zweist ndigen Vorlesung ber Software Engineering im Semester vor dem SoPra Um dieses Wissen wieder in den Vordergrund zu holen und mit dem notwendigen Spe zialwissen zu erg nzen verwenden wir im SoPra ein angeleitetes Literaturstudium und haben damit g
138. g ist eine erfolg reiche Teilnahme an der Informatik I Grundvorlesung die die Grundlagen der Objekt orientierung und der Programmiersprache C vermittelt Ein Vorwissen auf dem Ge biet des SWE ist bei den TeilnehmerInnen so gut wie nicht vorhanden Vom Code zu den Anforderungen und wieder zur ck 57 Die Ziele der Lehrveranstaltung stimmen mit den in Lic 03 beschriebenen Zielen berein d h Vermittlung von gesichertem Fachwissen im Bereich SWE Anwenden des Fachwissens an realit tsnahen Problem und Aufgabenstellungen Reflexion ber die Anwendung des Fachwissens und praxisnahe Ausbildung der Studierenden durch Kennenlernen von industriell benutzten Methoden Sprachen und Werkzeugen der ebenfalls genannte Einbezug der Industrie war nicht beabsichtigt Aufgrund der K rze der Zeit liegt der Schwerpunkt in den praktischen bungen auf dem eigentlichen Entwicklungszyklus d h Softwarekontextgestaltung Require ments Engineering Architekturdefinition Feinentwurf und Implementierung Dabei sollen insbesondere auch die Qualit tssicherungsma nahmen der einzelnen Phasen erlernt werden Das umfasst die verschiedenen Arten sowohl des dynamischen als auch des statischen Testens Weiterhin ist auch die Vermittlung der Soft Skills Lic 03 Lew O1 ein Anliegen In den SEUH B nden finden sich viele Vorschl ge und Konzepte wie SWE Inhalte vermittelt werden k nnen Die meisten dieser Vorschl ge beziehen sich allerdings auf Veranstalt
139. g und Entwicklung war nicht so gro wie bef rchtet Allerdings waren die Studierenden mit dem Usability Test am Anfang berfordert da sie zu wenig von der Dom ne SWE wussten Bei der n chsten Durchf hrung sollen die Studierenden zuerst explorativ mit dem System umgehen bevor sie einen systematischen Usability Test durchf hren Wie oben erw hnt mussten einige der bungen die f r den ersten Teil des Semes ters geplant waren in die zweite H lfte verschoben werden Die anf ngliche Bef rch tung dass dadurch f r die Studierenden nicht gen gend Zeit bleiben k nnte das erwor bene Wissen noch einmal zu ben vor der Durchf hrung der nderungsaufgabe er wies sich als unbegr ndet Sysiphus hat sich als Werkzeug bew hrt da es problemlos die Bearbeitung der glei chen Aufgabe in verschiedenen Teams unterst tzt so dass einerseits in jedem Team eine gemeinsame Version zur Verf gung stand und andererseits z B bei Ergebnispr sentationen online zwischen den Versionen gewechselt werden konnte Die Rationale F higkeiten des Werkzeugs haben sich bew hrt um den Studierenden bei der Einarbeitung Zusatzinformation zur Verf gung zu stellen z B verschiedene Architekturalternativen und Begr ndungen f r die Auswahl der spezifischen Architek 66 Barbara Paech Lars Borner J rgen R ckert Allen Dutoit Timo Wolf tur Sie wurden aber nicht zur Kommunikation zwischen den Studierenden genutzt Im Laufe des Semesters wurde deutlich
140. geht es nicht darum neue Erfahrungen zu machen sondern bestehende Erfahrungen an andere Studierende weiterzugeben Wir haben die Technik LIDs Sch 00 verwendet um mit wenig Aufwand den Studentenprojekten Erfahrungen zu entlocken Die Erfahrungen sollen nun k nftigen Projektgruppen zugute kommen Dazu werden sie in ein Internet Werkzeug gesteckt das in einer Bachelor Arbeit entwickelt wurde Lir 04 Besonders interessant ist dass Leser die dort stehenden Erfahrungsberichte im Stil von Amazon oder eBay bewerten k nnen So erhalten Autoren und k nftige Leser eine schnelle Ein sch tzung ber den Nutzen eines solchen Berichts der oft Erfahrungspaket hei t Erfahrung a a x Pig Abb 4 Erfahrungsweitergabe mit Werkzeug ist schwieriger als man denkt Vier Formen der Erfahrungsvermittlung im Studium 23 Derlei Werkzeuge werden gerne entwickelt wo Erfahrungen vermittelt werden sollen Meiner berzeugung nach sind zwar Werkzeuge f r die Verteilung n tig aber sie stellen das kleinste Problem dar Es gelingt nur mit gro er M he den Erfahrungscha rakter eigene Beobachtung Gef hl ber ein schriftliches Erfahrungspaket zu trans portieren egal wie elegant das Werkzeug daf r ist Diese Ansicht wird von vielen anderen geteilt die Erfahrungsvermittlung nicht haupts chlich als Werkzeugproblem sehen z B Bar 99 In Sch 02 habe ich eine ganze Reihe von Missverst ndnissen und H rden beschrieb
141. gen heraus haben wir beschlossen das Praktikum rundzuerneuern und komplett neu zu organisieren http www st cs uni sb de edu sopra 2004 70 Christian Lindig und Andreas Zeller 2 Sechs Wochen Vollzeit Unsere erste und wesentliche Entscheidung war das Praktikum vom sonstigen Vorle sungsbetrieb zu trennen und in der vorlesungsfreien Zeit Semesterferien zu veran stalten Hierf r gibt es eine Reihe von Gr nden Inder vorlesungsfreien Zeit gibt es keine Konflikte mit anderen Vorlesungen oder sonstigen Verpflichtungen e Studierende ben tigen die vorlesungsfreie Zeit nicht zur Pr fungsvorberei tung da im Bachelor Studiengang alle Pr fungen studienbegleitend stattfin den e Studierende k nnen in der Vorlesungszeit anstelle des weggefallenen Prakti kums weitere Veranstaltungen besuchen was die Studiendauer verk rzt Die vorlesungsfreie Zeit im Sommer umfasst etwa drei Monate Wir g nnen den Stu dierenden sechs Wochen f r Urlaub und andere Aktivit ten womit sechs Wochen f r das Praktikum zur Verf gung stehen Dies bedingt dass das Praktikum in Vollzeit ab solviert werden muss f r Studierende wie Betreuer Vollzeit hat f r die Studierenden viel Gutes da sie den ganzen Tag vor Ort sind und sich so die Teams ganz auf die Auf gabe konzentrieren k nnen Auch Betreuer und Dozenten kommen zu kaum etwas an derem was allerdings in der folgenden Vorlesungszeit ausgeglichen wird Im kommen den Winterseme
142. hen alle dass gute Arbeit erkannt und belohnt wird Arbeitstausch Wenn Teams ihre Zwischenergebnisse tauschen und so weiterarbei ten sollen erleben sie pers nlich wie wichtig Verst ndlichkeit von Konzeption bzw Code ist In dem Praktikum Carls1993 entwickelten die Teams kooperativ Teile einer Software hier steigerte es die Motivation Insbesondere bei konkurrierenden Teams wird der Tausch von Arbeitsergebnissen wie wir es im SoPra fr her praktiziert hatten jedoch leicht zum Motivationskiller Wozu haben wir uns dann angestrengt wenn man uns unsere Ergebnisse wegnimmt Tutoren m ssen zur Lehrveranstaltung stehen Selbst ein noch so kleines Nase r mpfen der Tutoren zu den didaktischen Methoden oder den Inhalten der Lehrveran staltung sp ren die Teilnehmer sofort und das unterminiert die Glaubw rdigkeit und damit die Motivation Daher soll einerseits im Vorstellungsgespr ch beobachtet wer den ob die Bewerber f r Tutorate wirklich den Sinn der Lehrveranstaltung verstehen Andererseits soll ihnen Gelegenheit zu Kritik und Verbesserung gegeben werden So geh rt es im SoPra zur Schulung der Tutoren diese hierzu zu befragen und ihre Punkte dort wo m glich auch gleich in das Praktikum einzubauen Auch kann das w chentliche Vorbereitungstreffen der Tutoren bewusst als Gelegenheit zum Dampf ablassen ge nutzt werden Diese psychohygienische Ma nahme hilft ihren Frust dorthin zu lenken wo er hingeh rt zum Praktikum
143. hitekt diese F higkeiten um zu einer befriedi genden L sung zu gelangen Aber auch Qualit tsbeauftragte m ssen beurteilen k nnen welche Ma nahmen durchsetzbar sind Nahe liegend mag scheinen Studierende in echte Projekte in Wirtschaftsunternehmen zu stecken damit sie dort ihre Erfahrungen machen Diese gute Idee hat aber leider auch einige Nachteile e Nicht an jedem Hochschulstandort sind auf Dauer ausreichend viele Prakti kumspl tze vorhanden Firmen scheuen oft davor zur ck st ndig f r wenige Wochen neue Praktikanten einzulernen e Die Pflicht einen Praktikumsbericht zu schreiben ersetzt nicht Betreuung und bietet kaum Unterst tzung zur eigenen Reflexion Es kann also durchaus gelingen dass Studierende zwar in der Praxis arbeiten und dort auch an Vorg ngen teilhaben die durchaus typisch sind dies aber gar nicht richtig wahrnehmen Wie sollen sie auch erkennen was n tzliche Erlebnisse sind und diese in nutzbare Erfahrung bersetzen e Schlie lich f hren Praktika in den neuen Bachelor Studieng ngen zu einem Engpass im ohnehin sehr kurzen Studienplan Wenn in sechs Semestern die Berufsbef higung erworben werden soll kann man sich kaum leisten zwei davon f r Bachelorarbeit und Praktikum aufzuwenden Irgendwann muss ja auch das n tige Grundwissen vermittelt werden An der Universit t Hannover wurde daher das Praktikum aus dem Studienplan genom men wenn auch mit ausdr cklichem Bedauern In der In
144. hmer auf die Klassennamen im Entwurf geeinigt haben wird der Entwurf gemeinsam implementiert Je nach Programmierkultur kann inkrementell iterativ oder in einem gro en Entwicklungsschritt vorgegangen werden und je nach vorhandener Zeit kann auch noch ein Makrobefehl implementiert werden F r diesen Abschnitt sollten mindestens 30 Minuten eingeplant werden 3 3 Zusammenfassung Abschluss Der Entwurf und die Implementierung werden auf vorbereiteten Folien reflektiert Auf einer Folie sind die Teilnehmer des generischen Musters den Teilnehmern der konkre ten Realisierung gegeniibergestellt bei der die Namen durchaus von den in der Gruppe gew hlten abweichen k nnen Eine weitere Folie zeigt das spezifische Klassendia gramm der L sung bei der auch sehr wahrscheinlich die Namen abweichen Schlie lich werden die Vorteile des Befehlsmusters und weitere Anwendungsm glichkeiten auf Folien zusammengefasst Dies alles sollte nicht l nger als 10 Minuten dauern 4 Bisherige Erfahrungen mit Teachlets Bei den bisherigen Erfahrungen mit Teachlets konnten unterschiedliche Muster bei der Choreographie beobachtet werden Einige Teachlets wurden direkt mit dem Ausgangssystem begonnen ohne einf h rende Folien zum Lernziel keine trockene Darstellung eines Entwurfsmusters zu Anfang Die Aufgabe wurde bearbeitet und anschlie end wurde enth llt dass da Eine Werkstatt f r Teachlets 99 gerade etwas benutzt wurde das blicherweise a
145. hmolitzky und Heinz Z llighoven Integration agiler Prozesse in die Softwaretechnik Ausbildung im Informatik Grundstudium Proc SEUH 8 dpunkt verlag Heidelberg 2004 DHZS99 Birgit Demuth Heinrich Hu mann et al Erfahrungen mit einem frameworkbasierten Software praktikum Proc SEUH 6 Teubner 1999 DM91 Jocelyn R Drolet and Colin L Moodie Object Oriented Simulation with Smalltalk 80 A Case Study In Nelson Kelton Clark eds Proceedings of the 1991 Winter Simulation Conference 1991 GR83 Adele Goldberg und David Robson Smalltalk 80 The Language and ist Implementation Part Three Addison Wesely 1983 H95 Eva Hornecker Pr sentationstechniken und Teamtraining f r das Software Praktikum Proc SEUH 95 Teubner 1995 S 69 81 ICFP04 ICFP 2004 Programming Contest http Avww cis upenn edu proj plclub contest index php M04 Andreas Metzger Konzeption und Analyse eines Softwarepraktikums im Grundstudium Proc SEUH 8 dpunkt verlag Heidelberg 2004 S 41 48 PMP00 Lutz Prechelt Guido Malpohl Michael Philippsen JPlag Finding plagiarisms among a set of pro grams Interner Bericht 2000 1 Universit t Karlsruhe M rz 2000 Zel00 Andreas Zeller Making Students Read and Review Code Proc 5 ACM SIGCSE SIGCUE Annual Conference on Innovation and Technology in Computer Science Education ITiCSE 2000 Helsinki Finnland Juli 2000 S 89 92 Eine Plattform fur die Softwaretechnik Fernlehre Philipp Bouill
146. hpartner seitens des Kunden e nderungen und versp tete Pr zisierung von Anforderungen 3 2 Didaktisches Ziel Motivation der Teilnehmer ber einen engen Praxisbezug wird bereits viel zur Motivation beigetragen Folgende Punkte k nnen die Motivation weiter steigern Wettkampf Es ist eine der st rksten Motivationsmethoden die Teams wettstre bend dieselbe Aufgabe l sen zu lassen Der Wettkampf im SoPra 2004 war sehr moti vierend Einzelne Teams erstellten fernsehreife Vertriebsshows f r die Abschlusspr sentation Damit der Wettkampf und die Bestimmung des Siegerteams am Schluss auch Spa macht kam unter anderem ein Applausometer zum Einsatz ein Phonometer vom Physikinstitut womit der Publikumsbeifall f r die Pr sentationen der Teams ge messen und in Wettkampfpunkte verwandelt wurde Lustige und bunte Anwendung Die Aufgabe soll nicht nur Technisches enthalten sondern auch Sichtbares und Gestalterisches Die Aufgabe B rsencafe im SoPra 2004 war beispielsweise viel motivierender als es eine Verwaltungsanwendung gewesen w re Sie gab den Teilnehmern die Gelegenheit sich in der professionellen Gestaltung einer auf die emotionalen Bed rfnisse der Endkunden zugeschnittenen Oberfl che und einer an Ma st ben professioneller Benutzbarkeit Stoyan2004 orientierten Administ rationsoberfl che zu ben Da Benutzbarkeit ohnehin in fast jedem Informatik Studiengang zu kurz kommt in der Praxis aber ma geblich ber die A
147. hrend die anderen Gruppen ihre Zust ndigkeiten nur in CURE dokumentieren wollten Die Gruppe die CodeBeamer verwendet stellte bereits in der Pr senzphase erste Aufgaben in den Task Tracker von CodeBeamer ein und machte im Vergleich zu den anderen Gruppen in der Anfangsphase des Praktikums die schnellsten Fortschritte Ob dies an der transparenteren Aufgabenverteilung lag muss durch eine endg ltige Evalua tion gekl rt werden Nach etwa zwei Monaten stellte diese Gruppe jedoch die Nutzung von CodeBeamer ein Die Koordination erfolgte von diesem Zeitpunkt an nur noch ber einen w chentlich stattfindenden Team Chat Die Gruppenmitglieder begr ndeten diese Entscheidung damit dass CodeBeamer zu Beginn des Praktikums zur klareren Aufga benverteilung beigetragen hat Sp ter jedoch seien die einzelnen Aufgaben und Zust n digkeitsbereiche klar gewesen so dass zur Koordination der w chentliche Team Chat und die Benachrichtigungen durch CVS ber den Gruppenfortschritt gereicht h tten 5 Zusammenfassung Wir haben gezeigt wie wir Eclipse als die Basisumgebung f r Softwaretechnik Projekte in der Fernlehre verwenden m chten Zur Gesamtplattform geh ren neben Eclipse die beiden gro en Komponenten CURE das auch zurzeit schon die kooperative Lernplatform der FernUniversit t ist und das Projektmanagementsystem CodeBeamer CURE wurde bereits in Eclipse integriert wodurch der Benutzer nun innerhalb von Eclipse auf die Wiki Mail Chat und Ka
148. ht alle Studenten Einige wenige Teilnehmer wurden in den ersten zwei Wochen wegen Nichtbeteiligung oder mangelnder Kenntnisse ausge schlossen Die studentische Evaluation dokumentiert die Wirkung der Verbesserungen hier im Vergleich mit dem semesterbegleitenden Praktikum des Vorjahres e Der durchschnittliche Arbeitsaufwand ist kaum ver ndert statt semesterbe gleitend 22 Stunden Woche hatten wir nun 40 Stunden Woche Vollzeit e Die Arbeitsbelastung war f r 40 gerade richtig zuvor 0 f r 60 zu hoch zuvor 55 und f r 0 viel zu hoch zuvor 45 insgesamt also eine leichte berforderung die genau so erw nscht ist e Die gute Stimmung dr ckte sich auch in der Bewertung der Dozenten und Materialien aus die obwohl weitgehend identisch in s mtlichen Fragen zur Lehreffektivit t mit 0 5 0 7 Notenstufen besser bewertet wurden e Die gr te Steigerung 1 Notenstufe gab es in der Bewertung der Tutoren was f r unser Betreuungskonzept spricht e 80 w nschen sich eine zuf llige oder auf F higkeiten basierte Zusammen setzung der Gruppen wie bei uns eingesetzt e Alle Teilnehmer mit einer Ausnahme meinen das Praktikum solle in der vorlesungsfreien Zeit stattfinden Ein Softwarepraktikum in den Semesterferien ist bei gleichem Arbeitsaufwand deutlich weniger belastend Ein Software Praktikum als Sommerkurs 79 9 Vergleich Der Unterschied zwischen einem Praktikum in ein
149. ht Hier sollte das Team notieren wer was gemacht hat Schlechte Karten hat wer einfache unschuldige Fragen zu angeblich seinem Teilergebnis nicht beantworten kann Der Ort an dem ohnehin Aufgaben zuge ordnet werden ist der Projektplan Besprechungsprotokolle eignen sich auch sehr gut Forbrig1997 Der Plan soll Aufgaben gesch tzte Aufw nde und Namen enthalten und nicht nur die zuk nftigen sondern auch die erledigten Aufgaben sind jede Woche zu aktualisieren Zu Beginn solcher Praktika wird Projektplanung nicht immer sinnvoll sein denn wie soll ein einzelnes Klassendiagramm welches im Team erarbeitet wurde Verantwortlichen zugeordnet werden Hier ist aber auch die im Punkt Tutorenschu lung beschriebene kommunikative Kontrolle noch wirksam etwa beim Review des Klassendiagramms Sp testens ab Feinentwurf und Programmierung wird der Projekt plan zum wirksamen Kontrollinstrument Leistungskontrolle per Pr fung Kerer2004 machte nach mehreren Versuchen die Praktikumsteilnahme optional und verlagerte die Leistungskontrolle auf die Pr fung zum Schluss Nach den berichteten Erfahrungen war dies bei 600 Teilnehmern und eindeutig technischem Lernziel die beste L sung Z hlen von LOC In Gehrke2002 wird empfohlen f r alle Kursteilnehmer die LOC Lines of Code zu z hlen um Trittbrettfahrer zu vermeiden Kontrolle der Teamleistung Wenn Teamarbeit zu lernen mit zu den Zielen des Praktikums geh rt ist es berechtigt und notwendig
150. ht der Hochschu len SEUH7 Z rich 2001 Heidelberg dpunkt verlag S 11 21 Carls1993 H Carls J Raasch Der Unterschied zwischen Theorie und Praxis Vorlesung und Praktikum Software Engineering In J Raasch T Bassler Hrsg Software Engineering im Unterricht der Hoch schulen SEUH 93 Stuttgart Teubner S 105 114 Dawson2000 R Dawson Twenty Dirty Tricks to Train Software Engineers 22nd International Conference on Software Engineering Limerick Irland 2000 p 209 218 Forbrig1997 P Forbrig Probleme der Themenwahl und der Bewertung bei der Projektarbeit in der Software Engineering Ausbildung In P Forbrig G Riedewald Hrsg Software Engineering im Unterricht der Hochschulen SEUH 97 Stuttgart Teubner S 45 52 Gehrke2002 M Gehrke et al Reporting about Industrial Strength Software Engineering Courses for Under graduates 24th International Conference on Software Engineering Orlando Florida p 395 405 Glinz1996 M Glinz The Teacher Concepts The Student Tools On the Number and Importance of Concepts Methods and Tools to be Taught in Software Engineering Education Proc Third International Workshop on Software Engineering Education Berlin Softwaretechnik Trends 16 1 1996 Kerer2004 C Kerer G Reif et al ShareMe Running A Distributed Systems Lab For 600 Students With 3 Faculty Members Akzeptiert zur Publication in JEEE Transactions on Education http www infosys tuwien a
151. hteten Umgebungen Eclipse und IDEA gab es am Rande immer wieder kurze Diskussionen Nach Eindruck des Veran stalters waren diese Diskussionen ausgesprochen fruchtbar da sie unterstrichen wie wichtig das Werkzeug IDE f r den Softwaretechniker ist Es entstand eine Atmosph re des Austauschs ber Unterst tzungsm glichkeiten durch die IDE insbesondere f r Refactorings die in einer Veranstaltung ber objektorientierten Entwurf durchaus an gemessen war 6 Bewertung und Ausblick 6 1 Das Teachlet Konzept Bewertung Das Teachlet Konzept selbst hat sich f r die Vermittlung von Entwurfsmustern in Gruppen von bis zu 16 Teilnehmern bew hrt Das Feedback der Teilnehmer hat deut lich gemacht dass ein problembasierter Lehransatz EIIY8 gerade zum Aneignen von Entwurfsmustern ausgesprochen motivierend ist Die Vorteile einer engen Verzahnung von theoretischem Vortrag und praktischer Arbeit in der Programmierausbildung sind k rzlich auch von K lling und Barnes in K B04 beschrieben worden Das Teachlet Konzept l st die traditionelle Trennung von Vorlesung und bung noch weiter auf und stellt den Umgang mit Software Artefakten in den Mittelpunkt einer hochinteraktiven Lehr bzw Lerneinheit Teachlets erm glichen somit die Gestaltung sehr effektiver Veranstaltungen K lling und Barnes sprechen in K6B04 au erdem einen interessanten Aspekt an der auch bei Teachlets eine starke Bedeutung hat Der Teachlet Moderator kann als Rollenmode
152. i ging der Pr fer den Entwurf mit der Gruppe durch pr fte ob die gesamte Gruppe mit dem Entwurf vertraut war und gab eine Reihe von Auflagen mit auf den Weg um den Entwurf zu verbessern Die Pr fer sind die Dozenten und wissenschaftlichen Mitarbeiter des Lehr stuhls f r Softwaretechnik sie bieten die h chste Qualifikation f r die Dis kussion von Entwurfs und Konstruktionsproblemen e In der Implementierungsphase musste der Simulator einen Systemtest beste hen Einreichung und Test wurden durch Praktomat Zel00 automatisiert und basierte auf der Referenzimplementierung so dass hier keine manuelle Pr fung stattfand e In der Einsatzphase musste der selbst programmierte Schwarm ein Spiel ge gen eine gegebene schwache Mannschaft bestehen Dies wurde durch einen Lauf des offiziellen Simulators der Referenzimplementierung entschieden e Am Ende des Praktikums fand ein Turnier statt in dem die Schw rme ge geneinander antraten Die Teilnahme war freiwillig es gab Buchpreise f r die Gewinner sowie Sonderpreise f r den sch nsten Simulator und das beste Programmierwerkzeug e Das Praktikum wurde formal durch ein Kolloquium abgeschlossen in dem die Gruppen ihrem Pr fer noch einmal Details des Simulators und der Strate gie vorstellten Hauptzweck dieses Kolloquiums war sicherzustellen dass al le Gruppenmitglieder sich ausreichend beteiligt hatten und den Studierenden Raum f r Lob und Kritik zu bieten Auch wenn wir einen gro
153. ibt es einen Shared Pointer mit dem die Teilnehmer zeigen k nnen worauf sie sich beziehen und vor allem das sog Application Sharing Jeder Teilnehmer kann der Gruppe eine beliebige Applikation online zur Verf gung stellen Modelldiskussionen verlaufen dann fast wie am Flipchart Jemand pr sentiert einen Modellvorschlag der gemeinsam modifiziert wird Dar ber hinaus lassen sich Sitzungen aufzeichnen 4 Pers nliche Begegnungen Technisch und didaktisch l sst sich also auch der Soft Skill Aspekt des Software Engineering Unterrichts online mindestens so gut abdecken wie im Pr senzstudium Dennoch empfehlen wir wenigstens zwei Pr senztermine vorzusehen da die pers nliche Begegnung die Online Kommunikation nachhaltig verbessert Literatur G M 02 G G rlitz und S M ller Didaktisches Design f r eine Online Programmierausbildung GI Jahrestagung Dortmund 2002 http www netucate com Siehe auch htip www f4 fhtw berlin de weberwu papers SoftEngUnterrOnline doc Selbstgesteuertes Lernen und interdisziplinare Projektarbeit neue Wege der Kompetenzentwicklung im Software Engineering Hans Georg Hopf Georg Simon Ohm Fachhochschule N rnberg Kesslerplatz 12 90489 N rnberg hans georg hopf fh nuernberg de 1 Interdisziplinarit t Defizite in der Software Engineering Ausbildung werden h ufig beklagt Der im Jahr 2001 neu an der Georg Simon Ohm Fachhochschule im Fachbereich Elektrotechnik
154. ich daher auf folgende Elemente e Zu Beginn des Workshops machten wir eine ausf hrliche Kennenlernrunde in der jeder Studierende sich den anderen anhand eines Steckbriefes vor stellte siehe Abbildung 4 Pop Epiunig CO Nia cal k Pe a Sans y ee Immo Masten Abb 4 Ein typischer Steckbrief e In Diskussionsrunden wurden die Studenten f r die Unterschiedlichkeiten innerhalb des Teams und das damit verbundene Problempotenzial sensibilisiert Dazu diskutieren wir beispielsweise Fragen wie Euer Projekt steht unter gro em Zeitdruck Was ist dir wichtiger a Die Deadline wird auf jeden Fall eingehalten ggf werden Abstriche bei der Qualit t zugelassen b Das Abliefern eines Qualit tsprodukts hat Vorrang ggf muss die Deadline berschritten werden e Bei ganzt gigen Blockveranstaltungen empfiehlt es sich gerade nach der Mittagspause und am Nachmittag hin und wieder auflockernde bungen zu machen wir haben dabei bungen eingesetzt bei denen die Kooperation im Team im Vordergrund stand z B Reise nach Solidarien Sen 04 Decken drehen Sen 04 Stuhlskulptur Henn 02 Teamtraining f r Software Ingenieure 33 L nomas zn IMA Radi Votar Abb 5 Zwischenergebnis auf dem Weg zum Teamprofil Im Rahmen des Miniprojekts siehe Abschnitt 3 6 lernten die Studierenden ver schiedene Elemente einer Teaminfrastruktur kennen z B Kommunikation ber Mailinglisten Jour fixe und ents
155. idungen zur Entwicklungsumgebung und das techni sche Know how der Firma kann genutzt werden andererseits entstehen aber Restriktio nen mit denen sich die Studenten zus tzlich zur eigentlichen Projektarbeit auseinander setzen m ssen Studenten die sich vor dem Praktikum bereits kannten k nnen sich schneller auf einander einstimmen besser gemeinsame Termine finden und fr her mit der eigentli chen Arbeit beginnen Daf r werden bestehende Probleme aus falsch verstandener Freundschaft oft nicht angesprochen und f hren mitunter sp ter zum Zerw rfnis in der Gruppe Umgekehrt ben tigen Teams deren Mitglieder sich zun chst nicht kennen zu Beginn einen h heren Kommunikations und Koordinationsaufwand gehen aber meist offener mit Problemen um Beide Konstellationen k nnen daher sowohl zum Erfolg des Projekts als auch zu dessen Scheitern f hren Im externen Praktikum ist die 130 Birgit Demuth Lothar Schmitz Barbara Wittek Ausrichtung auf das gemeinsame Ziel jedoch h ufig st rker ausgepr gt sodass hier eher L sungen f r Teamprobleme gesucht werden und seltener Teams oder einzelne Mitglieder aus dem Praktikum ausscheiden Die Auswahl besonders leistungsstarker Studenten f r das externe Praktikum kann f r die Teamarbeit sowohl Vor als auch Nachteile haben Im internen Praktikum sind die Gruppen oft heterogen bez glich der F higkeiten ihrer einzelnen Mitglieder Teamprobleme resultieren oft aus unterschied licher Arbeitsleistung
156. ielgerichteten Kooperation im Team verf gen Das von uns in M nchen durchgef hrte Teamtraining basiert auf Konzepten die seit einigen Jahren von der Hochschuldidaktischen Arbeitsstelle der TU Darmstadt ange wandt werden e Team Coaching von Software Projekten am Institut f r Informatik der TU Darmstadt Hen 02 e Interdisziplin res Teamtraining an der TU Darmstadt Einzelpersonen die sich vor dem Workshop nicht kannten und die nach dem Workshop nicht als Team zusammenarbeiten m ssen bilden w hrend des dreit gigen Workshops zu Trainingszwecken ein Ad hoc Team Kom 04 F r M nchen wurde das Darmst dter interdisziplin re Teamtraining f r Ad hoc Teams berf hrt in ein Teamtraining f r echte Teams aus Studierenden die an dem Softwaretechnik Praktikum teilnehmen werden Da es sich nicht um ein Ad hoc Team handelte sondern um eine Gruppe von Stu dierenden die sich im Anschluss an das Training als Team bew hren musste musste das Training um spezielle Teambuilding Aspekte erg nzt werden Der bereits existie rende interdisziplin re Projektmanagement Anteil wurde auf den spezifischen Kontext des Praktikums zugeschnitten Im Gegensatz zu Darmstadt war das Teamtraining nicht optional sondern als verpflichtender Baustein f r alle Teilnehmer am STP vorgeschrie ben und wurde mit einem eigenen Seminarschein anerkannt Im Jahr 2003 wurde dieses Teamtraining von Katharina Neumeyer und Andreas Fleischmann ko
157. ierenden des englischsprachigen Masterstudien gangs INFOTECH besucht wird stehen sowohl die Studierenden als auch die Betreuer vor der Herausforderung die Kommunikation in Englisch durchzuf hren Lehren und Lernen erfolgen also in einer Fremdsprache Insbesondere die Dokumente die in den verschiedenen Projektentwicklungsphasen angefertigt werden m ssen in englischer Sprache erstellt werden Der Gebrauch von Englisch geh rt im heutigen Berufsleben zum Alltag Im Fachpraktikum Softwaretechnik werden die Studierenden durch Be sprechungen Diskussionen und Dokumentation in englischer Sprache auf die indus trielle Praxis vorbereitet In einer Zeit fortschreitender Globalisierung ist die F higkeit der Zusammenarbeit in multikulturellen Teams von zunehmend wichtigerer Bedeutung und sollte in der Ausbildung nicht ignoriert werden Die Zusammensetzung der Teams aus Studierenden der drei genannten Fachrichtungen macht nicht nur den Gebrauch von Englisch erfor derlich sondern schult die Studierenden in der Zusammenarbeit mit Menschen aus an deren Kulturen Am INFOTECH Studiengang nehmen Studierende aus der ganzen Welt mit unterschiedlichstem kulturellem Hintergrund teil Durch die enge Zusammen arbeit der Studierenden in den Teams sind die Studierenden gefordert sensibel f r die Arbeitskulturen der Teammitglieder zu sein und einen gemeinsamen Weg f r die Zu sammenarbeit zu finden 4 2 Projektmanagement Die Studierenden werden im Fachpraktikum
158. ies zun chst zu Bequem lichkeit und dann bald zum Gef hl berfl ssig zu sein Wie soll aber jemand der die Mehrheit der Zeit scheinbar nicht gebraucht wird motiviert sein So mussten in fr heren Durchf hrungen des SoPra die Teilnehmer manche Tutoren erst in der Cafeteria suchen wenn sie Fragen hatten Seitdem wurde eine feste Regel eingef hrt f r die Ar beit der Tutoren St ndiger Kontakt mit der Gruppe Dies wurde kombiniert mit der Erwartungshaltung nicht nur auf Anfrage zu helfen sondern auch gelegentlich Teil nehmer mit irgendetwas anzusprechen und nicht nur bei Hausaufgaben sondern auch bei Pr senz bungen Feedback zu geben So hatten die Tutoren sp rbar mehr Gef hl n tzlich zu sein und somit mehr Motivation ber Probleme sprechen besonders ber menschliche ist ein anderes Ar beitsprinzip Wenn im SoPra Tutoren oder Obertutoren ber Team Probleme berich ten bekommen sie stets Anh rung und Anerkennung Es wird bewusst getrennt zwi schen der Erwartung Probleme st ndig zu berichten und der Annahme dass sie in der Lage sind die meisten selber zu l sen W hrend die Leitung somit ein genaueres Bild ber den Zustand des Praktikums erh lt profitieren die Tutoren indem sie ihre Rolle ganz anders erleben Aus Sicht des Projekts f r den Kunden sind sie ein Coach dies geh rt zur traditionellen Tutorenrolle Aus Sicht der hier dargestellten Arbeitsweise und der Tutor Obertutor Praktikumsleiter Hie
159. iese Person bereitet das Meeting vor Raum reservieren Erinnerungsmail verschicken Tagesordnungspunkte sammeln und moderiert das Meeting Zu Beginn des Meetings sollten gemeinsam die Tagesordnungspunkte ge sammelt werden die besprochen werden m ssen diese werden dann ent sprechend ihrer Wichtigkeit und Dringlichkeit in eine Reihenfolge gebracht und der Reihe nach abgearbeitet Verschiedene Arten der Ergebnissicherung zum Beispiel Sofort Protokoll am Laptop das mit einem Beamer projiziert wird Arbeitstechniken Hier wurden verschiedene Arbeitstechniken zum gemeinsamen Sammeln Ordnen Strukturieren und Bewerten Entscheiden vorgestellt Brainstorming und Kartentechniken wie zum Beispiel in Abbildung 6 dargestellt Regeln f r das effektive und kooperative Diskutieren zum Beispiel Her stellen einer gemeinsamen Ausgangsbasis Zieldefinition und Strukturierung von Diskussionen Ergebnissicherung Abbildung 6 zeigt Tipps zum Disku tieren die die Studierenden selbst formuliert haben betreffend das Einzelver halten ich das Gruppenverhalten Gruppe und die gesamte Organi sation der Diskussion p ruktive nicht Go Thema 3 ab wee bee p klar und ofeudl Ausdrucken Teamtraining f r Software Ingenieure 35 e Verschiedene Methoden um gemeinsam Entscheidungen zu treffen zum Beispiel Abstimmungen Entscheidungsmatrizen oder Konsensdiskussion Uns war in diesem Zusammenhang besonders wichtig
160. ig und Andreas Zeller unmittelbaren Nutzen bringen Weiterf hrende Themen der Softwaretechnik sollten in eigenen spezifischen bungen vermittelt werden Ohnehin greift das Verst ndnis f r Programmieren im Gro en erst wenn entsprechende Programmier und Teamerfahrun gen vorhanden sind und diese werden im Praktikum gemacht Was uns allerdings schmerzt ist der Wegfall der Anforderungsanalyse die wir wieder ins Praktikum ein flie en lassen m chten Dies kann so geschehen dass ein Wahlpflichtteil wie Erstellen einer Simulator GUI oder Model Checking von Schwarm Automaten von einem Kunden grob vorgegeben wird und ber einige Iterationen in Abstimmung mit dem Kunden verfeinert wird ebenfalls innerhalb von sechs Wochen parallel zur Haupt aufgabe In BBSZ04 lesen wir dass Erfahrungen im Programmieren und in der Projektar beit sich am besten intensiv d h ganzt gig vermitteln lassen Dem k nnen wir nur zustimmen Wenn es weiter hei t Die Zw nge die sich aus den festgelegten Veranstal tungsformen und rastern der Raumvergabe und der Verkn pfung von Hauptstudium und Nebenfach ergeben verhindern l nger laufende Projektveranstaltungen so schla gen wir als pragmatische nunmehr erprobte L sung vor Projekte und Praktika in der vorlesungsfreien Zeit stattfinden zu lassen Vorlesungsfreie Zeit ist Praktikumszeit Literatur BBSZ04 Petra Becker Pechau Wolf Gideon Bleek Axel Sc
161. ildung in Softwaretechnik an Universit ten und Fachhochschulen wie ist sie in das Informatik Studium eingebettet wie sollte sie gestaltet werden welche Erfahrungen gibt es Dies sind die Themen um die es bei den SEUH Workshops geht SEUH geh rt mittlerweile zum festen Bestandteil der Informatik Tagungsreihen im deutschsprachigen Raum Sein hoher Bekanntheitsgrad und seine zunehmende Beliebt heit als Forum f r den Meinungs und Erfahrungsaustausch haben der diesj hrigen Veranstaltung die erfreuliche Anzahl von 32 eingereichten Beitr gen beschert darunter viele von hoher Qualit t Das Programmkomitee hat 12 Beitr ge zur Pr sentation und Aufnahme in den vorliegenden Tagungsband ausgew hlt zus tzlich wurden 4 Kurzbei tr ge angenommen F r die einzelnen Sitzungen des Workshops sind die Beitr ge wie folgt gruppiert e Didaktik und Training e Softwaretechnik Praktika e Fernlehre und Nahlehre e PSP und XP e Praktika mit externen Projekten Der berwiegende Teil der eingereichten Beitr ge hat Softwaretechnik Praktika und Projekte zum Gegenstand Auch zu einigen anderen Themen die im Aufruf zur Einrei chung genannt worden waren gab es Beitr ge Bemerkenswert ist zu welchen Themen keine Beitr ge eingereicht wurden Formale Methoden modellgetriebene und kompo nentenbasierte Entwicklung Invarianten der Softwaretechnik Lehre Das letztere The ma ist zugegebenerma en schwierig wir bedauern es sehr dass keiner es gewag
162. im Bereich Projektmanagement geschult Bestandteile des Projektmanagements sind die Projektplanung die Projektkontrolle die Ergreifung von Ma nahmen f r die Einhaltung des Projektplans sowie Kostenberech nung und Teamorganisation vgl LaG 99 S 17 f Zu den Lernzielen in diesem Auf gabenbereich geh rt auch das ben der ansprechenden Pr sentation von Arbeitsergeb nissen Die Projektplanung umfasst die Teilaufgaben Organisations Aufwands und Terminplanung sowie die Ressourcenplanung Die Projektplanung wird anhand eines Projektplans dokumentiert und projektbegleitend verfolgt Softwaretechnik live im Praktikum zur Projekterfahrung 49 Zudem geh rt es auch zu den Aufgaben des Projektmanagements Probleme in der Teamarbeit zu erkennen und diesen entgegenzuwirken Dies schlie t auch die Motivati on der Teammitglieder mit ein Am Ende des Projekts verfasst der Projektmanager ei nen Projektabschlussbericht der eine Zusammenfassung des gesamten Projektverlaufs enth lt und die erzielten Ergebnisse erl utert 4 3 Methodische Softwareentwicklung Bei der Durchf hrung des Projekts werden die Studierenden in methodischer Software entwicklung geschult Dabei werden Techniken und Methoden der Softwaretechnik angewandt welche die Studierenden in den Vorlesungen Einf hrung in die Informatik III G hn04a und Softwaretechnik I G hn04b kennen gelernt haben Die Software entwicklung erfolgt objektorientiert wobei f r Analyse OOA
163. in Student bernimmt die Rolle des Chefprogrammierers der Entscheidungen trifft und als Ansprechpartner f r Kunden und Betreuer fungiert Die weiteren Rollen Assistent Sekret r und Programmierer werden unter den restlichen Teammitgliedern aufgeteilt F r jedes Team im internen Praktikum wird ein studentischer Tutor engagiert der den Softwareentwicklungsprozess kontrolliert die Rolle des Kunden bernimmt und den Gruppen bei auftretenden technischen und kommunikativen Problemen hilfreich zur Seite steht Die Tutoren haben dabei eine hohe Verantwortung da Entscheidungen ber Korrektheit von Dokumenten Einhaltung von Zeitvorgaben und Beteiligung aller Teammitglieder am Projekt zu treffen sind Die Teams m ssen w chentlich einmal an Pflichtkonsultationen mit ihrem Betreuer teilnehmen Hierbei werden Ergebnisse be sprochen Probleme gekl rt die Einhaltung des Zeitplans berpr ft etc Das interne Praktikum ist in Phasen eingeteilt f r die ein strenger Zeitplan vorge geben wird Nach zweiw chiger Einarbeitungsphase in der sich die Studenten die Grundlagen des wiederzuverwendenden Anwendungsframeworks aneignen sollen entscheidet ein Zwischentest ber die weitere Teilnahme am Praktikum Die Bearbei tung der Aufgabe erfolgt danach in den Phasen Analyse Entwurf Implementation Test und Wartung Nach Abschluss dieser Phasen stellen die Teams ihre Ergebnisse in einer Endpr sentation vor F r die Bearbeitung des Projekts stehen den Studieren
164. in der Modellschicht oder in den Client Anwendungen vornehmen Trotz dieser nderungen k nnen alle gleichzeitig mit dem gleichen Server und dem gleichen Datenbestand arbeiten Bei nderungen der Client Anwendungen oder der Modellschicht ben tigt der Server keinen Neustart Dadurch wird der Installations Organisations und Wartungsaufwand bei einer gro en Studie rendenanzahl w hrend einer Lehrveranstaltung oder eines Praktikums verringert Dar ber hinaus m ssen sich die Studierenden nicht in die komplizierte verteilte Architek 62 Barbara Paech Lars Borner J rgen R ckert Allen Dutoit Timo Wolf tur von Sysiphus einarbeiten Je nach Wissensstand k nnen sie leichtere oder schwerere Aufgaben in unterschiedlichen Abstraktionsbereichen der Architektur bearbeiten Auf grund der beschriebenen Eigenschaften eignet sich das System Sysiphus hervorragend fiir den Einsatz in Lehrveranstaltungen des SWE 2 3 Die Werkzeuge Zur Bearbeitung des Sysiphus Systems ist aufgrund seiner Komplexit t eine praxisnahe Entwicklungsumgebung erforderlich Aus fr heren Veranstaltungen gab es in Heidel berg erste Erfahrungen mit der Rational Suite Diese erfordert aber die Einarbeitung in sehr unterschiedliche Tools und bietet keine Unterst tzung f r die in einem Praktikum relevanten Kommunikationsaspekte Weitere Erfahrungen gab es mit der Anwendung REQuest die wie oben beschrieben auf Sysiphus aufsetzt Der Einsatz von REQuest bedeutet f r die Studi
165. iner Programmiersprache Normalerweise wird in diesen Vorlesungen Wert darauf gelegt dass die Studierenden das Konzept der Pro grammiersprache verstehen und somit selbstst ndig in der Lage sind gro e Programme zu entwickeln Um das Verst ndnis der Softwareentwicklung im Gro en noch zu erh hen gibt es theoretische Softwaretechnik Vorlesungen die h ufig erst im Haupt studium stattfinden in denen die Studierenden erstmals direkt mit der Komplexit t eines gro en Softwaresystems in Ber hrung kommen Die rein theoretischen Betrachtungen der Softwaretechnik reichen allerdings nicht aus um den Studierenden ein Gef hl von den Kommunikations Koordinations und Kollaborationsproblemen zu geben die w hrend eines Softwareprojekts auftreten k n nen Studierende neigen dazu sich auf die technischen Probleme zu konzentrieren und zu glauben dass die sozialen Aspekte erst gar nicht auftreten Daher werden an vielen Universit ten und insbesondere auch an der FernUniversit t in Hagen begleitend zu den Softwaretechnik Vorlesungen Praktika angeboten in denen eine Gruppe von Studieren den ein gr eres Softwaresystem entwickeln muss Um solche Praktika zu erleichtern wird eine Reihe von Softwarewerkzeugen verwendet Bezogen auf Eclipse gibt es bis lang noch nicht viele Plug ins die Kollaborationsprozesse unterst tzen Es gibt zwar einige Plug ins die Instant Messaging Protokolle in Eclipse integrieren wie z B das IM Plug in oder PepeMax
166. innvoll nach dem ersten Simulationslauf eine Feedback Sitzung anzubieten Dadurch k nnen Studie rende Effekte und deren Ursachen hinterfragen und Strategien gemeinsam mit der Lehrveranstaltungsleitung bewerten Die Vergleichskomponente unterst tzt Lehrveranstaltungsleiter und Studierende Sie erm glicht Projekte einander gegen berzustellen und Lernfortschritte aufzuzeigen Ebenso k nnen Studierende Vergleiche mit Alternativl sungen anstellen 4 Res mee Studierende wie Praktiker sind sich weitestgehend einig dass sie aus dem Experimen tieren mit AMEISE das sie in die Rolle eines virtuellen Projektleiters gebracht hat wesentliche Erfahrungen gewonnen haben Die Simulationsergebnisse werden weit gehend als realistisch eingestuft Die Hilfsmittelkomponenten k nnen je nach didak tischer Zielsetzung optional zugeschaltet werden Sie sind einfach erweiterbar Auch die Systementwicklung selbst hat wesentliche Ausbildungseffekte Sie bietet Studierenden die M glichkeit an einem gro en Legacy System Probleme zu erfahren die in blichen Semesterprojekten nicht auftreten k nnen References Dra00 A Drappa J Ludewig Simulation in Software Engineering Training In Proc 23rd Internat Conf on Software Engineering IEEE CS 2001 p 199 208 Jae04 S J ger E Hochm ller R Mittermeir A Bollin D Wakounig Systemunterst tzung der Software Projektmanagement Ausbildung TR ISYS 01 11 04 Univ Klagenfurt 2004 Man01
167. it mehreren tausend Studenten gewinnen konnten Abschnitt 4 Abschnitt 5 fasst aus unserer Sicht wichtige und praxisrelevante Lehren f r unser Aus bildungskonzept zusammen 2 Ziele und Rahmenbedingungen Das Praktikum hat die Vermittlung objektorientierter Softwareentwicklungstechniken im Rahmen eines Softwareprojekts sowie das Erlernen arbeitsteiliger und teamorientier ter Arbeitsweisen zum Ziel Dar ber hinaus wird die Wiederverwendung von Soft ware vorgeschrieben um die Arbeit mit Softwarebausteinen und deren Anpassung bewusst einzu ben Dem 99 Im internen Praktikum besteht daher die Aufgabe in der Erstellung einer Verkaufsanwendung auf Basis des Anwendungsframeworks Sa lesPoint Es werden Teams von meist f nf Studenten gebildet die eine grobe Beschrei bung einer komplexen Aufgabenstellung als Basis f r ihre Arbeit erhalten Zun chst ist eine Anforderungsermittlung durchzuf hren Dann erfolgt in mehreren Schritten die Modellierung des zuk nftigen Produkts mit Hilfe verschiedener UML basierter Be schreibungstechniken Das Ziel der Modellierung ist ein auf die wiederzuverwendenden 126 Birgit Demuth Lothar Schmitz Barbara Wittek Softwarebausteine abgestimmter Entwurf der dann mittels der Programmiersprache Java umgesetzt werden muss Zur Teambildung k nnen die Studenten vorab W nsche u ern die nach M glich keit erf llt werden F r die Arbeitsteilung innerhalb der Teams wird das Chefprogram miererprinzip empfohlen E
168. itung notwendigen ge nerellen Aktivit ten und Produkte und deren Abh ngigkeiten definiert Tailoring Da bei wurden spezielle Anpassungen f r die Projektbearbeitung in kleinen Teams vorgenommen Zur Festlegung des zeitlichen Ablaufs der Projektbearbeitung wurde das V Modell mit einem einfachen Phasenmodell kombiniert Das Ergebnis sind die folgenden Projektphasen e Anforderungserfassung e Anforderungsanalyse e Softwareentwurf e Softwareimplementierung und integration e Softwaretest und berarbeitung Softwaretechnik live im Praktikum zur Projekterfahrung 45 Der Einsatz des Vorgehensmodells bietet zahlreiche Vorteile sowohl fiir die Studieren den als auch fiir die Betreuer Durch das Vorgehensmodell werden die Studierenden fr hzeitig dazu angehalten sich Gedanken ber die anstehenden Aufgaben zu machen diese zu formulieren und eine detaillierte Planung zu erstellen Dadurch wird das Pro jekt berschaubar und die Studierenden k nnen den zeitlichen Ablauf absch tzen Unn tige Leerlaufzeiten aufgrund von ungeplantem Vorgehen k nnen weitgehend minimiert oder ganz ausgeschlossen werden Die Studierenden werden durch das Vorgehensmodell zu einer fortw hrenden strukturierten Projektdurchf hrung und dokumentation angehalten Auch f r die Betreuer sind die Arbeiten der Teams einfa cher zu kontrollieren Es kann festgestellt werden welche Aufgaben verz gert sind und welche Auswirkungen die Verz gerung haben kann Wie berei
169. iv kennen Erst wenn der Leistungsumfang klar geworden ist sollte die Architektur untersucht werden Insbesondere hier tritt der Moderator in den Hintergrund Fiir welche Klasse soll ich zuerst den Quelltext zeigen und folgt den Anweisungen der Teilnehmer Starte bitte noch einmal die Anwendung das m chte ich ausgef hrt sehen etc Nachdem das Ausgangssystem aus Au en und Innensicht allen Teilnehmern klar geworden ist stellt der Moderator die erste Aufgabe Idealerweise ist diese auf min destens einer eigenen Folie formuliert Meist besteht die Aufgabe in einer Erweiterung der Funktionalit t ein Undo soll m glich sein aber das muss nicht der Fall sein Gerade Entwurfsmuster werden h ufig dann eingesetzt wenn die innere Architektur nicht ausreichend wartbar ist Eine Aufgabe kann deshalb auch lauten die Anzahl der Klassen zu minimieren oder die Austauschbarkeit eines Quelltextabschnitts zuk nftig einfacher zu gestalten F r die sehr interaktive Implementierungsphase sollten mindestens 30 Minuten ein geplant werden Der Moderator muss dabei immer im Auge behalten dass gen gend Zeit f r eine abschlie ende Zusammenfassung bleibt In dieser Zusammenfassung soll te unterst tzt durch geeignete Folien das gerade Getane noch einmal ausf hrlich re flektiert werden Au erdem sollten hier alternative L sungen und weitere Einsatzm g lichkeiten des zu lernenden Konzepts dargestellt werden Im Abschluss wird eine T
170. ives Projektmitglied stellt ein weiteres Merkmal von XP dar Durch die iterative Vorgehensweise kann leicht auf sich st ndig ndernde Anforderungen des Kunden reagiert werden Die Bedeutung des Kunden im Entwicklungsprozess l sst sich in 122 Doris Schmedding und Ingrid Beckmann studentischen XP Projekten nur mit hohem Aufwand simulieren MSK04 Als Kunde ist ein Lehrender nach XP auch aktiv in den Entwicklungsprozess eingebunden er formuliert Abnahmetests und bestimmt bei der Iterationsplanung mit Ein Kunde der vom Veranstalter simuliert wird dr ngt auf die Fertigstellung des m glichst umfangreichen Produkts Dieser Rollenkonflikt zwischen Lehrendem der auf die korrekte Einhaltung der Abl ufe und Konzepte achten muss und dem simulierten aktiven Kunden wird auch von M gge Speicher und Kniesel MSK04 best tigt Bei der phasenorientierten Vorgehensweise geht man davon aus dass zu einem bestimmten Zeitpunkt alle Anforderungen des Kunden erhoben und dokumentiert sind Dann kann mit der eigentlichen Entwicklung begonnen werden Das l sst sich von Lehrenden in studentischen Projekten zwar leicht realisieren indem von ihnen entsprechende Dokumente vorbereitet werden ist aber eine unrealistische Sicht der Wirklichkeit denn reale Kunden ndern st ndig w hrend der Entwicklung ihre Anforderungen Agile Vorgehensweisen wie XP sind hier den wenig flexiblen auf Dokumenten basierenden Vorgehensweisen berlegen Aber Projekte mit realen Kun
171. k nnen so kompetente Hilfe anbieten 3 Das externe Praktikum Bez glich der Rahmenbedingungen und des Anforderungsniveaus unterscheiden sich internes und externes Praktikum nicht wesentlich eher bei Aufgabenstellung Arbeits bedingungen und Kontrollmechanismen W hrend im internen Praktikum die Aufgabe in der Erstellung einer Verkaufsanwendung auf Basis des am Lehrstuhl entwickelten Anwendungsframeworks SalesPoint besteht h ngt die Aufgabenstellung im externen Praktikum von den Anforderungen der jeweiligen Firma Institution ab Das Spektrum reicht dabei von hauseigenen Werkzeugen ber Prototypen zur Ermittlung von Pro duktanforderungen und zur Nutzerakquisition bis zu realen Web Anwendungen Es wird jedoch darauf geachtet dass der Umfang in etwa dem der universit ren Projekte entspricht Das setzt eine enge Zusammenarbeit zwischen dem Lehrstuhl und den am Praktikum beteiligten Firmen voraus Damit die Rechte und Pflichten aller Beteiligten gewahrt werden k nnen wird bereits in der Vorbereitungsphase ein Kooperationsver trag geschlossen Auf der Basis dieser Vereinbarung k nnen w hrend der Bearbei tungszeit auftretende Probleme sowie berechtigte Interessen der Firmen etwa Geheim haltung angemessen ber cksichtigt werden Selbstverst ndlich hat dabei der Lernerfolg Priorit t gegen ber Anforderungen an den Funktionsumfang des Produkts Nicht zu untersch tzen ist der hohe Aufwand bei der Vorbereitung externer Projekte Das betrifft
172. kzeptanz der Software entscheidet sollten alle Gelegenheiten genutzt werden dies zu lehren Gestaltungsfreiheit Als der Kunde im SoPra 2004 lediglich betriebswirtschaftliche Ziele vorgab hatten die Studierenden zun chst den Eindruck dass es keine klaren An forderungen gebe Die Studierenden mussten darauf aufmerksam gemacht werden dass der Kunde nichts von Informatik versteht und die Software daran messen wird wie gut sie sein Gesch ft unterst tzt Dann entwickelten die Teilnehmer jedoch viel Spa am technisch freieren aber betriebswirtschaftlich zielorientierten Gestalten Technisch wurden vom Praktikum her Programmiersprache Zielplattform und zu verwendende Codeteile vorgegeben Das Ziel des Kunden lautete Wir m chten den Umsatz stei gern Die Teilnehmer mussten dann in der Sprache des Kunden erfragen wie das denn geschehen soll Durch niedrigen Personalaufwand indem h ufig ben tigte Ab l ufe sehr schnell durchzuf hren sind Weiterhin Nat rlich k nnen technische Vorgaben genauso praxisrelevant sein wenn der Auf traggeber technisch versiert ist Motivatorisch und f r das Lernen per berraschung empfehlen wir jedoch die betriebswirtschaftlichen Ziele Stau unausgesprochener Gef hle und ungel ster Probleme vermeiden Zu den st rksten Motivationskillern geh ren unausgesprochene nicht angeh rte oder nicht Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 7 b
173. l reports the students evaluated the PSP exercises and their own learning during the course They considered the series of exercises a good introduction to a measurement based process but to be really valuable more exercise is needed many students were disappointed with their own prediction skills and their slow or nonexistent improvement Nevertheless they felt that by guiding them to plan their entire process instead of just starting to code from some part of the task the method could potentially help them in learning to make better estimates Reviewing one s own work was considered difficult and even unmotivating but still several of the students mentioned reviews as one of the tools that they might consider using in the future 5 Future plans Based on our experience we consider PSP a useful small scale tool for teaching process measurement The basic measurements time size and number of defects are easily 112 A Inkeri Verkamo Asko Saura comprehensible to the students The series of exercises is long enough to allow some learning and also to show some basic difficulties in starting a measurement program The main drawback of the PSP exercises is the continuously changing process In our course seven exercises are performed using six different processes in the original course ten exercises using seven processes which means that in almost every exercise the student is required to learn some new measures In consequence the m
174. lberg 1998 Teu95 S Teufel C Sauter T M hlherr K Bauknecht Computerunterstiitzung f r die Gruppenarbeit Addison Wesley 1995 Tie01 D A Tietze A Framework for Developing Component based Co operative Applications Dissertation Technische Universit t Darmstadt 2001 Won03 K Wong W Blanchet Y Liu C Schofield E Stroulia Z Xing JRefleX Towards supporting small student software teams In Proceedings of the 2003 OOPSLA Workshop on Eclipse Technology eXchange S 50 54 2003 Eine Werkstatt zum Vermitteln objektorientierter Entwurfs und Sprachkonzepte mit Teachlets Axel Schmolitzky Arbeitsbereich Softwaretechnik Fachbereich Informatik Universitat Hamburg Vogt K lln Str 30 22527 Hamburg schmolitzky informatik uni hamburg de Zusammenfassung Teachlets sind eine neuartige Lehrform die urspr nglich f r die Vermittlung von Entwurfsmustern entwickelt wurde Ausgehend von lauff higem Code wird eine Aufgabe gestellt die gemeinsam und interaktiv von allen Teilnehmern in nerhalb einer Unterrichtseinheit gel st wird ein Moderator bedient dabei auf Zuruf den Rechner mit Entwicklungsumgebung und Beamer Teachlets k nnen bereits f r sich genommen als innovative Lehrform eingesetzt werden sie k n nen aber auch als Entwurfsgegenstand in seminarartigen Veranstaltungen die nen In der hier beschriebenen Lehrveranstaltung zu fortgeschrittenen Konzep ten objektorientierter Programmierung haben die Teilnehmer
175. lenderfunktionen von CURE zugreifen kann ohne dazu den Browser ffnen zu m ssen CodeBeamer wird mit einem Eclipse Plug in ausgeliefert das die Tracker in eine Sicht in Eclipse integriert Erste Erfahrungen haben gezeigt dass CURE und CodeBeamer Studierende bei der verteilten Softwareentwicklung unterst tzen und deren Kollaboration erleichtert Zusammen mit weiteren Plug ins die entsprechend erweitert oder angepasst werden m ssen wird diese Plattform die Durchf hrung von Softwaretechnik Projekten nicht nur in der Fernlehre in allen Phasen erleichtern Studierende werden in der Lage sein einfacher und effizienter zu kollaborieren sie werden ihr Projekt leichter verwalten k nnen und ein besseres Endprodukt abgeben k nnen Da nahezu s mtliche Vorg nge 92 Philipp Bouillon Jens Krinke Stephan Lukosch persistent gehalten werden Kommunikation tiber Chat und Mail Tracker Versions kontrolle wird es fiir die Betreuer leichter sein einzelne Studierende separat zu bewerten Die vorgestellte integrierte Entwicklungsumgebung mit CURE und CodeBeamer wird zurzeit zum ersten Mal eingesetzt Uber erste Erfahrungen mit dem Einsatz der Entwicklungsumgebung haben wir berichtet Eine abschlie ende Evaluation der Kolla boration in den Gruppen wird zeigen ob Studierende weitere Hilfen und Werkzeuge ben tigen und ob sie die bereitgestellten Hilfsmittel akzeptieren Literatur Bou03 P Bouillon M Burger A Zeller Automated debugging in
176. lenspielen in denen im Tutoren kreis bungen des Praktikums durchgef hrt werden Selbstverst ndlich m ssen alle Tutoren das Praktikum kennen also selber bereits absolviert haben Einige spielen passive Teilnehmer dies ist das typische Leistungsproblem Teamprobleme wie Domi nanz Einzelner k nnen gleich mittrainiert werden Der Tutor muss nun von vorher besprochenen Reaktionsm glichkeiten eine angemessene anwenden Beispiele rein beschreibendes Feedback aktives Eingreifen Ihr beide habt euch dieses Mal kaum beteiligt bitte bernehmt in der kommenden Woche die oder sogar eine Anwei sung mit Benennung einer Konsequenz Wenn du einen Leistungsnachweis willst Als Einleitung der Schulung beschreiben die Tutoren Probleme die sie als fr here Kursteilnehmer erlebt haben und sagen wie sie sich L sungen vorstellen Diese Schu lung wird nur wirksam wenn die Erwartungshaltung ber das Semester aufrechterhal ten wird Dies erfolgt indem Praktikumsleiter und Tutoren beobachtete Teamprobleme und deren L sungen diskutieren Der Praktikumsleiter fragt immer wieder nach Prob lemen Bitte sagt wo es dr ckt ich h re euch zu Wenn Tutoren nicht ber Proble me berichten ist dies ein klares Zeichen dass sie ihre Aufgaben der Leistungskontrolle und als Teamarbeitsmentor nicht wahrnehmen Projektplan Beim Programmieren ist individuelle Leistungskontrolle schwierig da dies meist au erhalb der Pr senzzeit geschie
177. ll dienen das gute Praktiken der Softwareentwicklung vorlebt Als Nachteil von Teachlets ist zu bemerken dass sie ausschlie lich in echten Lehr situationen evaluiert werden k nnen Auf diese Weise reifen sie nur sehr langsam Ausblick Zuk nftig gilt es zu untersuchen inwieweit die zu vermittelnden Inhalte und die Teil nehmerzahl eines Teachlets variiert werden k nnen Es wurde bisher nur wenig Erfahrung bei der Vermittlung von Programmier sprachkonzepten gesammelt obwohl dies urspr nglich f r die Teachlet Eine Werkstatt f r Teachlets 103 Werkstatt vorgesehen war Aufgrund der Wahlm glichkeiten der Teilnehmer gab es keine Teachlets zu beispielsweise multipler Implementierungs Ver erbung Generizit t oder Multi Methoden Hier m ssen weitere Erfahrungen gesammelt werden Auch das Vermitteln von Algorithmen k nnte durch den Einsatz von Teachlets interessanter gestaltet werden insbesondere weil die Einbettung eines Algorithmus in einen Problemkontext vermutlich stark mo tivierend f r die Studierenden ist e Es sollte untersucht werden inwieweit der Ansatz skaliert d h mit welcher Anzahl von Teilnehmern das Konzept maximal umsetzbar ist Wenn die Gruppe sehr gro wird Kann sich nicht mehr jeder Teilnehmer einbringen Trotzdem k nnte der Einsatz von Teachlets auch bei gr eren Gruppen fruchtbar sein weil die passiven Teilnehmer an der interaktiven Probleml sung die von den aktiveren Teilnehmern voranget
178. lls erm glichen soll das in der noch leeren Listbox rechts unten darzustellen ist 2 i Protokoll Ausgangswert 1 Operand 1 V anzeigen Abb 1 Die grafische Oberfl che des Ausgangssystems Das eigentliche Kopfrechentraining wird nun wie folgt durchgef hrt Der Anwender w hlt per Knopfdruck einen der vier Operatoren aus sodass dieser im Hintergrund auf die Ausgangswert genannte Zahl als ersten Operanden und den mit Operand be zeichneten Wert als zweiten Operanden angewandt wird Dieses Ergebnis stellt im n chsten Rechenschritt den ersten Operanden dar w hrend unter Operand ein neuer zuf llig gew hlter Wert von 1 bis 9 erscheint welcher wiederum den zweiten Operan den der folgenden Operation repr sentiert Der urspr ngliche Ausgangswert wird mitt lerweile ausgegraut um zu verdeutlichen dass er nicht mehr direkt in die folgenden Operationen involviert ist Nach Klick auf das Gleichheitszeichen wird das aktuelle Resultat schlie lich angezeigt und zwar wieder schwarz unter Ausgangswert Bei der n chsten Folge von Rechenoperationen stellt er folglich auch den neuen Ausgangswert dar Das Programm wird gestartet und der Moderator f hrt die Funktionalit t einmal ei genst ndig vor Anschlie end ermuntert er die Teilnehmer ihn bei der Benutzung anzu leiten um mit ausreichenden Wiederholungen allen Teilnehmern die Funktionalit t klar zu machen Dieser einleitende Abschnitt sollte ca 5 bis h chsten
179. ls XY beispielsweise als Adapter bezeichnet wird Dies war meist dann sinnvoll wenn das Entwurfsmuster selbst nicht sehr kompliziert ist und prim r der Terminologiebildung dient Andere Teachlets wurden mit einer Beschreibung des Lernziels eingeleitet weil das Entwurfsmuster zu anspruchsvoll ist um von den Teilnehmern innerhalb der Lernein heit selbstst ndig abgeleitet zu werden Dies war bei einem Teachlet zum Interpreter muster so und w rde vermutlich auch etwa beim Besuchermuster so sein Hier wird die grundlegende Struktur des Musters zuerst vorgestellt und anschlie end das Muster auf eine konkrete Problemstellung angewendet Abweichend von der Darstellung im letzten Abschnitt kann es auch sinnvoll sein die Aufgabe zu stellen bevor die Architektur des Ausgangssystems untersucht wurde Wenn die Aufgabe sich ausschlie lich auf die Funktionalit t bezieht kann es f r die Teilnehmer sogar sinnvoller sein sich problemorientiert in den Quelltext einzulesen 4 1 Hinweise f r Moderatoren Die Moderation eines Teachlets ist anspruchsvoll anspruchsvoller als beispielsweise ein reiner Folienvortrag Grunds tzlich gelten die blichen Hinweise zu Folienvortr gen auch f r Teachlets insbesondere f r den Folienanteil Ein Teachlet wird h ufig im Sitzen moderiert F r den Folienanteil ist das m gli cherweise ungewohnt es sollte dem Moderator vorher bewusst sein Der Moderator sollte auch den Teachlet Rechner kennen um Tastenkombina
180. lt tung lierten Projekts anderen Teilneh bei gezielten Inter mer Zeitknappheit ventionen Gef hle Je schneller und Wenn Hektik ent Zum Teil sehr aus zweiter Hand glatter die Simula tion l uft umso weniger steht schlagen auch Gef hle hoch stark da echte Konse quenzen drohen z B kein Schein Bewertung ist auch gef hlsbeladen Schlussfolgerun gen Kaum d SESAM selbst erfordert Nachbesprechung Nachbesprechung wichtig sprudeln dann Entstehen beson ders um Interventi onen Bildet sich aus Inhalt und Bewer tungen 24 Kurt Schneider Freilich reichen unsere R ckmeldungen und Frageb gen nicht aus um die hier pr sen tierten Schlussfolgerungen statistisch zu belegen aber dieses Material hilft uns doch immerhin deutlich ber das Niveau pers nlicher Vermutungen hinauszukommen Der direkte Vergleich zeigt dass mit dem Werkzeug eine andere Art von Erfah rungsvermittlung gemeint ist n mlich die technische Speicherung und der Vertrieb Es zeigt sich auch dass Nachbesprechungen f r die drei anderen Varianten sehr wichtig sind was zwar nicht berrascht aber auch nicht selbstverst ndlich ist Lew O1 Beson ders eine reine Simulation wie SESAM erfordert unbedingt eine Nachbesprechung damit sich nicht falsche Schl sse festsetzen schon vor zehn Jahren waren viele Teil nehmer schnell bereit unerw nschtes Projektverhalten der angeblich fehlerhaften Simulation
181. m Grundstudium wo viel Wert auf formal saubere Beschreibungen von Informatik Inhalten gelegt wird 6 7 DI 7 Diagramme 5 entwickeln 4 4 GS cur 3 3 EEE implementieren 2 2 CE Testen 1 all Mittel weh BEE Sonstiges 0 0 0 0 Woche 1 Woche 3 Woche 1 Woche 3 Woche 2 Woche 2 Abb 3 Tatigkeiten der Gruppen links UML Gruppen rechts XP Gruppe Im iterativen XP Prozess wird durch eine konsequente Beschr nkung auf das Wesentliche ein komplexes Problem einfacher l sbar und es entsteht sehr schnell eine erste funktionierende Version des Programms Durch st ndige Integration neuer Funktionalit t wird das Programm in kleinen Iterationen schrittweise ausgebaut Bei einer UML basierten Vorgehensweise muss in den fr hen Phasen viel Zeit f r die Modellierung aufgewendet werden Es besteht dabei die Gefahr dass trotz hervorragender Modellierung nach Ablauf der Projektzeit kein lauff higes Programm vorliegt Bei der XP Vorgehensweise entsteht bereits in der ersten Iteration eine vorzeigbare Version des Programms Das f hrt fr hzeitig zu Erfolgserlebnissen und tr gt zur Motivation bei Abbildung 3 zeigt deutlich wie unterschiedlich die verschiedenen Entwicklungst tigkeiten zu Buche schlagen W hrend die UML Gruppen links die einem wasserfallartigen Prozess Schm01 folgen zun chst Diagramme erstellen und 120 Doris Schmedding und Ingrid Beckmann dann implementieren sowie testen implementiert die XP Gruppe von Anfang an
182. m Praktikum ge nerell speziell aber mit den beiden alternativen Ausbildungskonzepten gesam melt wurden wird im Folgenden berichtet 1 Einleitung In vergangenen SEUH Workshops wurden h ufig die Konzeption sowie Erfahrungen bei der Durchf hrung von Software Praktika vorgestellt in SEU 99 beispielsweise war dem Thema Software Praktika eine eigene Sitzung gewidmet Die geschilderten Erfahrungen beziehen sich auf sehr unterschiedliche Studiensituationen und Rahmen bedingungen Praktika im Grundstudium oder im Hauptstudium Praktika mit sehr vie len oder relativ wenigen Teilnehmern Praktika die intern innerhalb der Hochschule oder extern in Zusammenarbeit mit Softwarefirmen durchgef hrt wurden Das Softwaretechnologie Praktikum an der TU Dresden Stp 04 ist f r die Studien g nge Informatik Medieninformatik und Informationssystemtechnik eine Pflichtveran staltung von zwei Semesterwochenstunden SWS im Grundstudium auch im Erg n Softwaretechnologie Praktikum im Grundstudium 125 zungsstudiengang Softwaretechnik obligatorischer Bestandteil und baut auf der Vorle sung Ubung Softwaretechnologie I auf Analog ist die Situation in den Studieng n gen Informatik und Wirtschaftsinformatik der UniBW M nchen Die aus dem Frame work SalesPoint und einer umfangreichen Dokumentation bestehende Praktikums infrastruktur wurde von beiden Universit ten gemeinsam entwickelt gepflegt und ge nutzt Dar ber haben wir in Dem
183. mation Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie detaillierte bibliografische Daten sind im Internet ber lt http dnb ddb de gt abrufbar ISBN 3 89864 328 X 1 Auflage 2005 Copyright 2005 dpunkt verlag GmbH Ringstra e 19 b 69115 Heidelberg Die vorliegende Publikation ist urheberrechtlich gesch tzt Alle Rechte vorbehalten Die Verwendung der Texte und Abbildungen auch auszugsweise ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar Dies gilt insbesondere f r die Vervielf ltigung bersetzung oder die Verwendung in elektronischen Systemen Alle Informationen in diesem Buch wurden mit gr ter Sorgfalt kontrolliert Weder Autoren noch Verlag k nnen jedoch f r Sch den haftbar gemacht werden die in Zusammenhang mit der Verwendung dieses Buches stehen In diesem Buch werden eingetragene Warenzeichen Handelsnamen und Gebrauchsnamen verwendet Auch wenn diese nicht als solche gekennzeichnet sind gelten die entsprechenden Schutzbestimmungen Vorwort Der vorliegende Tagungsband enth lt die Beitr ge zum 9 Workshop Software Engi neering im Unterricht der Hochschulen SEUH 1992 von Jochen Ludewig ins Leben gerufen findet dieser Workshop alle zwei Jahre statt Er wird von der Gesellschaft fiir Informatik und dem German Chapter of the ACM gemeinsam mit der Schweizer Infor matik Gesellschaft durchgef hrt Ausb
184. mente oder Codefragmente nicht explizit als richtig oder falsch einge stuft werden So sind z B bereits erste richtige Ans tze als Erfolg zu werten w hrend Fehler aufgrund mangelnder Arbeitsmoral nicht toleriert werden k nnen Daraus resul tieren gewisse Unsicherheiten sowohl bei den Tutoren als auch bei den Studierenden die durch strenge Richtlinien und intensive Anleitung der Tutoren minimiert werden m ssen Dazu finden w chentliche Tutorenbesprechungen statt Bei den Studenten im externen Praktikum ist der Einsatz von Druckmitteln seltener n tig Durch die Arbeit in einer Firma an einer realen Aufgabe ist die Motivation erheb lich h her Hier liegen die Probleme dann oft in anderen Bereichen So k nnen Diskre panzen zwischen den Anforderungen der Firma und den F higkeiten der Studenten entstehen die im Grundstudium mit vielen Technologien noch nicht vertraut sind Auch dadurch kann es zu einer Demotivation kommen die jedoch andere Ursachen hat und mit anderen Mitteln als im internen Praktikum zu beheben ist Als hilfreich hat sich das Durchf hren einer Zwischenpr sentation erwiesen bei der die Studierenden den aktu ellen Arbeitsstand vorstellen und selbst einen berblick ber bisher Erreichtes erhalten Dabei k nnen dann auch seitens des Lehrstuhls die Anspr che der Firmen mit den Leis tungsgrenzen der Studenten abgeglichen werden Im internen Praktikum sind solche Softwaretechnologie Praktikum im Grundstudium 131 Zwischenp
185. muster die im Quellcode umgesetzt worden sind wurden nicht richtig in den Diagrammen dargestellt Ihre Aufgabe ist es nun die fehlenden Entwurfsmuster in zwei dieser Klassendiagramme einzuf gen Die 12 TeilnehmerInnen der Veranstaltung wurden in 3 Gruppen eingeteilt Die Aufga ben wurden nahezu vollst ndig in Teamarbeit gel st Auf diese Weise waren die Stu dierenden gezwungen miteinander zu kommunizieren und zu lernen gemeinsam schwierige komplexe und sehr umfangreiche Aufgaben zu l sen Jedem Team wurde ein pers nlicher Betreuer zur Seite gestellt der in Inhaltsfragen als Ansprechpartner zur Verf gung stand und als Teamleiter fungierte Im Nachfolgenden wird kurz genauer auf die wichtigsten Inhalte der beiden Ab schnitte des Semesters eingegangen mit Hauptaugenmerk auf die h ufig vernachl ssig ten Qualit tssicherungsma nahmen in Abbildung 1 fett hervorgehoben Die Folien sind unter http www swe informatik uni heidelberg de herunterladbar Ubungsmateri alien sind auf Nachfrage erh ltlich Bottom up vom Quellcode zu den Anforderungen Wie in Abbildung 1 zu erkennen ist wurde das Semester mit einem Crash Kurs in Java begonnen Um die Wissensl cken auf dem Gebiet der Java Programmierung zu ber br cken wurde innerhalb eines dreist ndigen Vortrags Basiswissen ber Java Java Servlet und Eclipse vermittelt Innerhalb der folgenden Woche erhielten die Studieren den zus tzlich zu den SWE Aufgaben drei Hausaufgaben i
186. n Projektplanung Konzeption Pro grammierung Teamarbeit Pr sentation Kundengespr che etc spannen ein Feld auf welches sich jeder einzelnen Pr fungsmethode entzieht Wissensabfrage L sen schrift licher Aufgaben Durchf hrung von Experimenten Beobachtung der Arbeit der Studie renden ber ein Semester Pr sentationen Rollenspiele Kontrolle der Teamleistung Kontrolle der Einzelleistung sie reichen alleine alle nicht aus Vielmehr ist eine sehr differenzierte Leistungskontrolle unter Nutzung aller Kan le erforderlich auch derjeni gen die mehr Aufwand kosten Erschwerend kommt hinzu dass im Software Enginee ring hohe Studierendenzahlen oft der gesamte Studienjahrgang typisch sind Generell stellt sich die Frage wie kommunikative F higkeiten in Informatik Studieng ngen besser geschult und sogar zum Gegenstand von Pr fungen gemacht werden k nnen In anderen Disziplinen zum Beispiel in der Gesangs und der Theater ausbildung geh ren solche Pr fungen zum Alltag Wir haben uns in diesem Beitrag vor allem auf Erfahrungen an der Universit t Z rich sowie ausgew hlte Ver ffentlichungen anderer Autoren gest tzt Nat rlich gibt es eine Menge weiterer Literatur zu diesem Thema insbesondere zur generellen Frage didakti scher Ziele und deren Erreichung Eine umfassende bersicht w rde jedoch den Rah men dieser Ver ffentlichung bei weitem sprengen Wir nehmen in diesem Beitrag eine andere Perspektive ein als dies bei
187. n bestehend aus 6 Studierenden f hrte ihr zweites Projekt nach der XP Vorgehensweise durch w hrend die anderen nach einer UML basierten Vorgehensweise Schm01 arbeiteten Das erste Projekt f hrten alle Gruppen nach der UML basierten Vorgehensweise durch die in der dem Praktikum vorangehenden Softwaretechnik Vorlesung gelehrt wird Dass nur eins der vier Praktikumsteams XP ausprobieren durfte h ngt mit dem gro en Betreuungsaufwand in einem XP Projekt zusammen Ein XP Coach in diesem Fall die Gruppenbetreuerin muss immer anwesend bzw sofort erreichbar sein Wissen auch ber den Entwicklungsprozess wird in direkter Kommunikation vom Coach weitergegeben Au erdem wollten wir die XP Gruppe bei der Arbeit beobachten Zur Einf hrung der XP Konzepte wurde in den beiden Lehrveranstaltungen jeweils zu Beginn ein XP Spiel durchgef hrt um den iterativen Ablauf eines XP Projekts kennen zu lernen und die Begriffe und die Rollen einzu ben wie es z B in AuMi01 beschrieben ist Dieser Einstieg hat sich sehr bew hrt und kann nur weiterempfohlen werden Auf der Informatica Feminale hatten die Teilnehmerinnen sich au erdem durch Literaturstudium und durch Kurzvortr ge in die Konzepte von XP eingearbeitet Im Software Praktikum haben wir nach dem Prinzip learning by doing gearbeitet Refactoring wurde vermittelt indem nach der ersten Iteration mit Hilfe eines Beamers gemeinsam der Code verbessert wurde Dabei wurde das Tool Refactorlt einges
188. n Studierenden aus Diplomstudieng ngen als auch von Studie renden aus einem internationalen Masterstudiengang besucht wird 1 Einleitung In den vergangenen Jahren hat die industrielle Softwareentwicklung immer mehr an Bedeutung f r die Ingenieurwissenschaften gewonnen Sie macht einen nicht zu ver nachl ssigenden Teil der beruflichen T tigkeit der Ingenieure aus Es ergibt sich daher die Notwendigkeit diese Tatsachen auch in der Lehre zu ber cksichtigen und Studie rende in Ingenieurstudieng ngen umfassend auf dem Gebiet der Softwaretechnik zu unterrichten Ein wesentliches Problem hierbei ist der mangelnde Bezug zur Praxis Im regul ren Lehrbetrieb der Hochschulen werden den Studierenden die fachlichen Grund lagen in Form von Vorlesungen und bungsveranstaltungen vermittelt Zwangsl ufig sind die gelehrten Inhalte sehr theoretischer Natur und erscheinen nicht nur unn tig komplex sondern auch fern der von vielen Studierenden auf die Programmierung redu zierten Softwareentwicklung Eine Ursache hierf r ist die Tatsache dass Studierende der Ingenieurwissenschaften im Verlauf des Studiums keine oder wenig praktische Er 42 Peter G hner Friedemann Bitsch Hisham Mubarak fahrung mit der systematischen und industriellen Softwareentwicklung sammeln k n nen Die Vermittlung der Lehrinhalte scheitert daher zumeist an der Akzeptanz der Notwendigkeit Software systematisch zu entwickeln Gleichzeitig erwartet die Industrie Hochschulabsol
189. n den Universit ten wird mit XP experimentiert Williams und Upchurch WiUp01 diskutieren welchen positiven Einfluss die Konzepte von XP in der Softwaretechnik Ausbildung haben k nnten Der tats chliche Einfluss auf den Wissensstand der Studierenden l sst sich schlecht messen aber ebenso wie wir konnten sie feststellen dass die im XP Kurs erzeugten Programme eine hohe Qualit t besitzen Lippert et al LRWZO1 beschreiben ebenfalls den Einsatz von XP in einem Grundstudiums Praktikum Zwei Praktikumsgruppen die beide nach der XP Vorgehensweise arbeiteten werden miteinander verglichen Die Projektteams unterscheiden sich in erster Linie dadurch wie viel Einfluss die Betreuer auf den Ablauf des Projekts genommen haben Entsprechend mehr oder weniger chaotisch lief der Entwicklungsprozess ab In MSK04 berichten die Autoren welche Konflikte bei der Simulation betrieblicher Abl ufe in einer Lehrveranstaltung auftreten k nnen Als ein Ergebnis der beschriebenen XP Praktika an der Universit t Bonn ist ein Rollenkonzept f r die Lehre von XP an der Universit t entstanden Angeregt durch die Beispiele wollten wir eigene Erfahrungen mit XP sammeln Die berwiegend positiven Erfahrungen auf der Informatica Feminale haben uns ermutigt 116 Doris Schmedding und Ingrid Beckmann direkt im Anschluss XP auch im Software Praktikum auszuprobieren Das Praktikum fand als sechsw chige ganzt gige Blockveranstaltung statt Eine von vier Arbeitsgruppe
190. n denen sie selbstst ndig Java Programmieraufgaben steigender Komplexit t l sen sollten Als Einarbeitung in die Oberfl che f hrten die Studierenden Usability Tests anhand vorgegebener Szenarien aus In der Vorlesung erfolgte an dieser Stelle auch eine erste Einf hrung in das Gebiet Qualit tssicherung Die zweite bung besch ftigte sich mit dem Quellcode von Sysiphus Neben der Ableitung von Klassendiagrammen aus dem Code lernten die Studierenden Programmierrichtlinien kennen und den Code damit zu verbessern In der dritten und vierten bung sollten sich die Studierenden haupts chlich mit den Modellierungstechniken und dem Integrationstest besch ftigen Doch es wurde schnell klar dass es weder in der Vorlesung noch in den bungen m glich war alle Dia 64 Barbara Paech Lars Borner J rgen R ckert Allen Dutoit Timo Wolf grammarten ausreichend zu behandeln Wir entschieden uns die bungen zum Thema Architektur Sequenzdiagramme und Integrationstest in den zweiten Teil des Semesters zu verlegen Das Thema Architektur erfordert einen gewissen berblick der in der zweiten H lfte eher vorhanden ist Sequenzdiagramme kann man am besten motivieren bei der Ableitung von Klassendiagrammen aus Use Cases d h beim Forward Enginee ring und Integrationstest baut auf Architektur und Sequenzdiagrammen auf In den Aufgaben zum Thema Modellierungstechniken erstellten die Studierenden einerseits aus dem Code Zustandsdiagramme und anderersei
191. n der Aufgaben soll das Lernziel durch gemein same Programmierung erreicht werden Ein Foliensatz zur Darstellung von Ausgangssystem Lernziel und Aufgabe zur Erl uterung grundlegender Terminologie aber auch zur Diskussion von L sungsalternativen und Verallgemeinerungen erg nzend sind Hand outs m glich Das Ausgangssystem sollte klein genug sein um von den Teilnehmern in 15 bis 20 Mi nuten erkundet werden zu k nnen Dabei sollte deutlich zwischen nach au en sichtba rer Funktionalit t und innerer Architektur unterschieden werden Die Funktionalit t sollte klar beschrieben bzw leicht erkundbar sein Als sehr motivierend haben sich Ausgangssysteme mit einer grafischen Oberfl che erwiesen 2 2 Dynamik eines Teachlets Die Qualit t eines Teachlets zeigt sich erst bei der Durchf hrung in einer Unterrichts einheit Abh ngig von den beteiligten Personen k nnen ausgehend von derselben stati schen Teachlet Struktur unterschiedliche Verl ufe auftreten Ein Einsatz eines Teach lets in einer Lehr oder besser Lerneinheit wird im Folgenden als Teachlet Einheit be zeichnet Eine Teachlet Einheit verh lt sich zur statischen Beschreibung aus dem vori gen Abschnitt wie ein Exemplar zu seiner Klasse in der Objektorientierung Eine typi sche Teachlet Einheit dauert 90 Minuten Jede Teachlet Einheit hat eine Anzahl an Teilnehmern und einen Moderator der das Teachlet mit Hilfe eines Rechners dem Teachlet Rechner an den ein Beame
192. n die Aussage dass ihnen das Studienprojekt ins gesamt Spa gemacht hat Entscheidend hierf r war die positive Grundstimmung im Projektteam der reale Einsatz der Software au erhalb der Hochschule der hohe Stel lenwert der Software f r den Kunden der Einsatz interessanter neuer Technologien und die M glichkeit zur Erweiterung der eigenen Kenntnisse Die Beteiligung eines hochschulexternen Kunden beurteilten alle Studenten als po sitiv Hierbei war vor allem von Bedeutung dass eine sehr hohe Motivation bestand das Projekt erfolgreich durchzuf hren Dies wurde von den Studenten mit realistischen Arbeitsbedingungen und einer erh hten Erwartungshaltung an die Funktionalit t des Produkts begr ndet Als ebenfalls motivationssteigernd wurde die M glichkeit genannt Vorgehensweisen in der Softwareentwicklung au erhalb der Universit t kennen zu ler nen Von den Studenten wurde lediglich negativ beurteilt dass aus ihrer Sicht nach Projekte der Lehre mit hochschulexternen Kunden 143 Beendigung des Projekts zu wenig Feedback durch die hochschulexternen Kunden ge geben wurde Die Frage ob sie ein hnliches Projekt nochmals durchf hren w rden bejahten 8 von 9 Studenten Dabei war vor allem ausschlaggebend dass diese Art von Projekt eine sehr gute Vorbereitung auf reale Projekte in der Industrie bietet und die h heren Anfor derungen an die Projektdurchf hrung die Motivation steigern 3 8 AbschlieBende Bewertung Die Betreuung des
193. n erh hten Arbeitsaufwand bedeutet Allerdings ist dadurch der pers nliche Gewinn auch h her da sich die Studenten im externen Praktikum oft selbstst ndig mit sehr aktuellen Technologien besch ftigen m ssen was ihnen im weiteren Verlauf ihres Studiums bzw im sp teren Berufsleben von Nutzen sein kann Im externen Praktikum ist die Forderung nach Ver ffentlichung von Modellierungs ergebnissen und Implementationsdetails meist nicht durchzusetzen da hier die Geheim haltung von Firmeninterna Vorrang hat Das f hrt h ufig dazu dass die Studenten die Dokumentation generell vernachl ssigen was sich am Ende des Projekts auch in einer mangelhaften Anwender und Entwicklerdokumentation widerspiegelt 4 Beobachtungen und Erfahrungen Die Planm igkeit des Softwareentwicklungsprozesses hat im Praktikum einen hohen Stellenwert W hrend jedoch im internen Praktikum durch die l ckenlose Betreuung die Einhaltung eines sauberen Entwicklungsprozesses durchgesetzt wird neigen Studen ten im externen Praktikum oft zu einer missverstandenen Form des Extreme Program ming Die Ursache daf r liegt darin dass die Betreuung in den Firmen eher ergebnis orientiert verl uft im universit ren Rahmen dagegen eher prozessorientiert Anderer seits stellt die gr ere Freiheit im externen Praktikum auch eine Chance f r einen gr Beren Lernerfolg dar Im internen Praktikum erhalten die Studenten strenge Vorgaben zu welchem Zeitpunkt welches UML Diagramm
194. n sehr positiv bewertet Sowohl Studierende als auch die wissenschaftlichen Mitarbeiter gewinnen durch das Fachpraktikum in vielf ltiger Weise Erfahrungen f r das Berufsleben F r beide stellt das Arbeiten in bzw das Betreuen von multikulturellen Teams eine Herausforderung dar W hrend des Praktikums bringen die kulturell bedingten unterschiedlichen Ar beitsweisen sowie Kommunikationsprobleme aufgrund von Sprachschwierigkeiten vie le Probleme und Schwierigkeiten mit sich die im Nachhinein betrachtet jedoch sowohl 54 Peter G hner Friedemann Bitsch Hisham Mubarak von den Betreuern wie auch von den Studierenden als wertvolle Erfahrungen gewertet werden Die wissenschaftlichen Mitarbeiter werden durch die besondere Konstellation des Fachpraktikums darin geschult Personalverantwortung zu bernehmen Sie tragen die Verantwortung f r die funktionierende Zusammenarbeit das zielorientierte Arbeiten und die kompetente Betreuung in allen Teams Sie m ssen Probleme in der Teamarbeit und Schwachstellen in der Projektbearbeitung erkennen und Verantwortung daf r tra gen dass eine rechtzeitige Auseinandersetzung mit Problemen stattfindet Sie machen Erfahrungen damit wie unterschiedliche Studierende auf verschiedene Weise motiviert werden m ssen Viele Studierende konnten in dem Praktikum Erfahrungen aus Fehlern sammeln die wesentlich gr ere Auswirkungen gehabt h tten wenn ihnen diese erst sp ter im Be rufsleben passiert w ren Studie
195. n zum Probleml sen auf Mikro Ebene vor Zun chst Problemanalyse und Zieldefinition Ergebnisorientierung Es wird festgelegt was hinten rauskommen soll Als Zweites wird die Meilensteinplanung Zeitorientierung Es wird eine Deadline f r die Aufgabe bestimmt und die Zeit bis zur Deadline in Einzel schritte aufgeteilt die Einzelschritte sind definiert durch die Teilergebnisse bzw den Reifegrad eines Ergebnisses das am Ende des Schrittes vorliegen soll Danach je nach Situation zum Beispiel wenn es um Strategien gemeinsame Ideenfindung Diskussionen oder Beschl sse geht gemeinsames Arbeiten im Team Weite Phasen Sammeln von Ideen zum Beispiel in einem Brainstorming Enge Phasen Bewerten von Ideen Aussortieren und Entschei den Oder paralleles Arbeiten in Kleingruppen Arbeitsteilung Die vermittelten Arbeitstechniken und Probleml seschritte haben die Studierenden im anschlie enden Miniprojekt selbstst ndig ausgew hlt und angewendet 3 6 Miniprojekt Etwa die H lfte des Teamtrainings bestand aus einem Miniprojekt In dieser Phase haben die Studierenden selbstst ndig gearbeitet wurden dabei von den Trainern be obachtet und etwa alle 30 Minuten unterbrochen um Feedback und Tipps zu geben Ziele des Miniprojekts waren Die Studierenden sollten die gelernten Techniken siehe Abschnitt 3 4 Teamwork selbstst ndig einsetzen und dadurch ihr Verst ndnis vertiefen die Trainer sehen wie di
196. nd termingerechter Anfertigung der Dokumente h lt die Softwaretechnologie Praktikum im Grundstudium 127 Studierenden durch die Au enwirkung aber auch zu vollst ndiger und gewissenhafter Arbeit an F r alle Studierenden des Praktikums ist die Verwendung des Versions verwaltungssystems CVS vorgeschrieben Dies vermittelt den Nutzen eines solchen Systems in der arbeitsteiligen Softwareentwicklung Auf der anderen Seite stellt das CVS ein Kontrollinstrument dar das den Betreuern der Teams vor allem w hrend der Implementierung erlaubt den Projektstand zu berwachen und die Beteiligung aller Studenten am Projekt zu berpr fen Sowohl f r das interne als auch f r das externe Praktikum wird die entsprechende Infrastruktur zentral bereitgestellt Als positiv f r den Verlauf des internen Praktikums kann auch die Homogenit t und Vielzahl der Projekte angesehen werden Da alle Teams den gleichen zeitlichen Restriktionen und organisatorischen Rahmenbedingungen unterliegen und das Sa lesPoint Praktikum auf jahrelange Erfahrung zur ckgreifen kann entstand eine aus f hrliche Praktikumsdokumentation und es gibt sehr viele Beispielprojekte im Web Au erdem sto en viele Teams w hrend ihrer Arbeit auf die gleichen Probleme sodass gegenseitige Hilfe z B im Praktikumsforum m glich ist Und nicht zuletzt waren die studentischen Betreuer der Gruppen mit vielen anstehenden Schwierigkeiten auch w h rend ihres eigenen Praktikums konfrontiert und
197. nd wenn er die Rolle des Kunden spielt total unzufrieden sein wenn diese u erlichkeiten der Professionalit t nicht gegeben sind Ich muss die Zusammenarbeit mit Ihrer Firma berdenken wenn Sie solche Schmierpapiere produzieren Kundenorientiertes Denken Wenn Studierende oder Mitarbeiter gefragt werden was von einer Aufgabenliste f r den Kunden wichtig sein k nnte schaffen es viele sinnvoll Priorit ten festzulegen Dennoch versagen die meisten in realen Situationen da ihnen niemand sagt dass dies jetzt eine bung zum Priorisieren ist und nach welchen Kriterien sie das denn tun sollten Solche Situationen k nnen f r Ausbildungszwecke leicht hergestellt werden Den Teilnehmern wird nichts Besonderes gesagt sie bekom men zu wenig Zeit f r eine Aufgabe und der Kunde wartet auf das Ergebnis Im SoPra 2004 beispielsweise sollten die Teams aufgrund eines Kundengespr chs eine grobe Skizze der Benutzeroberfl che des B rsencafes anfertigen Es war unm g Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 5 lich in der zur Verf gung gestellten Zeit die vollst ndige Oberfl che zu entwerfen Aus Sicht des Informatikers ist die Administration der Artikel und Bestellungen zentral weil sie u a das Klassenmodell ergeben w hrend die Gestaltung der Anzeigetafel f r die Artikel mit variablem Preis sekund r ist F r den Auftraggeber den Wirt des B rsenca f s ist es umgekehrt Von de
198. ndardisierter Fragebogen verwendet der erprobt ist und auch in Betrieben eingesetzt wird Abbildung 2 zeigt dass alle Gruppen ihr Teamklima zu Beginn des Projekts Zeitpunkt 1 mit gut gt 3 5 bewerten Im Vergleich zu anderen Arbeitsteams in unserer Branche ist das ein guter Wert Ausgerechnet in der XP Gruppe 1 Gruppe war das Arbeitsklima am schlechtesten was wir vor der Befragung nicht ahnten In dieser Gruppe waren die Vorkenntnisse besonders heterogen was das kooperative Arbeiten belastete In allen Gruppen zeigt sich am Ende des Projekts ein verschlechtertes Klima Mit einer Verringerung des Mittelwerts um 0 08 f llt die Verschlechterung in der XP Gruppe am geringsten aus Die Standardabweichung Erfahrungen mit XP 119 nimmt bei allen Gruppen au er der XP Gruppe zu hier verringert sich der Wert Die Teammitglieder beantworteten die Fragen homogener als zu Beginn Da unsere Datenbasis so klein ist l sst sich aus dieser Beobachtung aber keine allgemeine Erkenntnis ableiten 3 3 Kleine Iterationen und st ndige Integration versus Modellierung und Dokumentation Anstelle von aufw ndiger Dokumentation in Form einer m glichst formalen Beschreibung wird durch st ndig wechselnde Partner bei der Arbeit erreicht dass das Wissen ber die Inhalte und den Fortschritt des Projekts innerhalb des Entwicklerteams verbreitet wird Die Betonung der Kommunikation gegen ber der Dokumentation steht eher im Gegensatz zu den bisherigen Lehrzielen i
199. nderer zu profitieren und andererseits entwickelte sich teilweise im Forum eine sehr fruchtbare fachliche Diskussion auf die der Mentor oder die Mentorin dann im Chat zuriickgreifen konnte 3 Fortgeschrittene synchrone Kommunikation Was die synchrone Kommunikation betrifft mussten wir feststellen dass ein reiner Text Chat fiir unsere Zwecke sehr unbefriedigend war Die meisten Diskussionen im Rahmen des Software Engineering Unterrichts drehen sich um Fragen der Model lierung Die Studierenden lernen schnell dass es das richtige Modell fiir ein Problem nicht gibt sondern nur je nach Intention mehr oder weniger gute Modelle Verschiede ne Alternativen asynchron zu diskutieren ist erm dend und schlie t selten die ganze Lerngruppe ein Daher wird ein synchrones Kommunikationswerkzeug ben tigt das Gruppen diskussionen am Flipchart simuliert Ein Whiteboard parallel zum Text Chat wie es die meisten Lernumgebungen anbieten ist eine Hilfe aber zumeist demotivierend schwer f llig und unflexibel Die Autorinnen haben deshalb oft Zusatzmaterial auf ihre Home page gestellt teils auch w hrend des Chats auf das sich der Chat beziehen konnte Aber allein die textuelle Bezugnahme ist unangemessen m hsam Im Netucate Lernraum haben wir eine empfehlenswerte Alternative gefunden Netucate bietet einen Audio Chat Video ist zuschaltbar mit einem zus tzlichen Text Chat f r Einw rfe und Zwischenfragen Zus tzlich zum Whiteboard g
200. nehmen das ein System zur Verwaltung der Schulungen einsetzt F r dieses System sollten die Anforderungen und das Handbuch mit dem Produkt nachdokumentiert wer den Dieser Kunde war auf das Werkzeug angewiesen Der Mitarbeiter der das Verwal tungssystem sehr genau kennt verl sst das Unternehmen Als zweiter Kunde stellte sich ein Softwareunternehmen zur Verf gung Alle Studienprojekte eines Semesters starten zu Semesterbeginn Die Studenten melden sich f r ihr Wunschprojekt an wollen zu viele Studenten an einem Projekt teil nehmen werden die Teilnehmer f r das Projekt ausgew hlt Alle Studenten k nnen Alternativprojekte angeben auf jeden Fall aber an einem Studienprojekt teilnehmen F r das Studienprojekt wurden nach der Anmeldung 10 Teilnehmer ausgew hlt 3 3 Projektorganisation Das Studienprojekt war als Entwicklungsprojekt organisiert also als Projekt f r die Herstellung eines Produkts f r den Softwaremarkt Die externen Kunden bernahmen die Rolle von Pilotkunden Ein Mitarbeiter fungierte als Marketing und interner Kunde Diese Organisation hat mehrere Gr nde e Der interne Kunde kann die Anforderungen der beiden Pilotkunden b ndeln und die Konsistenz so weit sichern dass ein Produkt machbar ist Da die Kunden aus sehr unterschiedlichen Bereichen kamen haben wir mit wider spr chlichen Anforderungen gerechnet e Das Ziel war ein erweiterbares Produkt zu erstellen das durch Plug ins f r unterschiedliche Zwecke ange
201. nfigur atin cls een n me U cortpcasn ie wed Ti I39 GOOGOO UG T Confguranonitest dans J Cortguratnten jeve Ly Mandata dass hom J MarOote java oP hrs 0000 A MyTest jve 1 Verf clone T Vertue jove Welcome to the Eclipse CURE plug in development home page Amapath or Please wi rieve the latest information on P Last modified by Philipp Bouillon 30 09 04 11 35 jumo t o Soong O Ove 1 9 Bist Fe Studer para T tenia free a gt Lennon and Deora Systems 1 30 09 10 55 58 Philipp Bowlen Welcome to the Eclipse CURE Plug In Development chat Feel a Bp Narsiens room free 10 ask any questions about the current plug in development w here or answer those questions 9 4 30 09 11 28 01 Philipp Boulliag Please let me remind you that LaTeX Syntax is alowed thus Si 5 oun_ x 1 insty tracti x 2 yalde S21 27 Pr E ue aow s S ws Tasks YA codetewrer tracer EE ad Cie Track Fikes machen 1607 of 197 tam D r amma ne ino Stared by Stans Abb 1 ECLIPSE mit CURE und CodeBeamer Sicht 3 2 Projektmanagement Softwareprojekte in der Fernlehre ben tigen genau wie andere Softwareprojekte auch ein strenges Projektmanagement Die Erfahrung an der FernUniversitat zeigt dass Teams die CURE zum Projektmanagement eingesetzt haben bessere Ergebnisse erzielt Eine Plattform f r die Softwaretechnik Fernlehre 87 haben als Teams die keine besonderen Werkzeuge
202. ngen besuchen Die Studierenden verwenden ca 8 14 Stunden pro Woche f r das Praktikum Zur Vermeidung von Stress und chaotischer Teamarbeit erhalten die Studierenden zu Be ginn des Fachpraktikums eine Einf hrung in das Thema Zeitmanagement angelehnt an Hump97 Dabei lernen sie im Hinblick auf ihre sp tere T tigkeit in der Industrie ihre Zeit selbstst ndig einzuteilen realistisch abzusch tzen die in der Realit t ben tigte Zeit zu erfassen und aufgrund dessen ihre Zeiteinteilung und absch tzung zu bewerten und kontinuierlich zu verbessern 5 Motivation der Studierenden Bei einer derartig arbeitsintensiven und zeitaufw ndigen Lehrveranstaltung stellt sich die Frage wie die Studierenden ber die gesamte Praktikumsdauer motiviert werden k nnen um ein Einbrechen der Motivation und der Lern bzw Leistungsbereitschaft zu vermeiden Dies ist sicherlich keine leichte Aufgabe und kann nicht durch einzelne sondern nur durch die Kombination abgestimmter Ma nahmen bew ltigt werden Dabei sind soziale und technische Aspekte zu ber cksichtigen Die Erfahrung zeigt dass die jenigen Teams am erfolgreichsten waren in denen ein ausgepr gter Teamgeist aufgrund der Motivation aller Teammitglieder entwickelt wurde Folgende Mittel werden am IAS erfolgreich zur Motivation eingesetzt Meilensteine Rollenspiel Teamarbeit Konkur renz eine herausfordernde Aufgabenstellung soziale Veranstaltungen und die Ergeb nispr sentation in Form eines Rob
203. ngen und war kein Problem in unserem Vollzeit Praktikum Gleichzeitig bestand in unserem Praktikum eine Anwesenheitspflicht die die Betreuung erleichterte und von den Teilnehmern positiv aufgenommen wurde Dies legt nahe dass der Wechsel zu einem Vollzeitpraktikum tats chlich einige spezifische Probleme eines semesterbegleitenden Praktikums l st 10 Fazit Mit dem Softwaretechnik Praktikum als 6 Wochen Sommerkurs k nnen wir nicht nur die vorlesungsfreie Zeit besser ausnutzen sondern es k nnen sich auch alle Beteiligten voll und ganz dem Praktikum widmen sei es in der Teamarbeit in der Betreuung oder in der Vorlesung Enthusiasmus geht nicht zu Lasten anderer Lehrveranstaltungen in den Semesterferien ist Abstimmung von Vorlesung und Praktikum kein Problem eine einheitliche Aufgabenstellung f r alle ist fair reduziert Risiken und vereinfacht das Finden genereller L sungen in der Betreuung Schlie lich hat der Wettbewerb die Mo tivation der Studierenden noch einmal erheblich gesteigert und so Freude an der Team arbeit und am Programmieren im Gro en vermittelt Insofern haben wir zahlreiche Probleme fr herer Praktika erfolgreich gel st was die Evaluation best tigt Offensichtlicher Mangel eines Blockkurses ist dass sich die Vorlesungsinhalte dem Praktikum unterordnen m ssen Erfahrungen aus fr heren Veranstaltungen zeigen dass Studierende im Praktikum genau an solchen Inhalten interessiert sind die ihnen einen 80 Christian Lind
204. nschaftlichen Mitarbeitern und externen Firmenver tretern betreut zum Teil in der Rolle der Kunden mit denen die Studierenden die Auf gabenstellung verhandelten zum Teil in der Rolle von Betreuern an die sich die Studierenden ratsuchend wenden konnten Bereits die Ausschreibung der Aufgabenstellung f hrte zu einer ersten Heraus forderung f r die Studierenden Sie mussten sich f r die Teilnahme am Praktikum formal bewerben Bei entsprechender Eignung wurden sie zu einem Auswahlgespr ch geladen das die Grundlage f r die Auswahl der Teilnehmer darstellte Kriterien f r die Auswahl von den Studierenden waren dabei neben fachlichen und technischen Kennt nissen beispielsweise Programmiererfahrung insbesondere auch die Bereitschaft ein berdurchschnittlich hohes Arbeitspensum zu bew ltigen und in einem selbstorganisier ten Team zu arbeiten Um den ausgew hlten zehn Studierenden das in der Einleitung beschriebene Funda ment zur Bew ltigung der organisatorischen und sozialen Problematik an die Hand zu geben und sie vor allem f r diese Art der Probleme zu sensibilisieren fand das Team training noch vor Beginn des Praktikums statt am ersten Semesterwochenende vom 23 bis 25 April 2004 Das Softwaretechnik Praktikum begann einige Tage sp ter mit einem Kick off am 27 April 2004 an diesem Kick off lernten die Studierenden ihre Betreuer und Kunden kennen bekamen die Aufgabenstellung in Form eines Lasten hefts und einen groben Proj
205. nsists of statistical software which is very different from the kind of programs that the students are used to working on Moreover statistical software packages exist in abundance so that writing yet another piece of software for this purpose is not motivating The advantage of using and testing your own software in doing the statistical calculations needed for measurement analysis is outweighed by the difficulty of understanding the concepts under a strained schedule We plan to change the topic of the exercises into something more familiar to the students As before the exercises should form a continuum that allows and encourages reuse of previous work at the same time producing software that the students might have a chance of using even later in their studies or work Finally a strong point of criticism that we feel necessary to address is the lack of measurement and analysis tools The original collection of paper sheets where students write down their measurements by hand has already been replaced by web pages both in our course and elsewhere Joh98 Mor00 Bor02 Likewise the students are provided Excel sheets with calculations of the various quality measures A more controversial topic is to what extent the analysis should be automated Certainly when this kind of analysis is used routinely in the industry the more it can be automated the better Mor00 On the other hand at the learning phase it is crucial to understand where the numbe
206. ntnisse so haben viele erst hier das Wechselspiel zwischen Kun den und Entwicklern im Planungsspiel richtig durchschaut Alle f hlen sich gef hls m ig stark angesprochen durchaus nicht immer nur mit positiven Gef hlen Und in der Reflexion haben die Teilnehmer leicht Zusammenh nge zwischen ihrem Verhalten und den Konsequenzen erkannt Alle Aspekte von Erfahrungen sind also intensiv ver mittelt worden Und das obwohl gar keine Software entwickelt wurde Hier hnelt die Agile Hour dem SESAM Ansatz In beiden F llen ist nur ein Kern authentisch der Rest hat nicht viel mit einem realen Software Projekt zu tun Wir hatten 48 Teilnehmer in den Agile Hours 31 haben per Fragebogen geantwortet Alle 31 haben angegeben die Agile Hour habe ihnen Spa gemacht Das reichhaltige m ndliche Feedback direkt Vier Formen der Erfahrungsvermittlung im Studium 21 nach den Agile Hours half uns die Intensit t der Erfahrungen in so kurzer Zeit als einen Grund dafiir zu identifizieren 4 Gezielte Eingriffe SWP04 Der dritte vorzustellende Ansatz klingt sicher besonders vertraut hnliche Versuche hat es schon viele gegeben Im letzen Wintersemester haben 46 Studierende Software Projekte SWPO4 in neun Gruppen zu je 5 6 Teilnehmern bei uns durchgef hrt Verschiedene Aufgabenstellungen wurden meist an mehrere Gruppen parallel vergeben Bei etwas genauerem Hinsehen haben solche universit ren Projekte oft nicht viel mit Industrieprojekten zu tun
207. nzipiert erstmalig durchgef hrt und von Katharina Spies evaluiert F r AutoRAID wurde das Training dann im Sommersemester 2004 zum zweiten Mal in der hier beschriebenen Form von Andreas Fleischmann durchgef hrt Teamtraining f r Software Ingenieure 31 3 2 Theoretische Grundlage Unsere Erfahrungen mit Teamarbeit in studentischen Projekten lassen sich mit der Teamkurve Abbildung 3 vereinfachend zusammenfassen L quantitative Leistung des Teams We a ae er ee t Projektverlauf Abb 3 Die Teamkurve W hrend man naiverweise erwarten k nnte dass die zehnfache Personenzahl in einem Team quantitativ zumindest ann hernd die zehnfache Leistung erbringt ist es in der Praxis oft so dass in einer Anfangsphase to bis t zehn Personen zusammen weniger leisten als eine Person alleine In dieser Phase der Teamfindung bilden sich Rollen und Infrastrukturen im Team Lan 00 Auch wenn diese Anfangsh rde berwunden ist wird ein Team nie die volle Leistung erreichen ab t da auch im perfekten Team immer Abstimmung und Koordination n tig ist Bei diesen beiden Problempunkten setzen wir im Teamtraining an Teambuilding soll die unproduktive Anfangsphase der Teamfindung bis t verk rzen und Frustration vermeiden und Teamwork Techniken sollen die Produktivit t in den anschlie enden Phasen erh hen ab t insbesondere ab tz Unserer Erfahrung nach d mpft schon alleine das Wissen um die Teamkurve die ans
208. oftwaretechnik Aus und Weiterbildung Darmstadt 2002 http www informatik uni stuttgart de ifi se publications download VortragDA pdf Sen 04 T Senninger Hrsg Kooperationsspiele eine Sammlung 2004 http www abenteuerprojekt de Spiele kooperation php Tau 01 D Taubner Software Entwicklung im industriellen Ma stab In J Desel Hrsg Das ist Informatik Springer Verlag 2001 Seite 85 98 http www sdm de dt tec pub art art seiim seiim pdf Softwaretechnik live im Praktikum zur Projekterfahrung Peter G hner Friedemann Bitsch Hisham Mubarak Universit t Stuttgart Institut f r Automatisierungs und Softwaretechnik Pfaffenwaldring 47 70550 Stuttgart goehner bitsch mubarak ias uni stuttgart de Zusammenfassung Hochschulabg ngern von Ingenieurstudieng ngen fehlt in der Regel Projekter fahrung sowie Erfahrungen mit Teamarbeit Um Studierende auf diese beiden wichtigen Aspekte der industriellen Praxis vorzubereiten bietet das Institut f r Automatisierungs und Softwaretechnik der Universit t Stuttgart das Fachprak tikum Softwaretechnik an dessen Konzept in diesem Beitrag vorgestellt wird Das Praktikum wird wie ein industrielles Projekt durchgef hrt Die Studieren den bilden Teams die wie kleine Firmen agieren und einen Auftrag zur Soft wareentwicklung termingerecht bearbeiten m ssen Die Studierenden sammeln Projekterfahrungen in international zusammengesetzten Teams da das Prakti kum sowohl vo
209. on Jens Krinke Stephan Lukosch FernUniversitat in Hagen 58084 Hagen philipp bouillon jens krinke stephan lukosch fernuni hagen de Zusammenfassung Softwaretechnik Lehre ist ohne entsprechende Praktika und Projekte nicht sinn voll An der FernUniversit t in Hagen ist die Softwaretechnik Lehre auch immer entfernte Lehre und die Anforderungen an die Softwaretechnik Praktika sind so mit h her Wir beschreiben eine integrierte Entwicklungsumgebung die auf Eclipse basiert und alle Werkzeuge die f r die entfernte Softwaretechnik Lehre n tig sind unter einer einzigen in sich geschlossenen Oberfl che vereint 1 Einf hrung Die Lehre der Softwaretechnik an Universit ten ist kompliziert Die Studierenden m s sen nicht nur mindestens eine Programmiersprache lernen und die Softwaretechnik sowohl theoretisch als auch praktisch verinnerlichen sondern sie m ssen zus tzlich auch noch lernen sich im Team zurechtzufinden Sie m ssen ihre Kommunikations f higkeiten verbessern und ein Verst ndnis f r die Probleme bekommen die sich w hrend der Entwicklung eines gro en realistischen Projekts ergeben Um das Ver st ndnis f r die Probleme der Softwareentwicklung zu sch rfen muss vom Dozenten eine gro e Projektaufgabe vorgegeben werden die sich von den Spielprogrammen aus Anf ngervorlesungen allein schon durch ihre schiere Komplexit t abhebt Um die Aufgabe als ganze bew ltigen zu k nnen werden die Studierenden in Teams einge
210. on Projektmanagement oder Groupware L sun gen unterst tzt dabei reicht die angebotene Bandbreite von Kommunikations Koordi nations und Kollaborationsunterst tzung bis hin zu vollst ndigen Softwaresystemen wie SourceForge oder GForge die bei Open Source Projekten zum Einsatz kommen In der Tat stellen die beiden letztgenannten Systeme eine gute Infrastruktur zur Erstel lung von gro en Softwaresystemen zur Verf gung weshalb einige Universit ten GForge benutzen Wir haben uns jedoch dazu entschlossen eine kommerzielle Variante zu verwenden Intlands CodeBeamer ist leichter zu bedienen und bietet gleichzeitig mehr Funktionalit t Eine weitere gro e Anforderung an die neue Plattform ist die M glichkeit f r die Betreuer des Projekts einzelne Studierende bewerten und benoten zu k nnen Au er dem m ssen die Betreuer die Gruppe bei Problemen beraten k nnen und ihnen Rat schl ge erteilen bevor es daf r zu sp t ist Zu diesem Zweck ist es wichtig dass ein Betreuer die Kommunikation der Gruppe nachvollziehen kann Sowohl die informellen projektbezogenen Gespr che als auch die eingeforderten Dokumente die w hrend des Projekts entstehen m ssen analysiert werden k nnen Au erdem muss nat rlich auch das Endprodukt also die entstandene Software jeder Gruppe ausprobiert und bewertet werden k nnen Einige Werkzeuge zur Analyse von Software existieren bereits die vom Betreuer benutzt werden k nnen um eine solche Analyse dur
211. on Wesley 2001 Schm01 D Schmedding Ein Prozessmodell fiir das Software Praktikum In H Lichter M Glinz Hsg SEUH 2001 Software Engineering im Unterricht der Hochschulen S 87 97 Ziirich 2001 dpunkt verlag WiUp01 L Williams R Upchurch Extreme Programming for Software Engineering Education In 31 ASEE IEEE Frontiers in Education Conference Reno NV 2001 Softwaretechnologie Praktikum im Grundstudium universitares oder reales Projekt Birgit Demuth Lothar Schmitz Barbara Wittek Fakult t Informatik Institut f r Software und Multimediatechnik Technische Universit t Dresden 01069 Dresden Birgit Demuth Barbara Wittek inf tu dresden de Fakult t Informatik Institut f r Softwaretechnologie Universit t der Bundeswehr M nchen 85577 Neubiberg lothar informatik unibw muenchen de Zusammenfassung Ein gemeinsam entwickeltes Softwaretechnologie Praktikum ist an der Fakult t Informatik der TU Dresden und an der Fakult t Informatik der UniBw M nchen obligatorischer Bestandteil im Grundstudium Das Praktikum wird an beiden Hochschulen in gleicher Weise als internes Praktikum im universit ren Rah men durchgef hrt Seit einigen Jahren erh lt an der TU Dresden ein Teil der Studenten die M glichkeit unter vergleichbaren Rahmenbedingungen ein reales Projekt als externes Praktikum in regionalen Firmen oder wissenschaftlichen Institutionen durchzuf hren ber die Erfahrungen die mit de
212. on vernachl ssigen zu k nnen was sich oft als Fehleinsch tzung herausstellt Schlechte Abstimmung von Vorlesung und Praktikum Die das Prakti kum begleitende Vorlesung ist in den allgemeinen Vorlesungsplan des Se mesters eingebunden Dieser favorisiert eine lineare Vermittlung von Stoff die aber nicht dem Bedarf in einem Praktikum entspricht Themen wie Ent wurf und Gruppenarbeit m ssen vermehrt am Anfang des Praktikums vermit telt werden w hrend in sp teren Phasen nur noch eine praktische und indivi duelle Betreuung n tig ist Mangelnde Vergleichbarkeit Die Aufgabenstellungen der Kunden unter schieden sich in Schwierigkeit Zeitaufwand und didaktischer Eignung be tr chtlich DHZS99 Als Folge war die von den Teilnehmern geforderte Leistung kaum objektiv zu vergleichen oder zu bewerten Schwierige Betreuung Die Aufgaben der Kunden erforderten tendenziell bereichsspezifische Architekturen und Algorithmen Netzwerke Computer grafik Numerik Information Retrieval die die betreuenden Mitarbeiter und Studenten sich erst spontan aneignen mussten Schlechte Skalierbarkeit Die Anzahl der Teilnehmer von Praktikum zu Praktikum schwankte stark und war oft erst kurzfristig bekannt Eine ent sprechende Anzahl von Kunden und damit Aufgabenstellungen zu finden war damit ein wiederkehrendes Problem Eine gro e Anzahl verschiedener Aufgabenstellungen versch rft die Probleme der Betreuung und Vergleich barkeit Aus diesen Erfahrun
213. onsten zum Teil erhebliche Anfangsfrustration Zitat eines Studierenden Teamarbeit das ist wie wenn sich zehn Leute in einen VW K fer quetschen um gemeinsam einzuparken erheblich weil sie nun wissen dass diese unproduktive An fangsphase die sie alle durchlaufen normal notwendig und vor bergehend ist Auch halten wir es f r notwendig Teamarbeit explizit zu motivieren und gezielt die Vorteile der Teamarbeit herauszustellen damit sie nicht in den Alltagsproblemen unter gehen Als Argumente f r Teamarbeit nennen wir dabei vor allem die letztendlich h here quantitative Leistung des Teams im Vergleich zu der einer einzelnen Person in Abbildung 3 ist das ab t und die h here Qualit t die sich daraus ergibt dass mehr 32 Andreas Fleischmann Katharina Spies Katharina Neumeyer Leute mehr Ideen haben aber auch dass man sich gegenseitig inspiriert Fehler in der Arbeit der anderen entdeckt usw 3 3 Ein Team formen Teambuilding Ein Lernziel des Teamtrainings ist es aus den Studierenden die sich noch nicht kennen ein Team zu formen Der Schwerpunkt des Workshops liegt dabei nicht im expliziten Teambuilding z B Theorie vielf ltige Kennenlern bungen Vertrauens bungen usw wir vertrauten stattdessen darauf dass sich die Teammitglieder durch die gemeinsame Arbeit im Workshop insbesondere im Miniprojekt Abschnitt 3 6 automatisch besser kennen und einsch tzen lernen Das explizite Teambuilding beschr nkte s
214. oordination dient der Abstimmung bei gemeinsamen Aufgaben Die Kooperation schlie lich fordert zus tzlich die Verfolgung gemeinsamer Ziele Aus der oben beschriebenen Situation heraus lassen sich in den Praktika an der FernUniversit t in all diesen Bereichen Probleme ausmachen Kommunikation Studierende der FernUniversit t benutzen in der Regel elektroni sche Hilfsmittel um miteinander zu kommunizieren also z B E Mail Instant Messaging Chat oder auch das Telefon Da sie aber oftmals unterschiedliche Arbeitszeiten und Arbeitsweisen haben ist der berwiegende Anteil der Kom munikation asynchron Eine direkte R ckmeldung auf eine evtl dringende Frage ist somit meistens nicht m glich Koordination Aus der r umlichen Distanz der Studierenden ergibt sich automa tisch ein hoher Koordinationsbedarf um die einzelnen T tigkeiten untereinander abzustimmen und eine Zusammenarbeit zu erm glichen Abstimmungsprozesse werden oft durch Kommunikation oder durch gemeinsame Artefakte z B gemeinsamer Projektplan unterst tzt Kollaboration Da die Studierenden sich nicht in einem Computerraum treffen k n nen um miteinander zu arbeiten m ssen sie stattdessen wieder auf elektronische Hilfsmittel zur ckgreifen Meist werden die Studierenden dann auch wieder zu unterschiedlichen Zeiten an dem Projekt arbeiten weshalb es wichtig ist dass jeder Einzelne wei was sich seit dem letzten Zugriff am Projekt ver ndert hat Au erdem muss klar
215. oterwettrennens Softwaretechnik live im Praktikum zur Projekterfahrung 51 5 1 Meilensteine Zu Beginn des Praktikums werden Meilensteine definiert zu denen bestimmte Zwi schenprodukte erstellt und vorgelegt werden m ssen Durch diese Zwischenziele wird nicht nur die Projektkontrolle unterst tzt sondern die Studierenden k nnen auch Teiler folge in ihrer Arbeit erleben die eine Basis f r die Weiterarbeit darstellen und eine mo tivierende Wirkung besitzen Je h rter ein Team f r die Erreichung eines Meilensteins gearbeitet hat desto gr er ist die Motivation das Projekt fortzuf hren Gleichzeitig wird dabei der Teamgeist gest rkt da Meilensteine meist nur durch erfolgreiche Team arbeit erreicht werden k nnen In der neunten Praktikumswoche findet eine Prototyppr sentation statt Die Studie renden pr sentieren dabei den gegenw rtigen Entwicklungsstand ihrer Steuerung Dem Kunden wird somit die M glichkeit gegeben den Fortschritt der Teams zu ermitteln und eventuelle Abweichungen zu den Anforderungen zu erkennen F r die Teams stellt diese Prototyppr sentation eine wichtige R ckmeldung ber den eigenen Stand im di rekten Vergleich mit der Konkurrenz dar Dies hat schon bei einigen Teams zu unge ahnten Motivationssch ben gef hrt 5 2 Rollenspiel und Teamarbeit Das Rollenspiel kommt beim Fachpraktikum in unterschiedlicher Weise zum Einsatz Zum einen tritt der Praktikumsorganisator den Studierenden als Auft
216. otz ihrer Vielseitigkeit nicht zu gro e Aufgabenstellung gefunden zu haben Ein Wettbewerb am Ende des Praktikums steigert das Teamgef hl und stachelt die Studierenden zu Spitzenleistungen an 6 Betreuung Am Praktikum nahmen 117 Studierende teil die zuf llig in 22 Gruppen zu 5 Studierenden aufgeteilt wurden M04 Jeweils drei dieser Gruppen waren einem stu dentischen Tutor zugeordnet der das Software Praktikum bereits erfolgreich absolviert hatte und Hilfestellung geben konnte Aufgabe eines Tutors war es die Erfolgschancen der Gruppe zu maximieren dabei aber selbst nicht mitzuarbeiten etwa wie ein Trainer im Sport Entsprechend dieser Rolle waren Tutoren auch nicht mit der Bewertung von Leistungen befasst Der typische Tagesablauf eines Studierenden sah in der zwei Wochen dauernden Entwurfsphase so aus 09 00 11 00 Uhr Vorlesung 11 00 12 30 Uhr Erstes Treffen mit Tutor alle drei Gruppen gemeinsam 13 00 17 30 Uhr Arbeit in der Gruppe 17 30 18 00 Uhr Zweites Treffen mit Tutor jede Gruppe einzeln In den Vormittags Treffen wurden die Ziele f r den Tag festgesetzt meist aufgrund des gerade behandelten Stoffs der Vorlesung In den Nachmittags Treffen wurden die Er gebnisse besprochen und zwar f r jede Gruppe einzeln Die lange Pause zwischen den Treffen bewirkt dass alle Gruppenmitglieder pr sent sind und sich tats chlich voll und ganz der Gruppenarbeit widmen k nnen Da alle Gruppen vor den gleichen Entwu
217. passt werden kann Die Anforderungen auf dieses Ziel hin zuzuschneiden war eine Aufgabe des internen Kunden Externe Kunden sind nicht st ndig verf gbar Um die Kommunikationswege kurz zu halten und die externen Kunden nicht zu sehr zu beanspruchen dien te der interne Kunde als Ansprechpartner f r die Studenten e Als Risiko haben wir gesehen dass ein externer Kunde abspringt Durch den internen Kunden h ngt das Studienprojekt jedoch nicht existenziell vom ex ternen Kunden ab Zus tzlich standen den Teilnehmern zwei Mitarbeiter als Betreuer zur Seite Die Teil nehmer stellten den Projektleiter zus tzlich geforderte Rollen waren ein Configuration Management und Qualit tssicherungs Beauftragter und ein Chefarchitekt 3 4 Anforderungen an den Ablauf des Projekts Das Projekts gliederte sich in die folgenden von den Mitarbeitern vorgegebenen Pha sen Im Vorprojekt arbeiteten die Teilnehmer in drei Gruppen Jede Gruppe f hrte An forderungsanalyse Entwurfs berlegungen Kostensch tzung und Planung durch und Projekte der Lehre mit hochschulexternen Kunden 141 erstellte ein Angebot Zur Analyse fanden Gespr che mit dem internen und den exter nen Kunden statt Abschluss der Vorprojektphase war die Angebotspr sentation in der jede Gruppe den Kunden ihr Angebot vorstellte Die Kunden einigten sich auf eine Gruppe die den Zuschlag erhielt Gefordert worden war die Projektabwicklung in zwei Iterationen Abschluss der ers ten
218. plausibles Verhalten zeigen So ein Modell ist schwer zu validieren und die Modell entwicklung ist selbst eine spannende Forschungsaufgabe Rodriguez et al beziehen sich auf einen anderen Simulationsansatz aber mit hnlicher Absicht Rod 04 Im Hinblick auf die Erfahrungsvermittlung versucht SESAM in einem simulierten und absolut nicht realen Umfeld authentische Erfahrungen zu vermitteln In erster N herung soll es ja keine Rolle spielen dass die Reize aus dem Projekt nur durch den Computer vermittelt werden Der Projektleiter soll beobachten wie sich seine Hand lungen und die Eigendynamik des simulierten Projekts auswirken Vers umt er zum Beispiel ein Review anzuberaumen so hat er sp ter kaum eine M glichkeit die Quali t t des Entwurfs zu beurteilen Dies ist so unerfreulich wie in einem entsprechenden realen Projekt Auch die Gef hlsantwort kann daher hnlich und vergleichbar intensiv Vier Formen der Erfahrungsvermittlung im Studium 19 sein Wird nun noch die gleiche Schlussfolgerung gezogen dann ist Erfahrung in allen drei Aspekten vom Modellentwickler an den spielenden Projektleiter vermittelt worden Wir haben bei den ersten Eins tzen von SESAM am Rande bemerkt dass die com puterbasierte Simulation nicht unbedingt die authentischsten Gefiihle hervorrief Solan ge der Simulator noch nicht zur Verfiigung stand hatten wir das Modell schon mit Excel Unterst tzung manuell benutzt Dei 94 Die von Hand errechneten
219. ppen berwiegend allein gearbeitet haben Der gro e Anteil der Arbeit im gesamten Team insbesondere am Anfang des Projekts in der ersten und auch noch in der zweiten Woche ist bei der XP Gruppe auf die Diskussion der Aufgabenstellung die Planung der Iterationen und 118 Doris Schmedding und Ingrid Beckmann die angeleitete Einarbeitung in die XP Konzepte zur ckzuf hren Diese Diskussionen ber die Aufgabenstellung und die Projektsitzungen zur Organisation der Arbeit finden sich auch in den anderen Gruppen die etwa ein Viertel ihrer Arbeitszeit im ganzen Team gearbeitet haben Auch die UML Gruppen haben mehr als 10 Prozent ihrer Zeit zu zweit gearbeitet 3 2 Kommunikation und Teamklima Die XP Vorgehensweise ist darauf ausgerichtet dass durch eine angenehme Arbeitsatmosph re die gute Zusammenarbeit im Team und damit auch die Qualit t des erstellten Produkts gef rdert werden Die Kommunikation unter den EntwicklerInnen wird als besonders wichtig f r den Erfolg eines Projekts angesehen In einer Lehrveranstaltung besteht der Reiz einer Vorgehensweise die sich die Verbesserung des Teamklimas zum Ziel setzt darin durch ein gutes Teamklima auch ein gutes Lernklima zu erreichen Projektbeginn Projektende N 6 6 7 7 6 6 7 7 XP Gruppe 2 Gruppe 3 Gruppe 4 Gruppe Abb 2 Teamklima in den Gruppen links bei Projektbeginn rechts bei Projektende In unserem Sopra Experiment wurden zur Messung des Teamklimas Ausz ge aus einem sta
220. pt zur Vorlesung Softwaretechnik I http www ias uni stuttgart de st1 IAS Uni versit t Stuttgart 2004 G nt99 H G nther Studienarbeit Portierung der zur Steuerung von Fahrrobotern entwickelten Software Umgebung auf Windows NT Institut f r Automatisierungs und Softwaretechnik Universit t Stuttgart 1999 Hump97 W S Humphrey Introduction to the Personal Software Process Addison Wesley Longman Inc Reading 1997 Land93 M Landfarth Diplomarbeit Entwurf und Aufbau eines ferngesteuerten Roboters M nchen Lehr stuhl f r Prozessrechner Technische Universit t M nchen 1993 LaG699 R Lauber P G hner Prozessautomatisierung 2 1 Auflage Springer Verlag Berlin Heidelberg New York 1999 Spat93 O Spatz Diplomarbeit Funktionserweiterung des Roboters f r das Software Engineering Praktikum M nchen Lehrstuhl f r Prozessrechner Technische Universit t M nchen 1993 Voos03 J Voosen Schlechte Noten f r die Praxis Hochschulanzeiger Nr 68 Frankfurt 2003 Vom Code zu den Anforderungen und wieder zur ck Software Engineering in sechs Semesterwochenstunden Barbara Paech 1 Lars Borner 1 J rgen R ckert 1 Allen H Dutoit 2 Timo Wolf 2 1 Universit t Heidelberg Fakult t f r Mathematik und Informatik AG Software Engineering Im Neuenheimer Feld 326 69120 Heidelberg paech lars borner juergen rueckert informatik uni heidelberg de 2 Technische Universitat M nchen Fakult t f r Info
221. r sentationen aufgrund der Vielzahl der Gruppen nicht m glich sodass Probleme oft tats chlich erst gegen Projektende sichtbar werden 5 Was haben wir gelernt Neben den oben beschriebenen konkreten Beobachtungen und Erfahrungen aus unse rem Praktikum ergibt sich f r uns eine Reihe von Lehren die sich vermutlich auch gewinnbringend auf hnliche Veranstaltungen andernorts bertragen lie en Die Betreuung durch studentische Tutoren hat sich als sehr effektiv erwiesen Dies setzt eine sorgf ltige Auswahl der Tutoren sowie deren intensive Betreuung durch den Lehrstuhl voraus Des Weiteren ist der w chentliche Gedanken und Erfahrungs austausch der Tutoren untereinander ein wirksames Instrument bei der qualitativen Absicherung in der Ausbildung Eine das Praktikum im Sommersemester 2004 beglei tende psychologische Studie iko 04 konnte die Vorbildwirkung des studentischen Tutors klar herausarbeiten Tutoren die motivieren intellektuell anregen und St rke ausstrahlen k nnen allerdings nur dann positiven Einfluss auf das Team und dessen Projektergebnisse nehmen wenn sich die Teammitglieder auch engagieren Ein weiterer wesentlicher Faktor f r den Erfolg des Praktikums ist die Motivation der Studenten Hier ist das externe Praktikum klar im Vorteil da die Identifikation mit einem realen Projekt leichter f llt als mit einem bungsbeispiel und das Ziel der Arbeit deutlicher wird Daher ist es notwendig im internen Praktikum den pers nli
222. r Eclipse auf ihre Verwendbarkeit in Software projekten der Fernlehre hin untersucht F r die einzelnen Phasen des Projekts werden unterschiedliche Werkzeuge angeboten die wir im Folgenden vorstellen Phase 1 Erstellen des Projekts Wenn ein Projekt erstellt wird muss der Betreuer in der Lage sein eine Projektbe schreibung zu erstellen und die Meilensteine anzugeben zu denen bestimmte Teile des Projekts fertig gestellt sein m ssen Eine allgemeine Beschreibung des Projekts kann in einem Raum f r das Projekt in CURE hinterlegt werden F r eine detaillierte Planung k nnen die Task Tracker von CodeBeamer verwendet werden wobei jeder Task einen Abschlusstermin haben kann Es w re w nschenswert wenn diese Abschlusstermine automatisch in einen Teamkalender eingetragen werden k nnten der von jedem einzel nen Teammitglied zu jeder Zeit eingesehen werden kann Au erdem k nnte jeder im Team diesen Teamkalender noch um eigene teaminterne Termine erweitern Leider haben wir kein Plug in gefunden das einen solchen Kalender implementieren w rde Die optimale L sung bliebe an dieser Stelle wohl eine Integration von Eclipse mit MS Outlook oder IBM Lotus Notes da dies die Anwendungen sind mit denen die meisten Leute ihre Termine synchronisieren Aktuelle Open Source Projektmanagement Werk zeuge bieten ihre eigenen Kalender an die jedoch nicht mit anderen Kalendern 7 Urspr nglich hatten wir vor GForge als eine kostenlose Alternative zu
223. r Gestaltung der Anzeigetafel h ngt der gesch ftliche Erfolg eines B rsencafes und damit prinzipiell die Brauchbarkeit der Software ab Teams welche aus Zeitgr nden die Preisanzeige weggelassen hatten konnten dann erleben wie ihr Kunde entr stet feststellte dass das Arbeitsergebnis f r ihn wertlos sei Durch dieses Auflaufenlassen und anschlie ende R ckmeldung durch den Kunden d h den Praktikumsleiter hatten die Teilnehmer ein deutliches Aha Erlebnis und es gab viel spontanes Lob am Ende dieser Praktikumseinheit Was in der konkreten Projektsituation wichtig oder unwichtig ist ist immer anders Die gelernte Lektion ist jedoch dass das Problem ohne besondere Aufforderung immer aus Kundensicht betrachtet und f r den Kunden zufriedenstellend gel st werden muss Gro e Software und Reengineering Die Praxisn he fortgeschrittener Praktika kann durch Aufgaben gesteigert werden die den berblick eines gro en Systems erfor dern Hierzu sollte der gesamte Softwareentwicklungsprozess bereits erlernt und er probt sein Bew hrte M glichkeiten sind ein Reengineering Projekt Bothe2001 oder ein gro es immer weitergef hrtes Projekt Raasch1997 In allen Praktika kann mit Reengineering konfrontiert werden indem undokumentierte Codeteile der L sung vorgegeben werden SoPra Harte Termine Harte Termine sind in jedem Praktikum leicht implementierbar indem Termine f r die Abgabe von Zwischen und Endprodukten gesetzt werden Der
224. r Studierenden auf das Berufsleben bei Dieser Beitrag beschreibt das Konzept des Fachpraktikums Softwaretechnik und be richtet ber die Erfahrungen die w hrend der vergangenen 9 Jahre am IAS gewonnen wurden 2 Praktikumsdurchf hrung in Projektform Die Lehrveranstaltungsform Fachpraktikum wird f r Studierende des Hauptstudiums der Diplomstudieng nge Elektro und Informationstechnik sowie Automatisierungs technik in der Produktion und des internationalen Masterstudiengangs Information Technology INFOTECH angeboten Fachpraktika verfolgen das Ziel die in Vorlesun gen erworbenen Fachkenntnisse der Teilnehmer zu vertiefen und anzuwenden bli cherweise wird in Fachpraktika eine Reihe an Versuchen von Studierenden absolviert die an vorbestimmten Terminen durchgef hrt werden Im Gegensatz hierzu steht das Fachpraktikum Softwaretechnik Es wird in Form ei nes industriellen Softwareprojekts durchgef hrt Dabei wird das Projekt nicht von je dem Studierenden einzeln sondern in einem von drei studentischen Teams mit jeweils sechs bis acht Teammitgliedern durchgef hrt Ein Team stellt dabei eine kleine Firma dar die als Auftragnehmer eines Kunden t tig ist und f r diesen ein Softwaresystem termingerecht zu realisieren hat Jedes Team wird von einem wissenschaftlichen Mitar Softwaretechnik live im Praktikum zur Projekterfahrung 43 beiter betreut Der Teambetreuer nimmt dabei nicht nur die Rolle eines Tutors ein er ist auch glei
225. r aktiven KundInnen bernehmen die immer anwesend oder zumindest schnell erreichbar sein sollen falls es keine echten Kunden gibt Literatur AuMi01 K Auer R Miller Extreme Programming Applied Playing to Win Addison Wesley 2001 Beck00 K Beck Extreme Programming explained Embrace Chance Addison Wesley 2000 Bckm04 I Beckmann Erkennen von Code M ngeln zum Refaktorisieren Diplomarbeit am Fachbereich Informatik der Universit t Dortmund 2004 BRJ99 G Booch J Rumbaugh I Jacobson The Unified Modeling Language User Guide Addison Wesley 1999 Fow100 M Fowler Refactoring oder Wie Sie das Design vorhandener Software verbessern Addison Wesley 2000 KSS04 C Kopka D Schmedding J Schr der Der Unified Process im Grundstudium Didaktische Konzeption Einsatz von Lernmodulen und Erfahrungen In DELFI 2004 Die 2 Deutsche e Learning Fachtagung Informatik Paderborn LNI 2004 LRWZ01 M Lippert S Roock H Wolf H Z llighofen XP lehren und lernen in H Lichter M Glinz Editors Software Engineering im Unterricht der Hochschulen SEUH 7 Z rich 2001 dpunkt verlag MSK04 H M gge D Speicher G Kniesel Extreme Programming in der Informatik Lehre Ein Erfahrungsbericht In P Dadam M Reichert Hrsg Informatik 2004 Informatik verbindet Proceedings der 34 GI Jahrestagung Band 2 Ulm LNI 2004 NeMa01 J Newkirk R C Martin Extreme Programming in Practice Addis
226. r ange schlossen ist durchf hrt Auf dem Teachlet Rechner sind eine Pr sentationssoftware und mindestens eine Entwicklungsumgebung installiert Der Moderator erkl rt anhand der Entwicklungsumgebung das Ausgangssystem eventuell unterst tzt durch Folien Er erkl rt au erdem das Lernziel und erl utert die Aufgabenstellung Anschlie end fun giert er berwiegend passiv und setzt die Anweisungen um die ihm von den Teilneh mern der Teachlet Einheit zur L sung der Aufgabe gegeben werden Er kann jederzeit moderierend eingreifen wenn die Vorschl ge zu sehr vom gew nschten Lernziel weg f hren er sollte jedoch auf keinen Fall die L sung herunterprogrammieren bli cherweise hat ein Moderator eine Choreographie im Kopf nach der das Teachlet durchgef hrt wird Er sollte auch immer eine fertige L sung in der Hinterhand haben die er im Notfall pr sentieren kann 96 Axel Schmolitzky 2 3 Eine typische Choreographie Ublicherweise wird das Ausgangssystem zu Anfang in eine kleine Story eingebettet insbesondere dann wenn aus didaktischen Gr nden starke Vereinfachungen gegen ber einem realistischen System vorgenommen wurden Dann startet der Moderator die An wendung f hrt selbstst ndig eine m glichst kurze Demo durch und ermuntert dann die Teilnehmer dazu ihn per Zuruf zu weiterer oder wiederholender Erkundung der Funk tionalit t aufzufordern Auf diese Weise lernen die Teilnehmer bereits die Funktionali t t interakt
227. raggeber gegen ber Zum anderen sehen sich die Studierenden von Anfang an als Auftragnehmer und lernen als Team aufzutreten Diese Sicht wird dadurch unterst tzt dass die Studieren den innerhalb ihres Teams unterschiedliche Verantwortungsbereiche wahrnehmen und vertreten Um die Teamidentit t weiter herauszubilden w hlt jedes Team einen Namen und ein Logo Dadurch entsteht in den Teams ein Wir Gef hl und damit eine Ver antwortung des Einzelnen gegen ber seinem Team 5 3 Konkurrenz Ein Mittel das die Motivation der Studierenden w hrend der gesamten Praktikumsdau er nachhaltig f rdert ist die Wettbewerbssituation in der sich die unterschiedlichen Teams von Beginn an befinden Erfahrungsgem macht diese Situation den besonde ren Reiz des Fachpraktikums aus Die Studierenden werden dazu angehalten ihre Mit bewerber nicht als erbitterte Konkurrenten anzusehen Die Gruppen k nnen und sollen sich in technischen und organisatorischen Fragen helfen Dies f hrt zu einer regelm i gen Kommunikation unter den Teams und damit zu einem st ndigen Absch tzen des Entwicklungsstands der Mitbewerber Die eigenen Ergebnisse und der Projektfortschritt stehen immer in Relation zu denen der anderen Teams Ein weiterer Vorteil der Wett bewerbssituation ist dass die entwickelten Softwaresysteme ein hohes Niveau erreichen und damit zu spannenderen Roboterrennen f hren die wiederum j ngere Studierende ansprechen 52 Peter G hner Fri
228. rarchie sind sie F hrungskr fte wie in einer Firmenorganisation in der Mitarbeitern auf allen Ebenen viel Eigenverantwortung zugestanden wird Bewerbungsverfahren Vorstellungsgespr che eventuell vorab eine Beschreibung relevanter Qualifikationen in einer Bewerbungsmail bewirken das Gef hl Wir sind ausgew hlt und d rfen diesen Job tun Im SoPra wurde die Erfahrung gemacht dass gar nicht so sehr der Inhalt sondern die Form von Bewerbungsmails sehr viel ber die Motivation der Bewerber aussagt Um qualifizierte und motivierte Tutoren ausw hlen zu k nnen braucht es viele Bewerber Es wurde beobachtet dass die Anzahl der Be werber stark davon abh ngt wie gelungen das Praktikum das letzte Mal war Ein Methodenkatalog zum Erreichen von didaktischen Zielen in Software Engineering Praktika 9 Anerkennung als Studienleistung ECTS Punkte sind eine kostenfreie Form der Bezahlung Die SoPra Tutoren erhielten fiir ihre Leistung vier ECTS Punkte Dies ist wahrscheinlich auch ein wesentlicher Grund dafiir dass wir die Tutoren aus geniigend vielen Bewerbern aussuchen konnten Ein zus tzliches kleines Gehalt Dies hatte im SoPra den positiven Motivationsef fekt dass das Gef hl eines formalen Arbeitsverh ltnisses entstand 3 4 Didaktisches Ziel Erfolg im Umgang mit unterschiedlichen Vorkenntnissen Es gibt eine Reihe von Methoden mit unterschiedlichen Vorkenntnissen der Teilneh mer konstruktiv umzugehen Ma nahmen zum Ausgleich zu
229. rbs erreicht Die eingesetzten Roboter wurden am Lehrstuhl f r Realzeit Computersysteme der TU M nchen Prof F rber entwickelt Spat93 Land93 Die u eren Abmessungen des Roboters sind durch seine Sto stange gegeben siehe Abb 2 Die Sto stange ist beweglich gelagert und bet tigt beim Auffahren auf ein Hindernis einen oder mehrere taktile Sensoren durch die der Roboter eine Kollision mit einem Hindernis und die Po sition der Kollision erkennen kann 46 Peter G hner Friedemann Bitsch Hisham Mubarak Ziellinie Roboter Abb 2 Sicht auf Roboter von oben links und schematische Darstellung eines Parcours rechts Den Robotern werden Fahrbefehle ber Infrarot gesendet und sie informieren ber ihren aktuellen Roboterstatus z B fahrend stehend oder in Kollision Die Aufgabe der Steuerungssoftware ist nun mithilfe dieser Informationen den Roboter schnellst m glich durch einen Hindernisparcours zu lenken und diesen zu kartografieren um die Hindernispositionen bei einem sp teren Lauf ber cksichtigen zu k nnen Die erfassten Parcoursdaten die Roboterpositionen sowie der geplante Weg zum Ziel m ssen gra fisch auf dem Bildschirm ausgegeben werden Zur Steuerung der Fahrroboter steht den Studierenden eine Softwareumgebung G nt99 zur Verf gung welche eine Kommunikationsbibliothek f r den koordinierten Zugriff auf die Roboter enth lt Zum Kennenlernen des technischen Prozesses k nnen die Roboter mithilfe ein
230. rch sesam index htmi Bar 99 Bartsch Sp rl B Transfer of Experience Issues Beyond Tool Building Workshop on Learning Software Organizations Kaiserslautern Germany Bec 00 Beck K Extreme Programming Explained Addison Wesley Boe 03 Boehm B and R Turner Balancing Agility and Discipline A Guide for the Perplexed Addson Wesley Con 00 Conradi R and T Dingsoyr Software Experience Bases A Consolidated Evaluation and Status Report Profes Oulu Finland Vier Formen der Erfahrungsvermittlung im Studium 25 Dei 94 Deininger M and K Schneider Teaching Software Project Management by Simulation Experiences with a Comprehensive Model Conference on Software Engineering Educa tion CSEE Austin Texas Din 00 Dingsoyr T An Evaluation of Research on Experience Factory Workshop on Learning Software Organizations Oulu Finland Dra 95 Drappa A M Deininger et al Forschungsprojekt SESAM Informatik Forschung und Entwicklung 10 1995 1 49 50 Joh 99 Johannson C P Hall et al Talk to Paula and Peter They are Experienced Interna tional Conference on Software Engineering and Knowledge Engineering SEKE 99 Workshop on Learning Software Organizations Kaiserslautern Germany Springer Lan 99 Landes D K Schneider et al Organizational Learning and Experience Documentation in Industrial Software Projects International Journal on Human Computer Studies IJHCS 51 Organization
231. rde die Geometrie des Spielfeldes von vier auf sechseckige Zellen ge n dert ein Zustand im Automaten verboten und verschiedene Wertebereiche ver ndert Die Korrektheit jedes Simulators wird durch einen Vergleich mit einer Referenzimplementierung gepr ft Jeder Simulator erzeugt Log Dateien die den vollst ndigen Zustand der simulierten Welt nach jedem Simulationszyklus enthalten Die Log Dateien der Referenzimplementierung stehen den Studierenden w hrend der Entwicklung zur Fehlersuche zur Verf gung Eine lange Simulation von zahlreichen Bugs in einer kleinen Welt kann auch unwahrscheinliche Situationen provozieren die so zu einer guten Abdeckung f hren und m gliche Fehler aufdecken Eine solch vielseitige Aufgabenstellung ist zu schade um sie nur f r ein Praktikum einzusetzen Tats chlich ist die Aufgabe eine isomorphe Kopie der Aufgabe des ICFP Programming Contest ICFP04 Dort hatten internationale Gruppen 72 Stunden Zeit einen m glichst leistungsf higen Schwarm zu entwickeln der gegen die Schw rme anderer Gruppen antreten soll W hrend der Schwerpunkt des Praktikums auf der Imp lementierung des Simulators liegt lag er im Wettbewerb auf der Entwicklung einer 76 Christian Lindig und Andreas Zeller Hochsprache um leistungsf hige Strategien ausdr cken zu k nnen Die Tatsache dass es im Contest 230 Gruppen schafften innerhalb von 72 Stunden einen Simulator und einen Schwarm zu implementieren gab uns die Sicherheit eine tr
232. rden F r die Teilnehmer am externen Praktikum erweist sich die M glichkeit Erfahrungen auf dem Gebiet der Software entwicklung an einem realen Projekt unter kontrollierten Bedingungen zu sammeln als 132 Birgit Demuth Lothar Schmitz Barbara Wittek besonders positiv Da die Studenten hier st rker selbstverantwortlich bez glich Zeitein teilung Einarbeitung in neue Technologien und Arbeitsteilung handeln und sich zudem einem realen Kunden gegen ber behaupten m ssen wird das Bewusstsein f r die dabei entstehenden Probleme gesch rft Die Teams im internen Praktikum ben tigen aufgrund ihrer meist leistungsm ig heterogenen Zusammensetzung st ndige Kontrolle und erh hte Aufmerksamkeit um die gleichm ige Beteiligung aller Studenten am Praktikum zu gew hrleisten Hier muss von erh hten Betreuungsanforderungen ausgegangen werden denen durch das Anbieten verschiedener Anlaufstellen bei Problemen Forum Tutor Lehrstuhl und umfangreicher organisatorischer und technischer Hilfestellungen Rechnung zu tragen ist Durch die st ndige Kontrolle der Teams und die intensive Anleitung im internen Praktikum lassen sich positive Auswirkungen auf den Lernerfolg erzielen Die Studen ten k nnen hier die Softwareentwicklung an einem bungsbeispiel gefahrlos auspro bieren und finden dabei jederzeit Unterst tzung in allen Bereichen ohne dass z B Fehlentscheidungen negative Konsequenzen f r das gesamte Projekt bedeuten Wenn diese Chance
233. re process measurement is an essential skill to be taught to future software engineers It is not adopted through classroom teaching unless the students are required to try out the suggested methods in order to experience both the advantages and the pitfalls of process measurement The Personal Software Process PSP is a well known tool for this purpose In our university we have used PSP as a part of our graduate course for teaching process measurement Our experience and the feedback from our students suggest some changes both in the exercises and in the process itself 1 Introduction It is generally admitted that the basis of successful software process improvement is measurement Any changes in the software process must be preceded by measurements of the present process to give a basis for evaluating the effects of the change On the other hand measurements of the software process are not necessarily reliable or comparable unless the process itself is well defined and rigorously followed Students specializing in software engineering need practice in measurement Even though many of them have some experience in real world software development they have seldom observed process measurement in the industry and it is even rarer that such measurements would be carried out in a systematic way To point out both the usefulness of measurement and the problems in its rigorous implementation the curriculum of future software engineers should include
234. rende haben die Erfahrung gemacht dass die Realisie rung von Softwareeigenschaften die der Kunde nicht gefordert hat unn tig viel Zeit und Arbeit kosten kann wenn der Kunde diese Eigenschaften nicht toleriert Viele Stu dierende haben zudem auch die Erfahrung gewonnen dass Software nderungen die kurzfristig vor der Produktvorstellung durchgef hrt werden sodass ein ausreichender Test der Gesamt Software nicht mehr m glich ist meist zu einer Verschlechterung statt zu einer Verbesserung der Software f hren In den letzten Jahren ist der Trend zu beobachten dass die Softwareprodukte im Fachpraktikum immer besser werden Ein entscheidender Faktor daf r ist wohl dass in den letzten Jahren die Ingenieursausbildung in Informatik Grundkenntnissen im Elekt rotechnik und Informationstechnik Studium wesentlich verbessert wurde So lernen die Studierenden an der Universit t Stuttgart bereits im Vordiplomstudium objektorientierte Softwareentwicklung sowie entsprechende Modellierungsnotationen UML und Pro grammiersprachen Java sowie die Gestaltung von Benutzungsoberfl chen kennen 7 Fazit Das Fachpraktikum Softwaretechnik hat sich als fester Bestandteil im Lehrangebot des IAS etabliert Der Aufwand zur Durchf hrung des Fachpraktikums ist sowohl f r Stu dierende wie auch wissenschaftliche Mitarbeiter hoch Es ist jedoch ein Aufwand der sich f r alle Beteiligten lohnt Sie gewinnen durch das Praktikum sehr gute Erfahrungen hinsichtlich P
235. rfsproblemen standen stellten sich schnell Entwurfsmuster heraus die zun chst von einzelnen Tutoren an andere von ihnen be treute Gruppen weitergegeben wurden aber auch sp ter beim Treffen der Tutoren dis kutiert wurden und so ihren Weg in die Vorlesung und andere Gruppen fanden Tat s chlich wiesen alle Entw rfe hnliche Grundkonzepte auf In der Implementierungsphase trafen sich die Gruppen nur noch einmal t glich mit ihrem Tutor Zu diesem Zeitpunkt war das Gruppengef hl schon so weit gefestigt dass weitergehende disziplinarische Regeln nicht mehr notwendig waren Hier gaben die Tutoren Hilfestellungen zum Programmieren und zur Fehlersuche auch hier wurden auftretende Probleme weitergemeldet so dass sie schnell behoben werden konnten Ein Software Praktikum als Sommerkurs 77 In den zwei Wochen der Einsatzphase waren unsere Tutoren im Wesentlichen ar beitslos da die Gruppen an ihren Strategien arbeiteten und die Tutoren ihnen nicht mehr folgen konnten Stattdessen wurden die Tutoren zur Durchfiihrung des Turniers eingesetzt St ndige Pr senz vereinfacht die Teamarbeit und verringert Risiken 7 Pr fung Ein Software Praktikum ist eine Pr fungsleistung und soll deswegen so objektiv und fair wie m glich gepr ft werden Die Pr fung teilt sich in Teilpr fungen die zum Ab schluss jeder Phase stattfanden e In der Entwurfsphase beurteilte ein Pr fer den Entwurf in zwei Kolloquien mit Gruppe und Tutor Hierbe
236. richts Denn Software Engineering Unterricht muss ber reines Wissen hinaus auch fachspezifische Soft Skills trainieren Fachkommunikation Team Arbeit und Organisation und gemeinschaftliche Probleml sung Das Studium an der VFH unter scheidet sich vom klassischen Fernstudium vor allem dadurch dass die Studierenden ihren Mentor und die Lerngruppe kennen und online miteinander kommunizieren etwa im Chat in dem der Mentor oder die Mentorin mit der gesamten Lerngruppe bestimmte Themen aufgreift und vertieft Die Frage ist ob die eingeschr nkten Kommunikations m glichkeiten in einem virtuellen Lernraum ausreichen um die erforderlichen Soft Skills zu trainieren Da wir hier selbst skeptisch waren m chten wir ber unsere Erfahrungen mit dem Modul berichten 2 Asynchrone Kommunikation Voraussetzung f r echte Teamarbeit ist ein synchronisierter Lernfortschritt was gut durch bewertete terminierte Einsendeaufgaben zu erreichen ist Wir sind an dieser Stelle noch eine Schritt weiter gegangen indem wir anstelle der Einsendung die Ver ffent lichung im Forum des virtuellen Lernraums gefordert haben Bewertet wurde nur die fristgerechte Ver ffentlichung die Inhalte wurden zur Diskussion gestellt im Forum und im w chentlichen Chat Dabei lernten die Studierenden einerseits ihre guten Ideen BMBF Leitprojekt Virtuelle Fachhochschule hrtp www oncampus de 150 Ilse Schmiedecke und Debora Weber Wulff preiszugeben und von denen a
237. rieben wird vermutlich besser teilhaben k nnen als an einem reinen Frontalvortrag Hier m ssen noch weitere Versuche unternommen werden Teachlets die sich als zielf hrend erwiesen haben und einen ausreichenden Reifegrad erreicht haben sollten anderen Lehrenden zur Verf gung gestellt werden Denkbar ist eine koordinierte Sammlung von Teachlets zu unterschiedlichsten Lernzielen die ber einen dedizierten Webauftritt zug nglich gemacht wird ebenso wie eine Einbindung in beispielsweise MuSofT AIf03 einem deutschen Portal f r multimediales Lehrmaterial in Softwaretechnik Veranstaltungen Da Teachlets bisher ausschlie lich von der Person durchgef hrt wurden die sie aus gearbeitet hat muss au erdem untersucht werden wie Teachlets geeignet dokumentiert werden k nnen Ziel sollte sein dass eine ausreichend kompetente Person ein ihr unbe kanntes Teachlet mit minimalem Vorbereitungsaufwand durchf hren kann 6 2 Die Teachlet Werkstatt Bewertung In einer eigenen Veranstaltung wurde das Erstellen von Teachlets in den Mittelpunkt gestellt Die relativ starke Formalisierung des Teachlet Konzepts hat dabei den Studie renden die Arbeit erleichtert Die Erstellung eines guten Teachlets stellt eine hohe Motivation f r Studierende dar Sie erfordert Kreativit t f r die grundlegende Idee und handwerkliches K nnen f r die Entwicklung des Ausgangssystems Die Durchf hrung des Teachlets erfordert au er dem ein souver nes Umgehen mit
238. rmatik AG Angewandte Softwaretechnik BoltzmannstraBe 3 85748 Garching b M nchen dutoit wolft in tum de Zusammenfassung An der Universit t Heidelberg wurde die Veranstaltung Software Engineering im Bachelor Studiengang Angewandte Informatik erstmals mit einem gro en Anteil praktischer bungen durchgef hrt Die Herausforderung war in Vorle sung und bung eines Semesters mit 6 Semesterwochenstunden die Studieren den zu bef higen an einem Softwaresystem realistischer Gr e systematisch nderungen durchzuf hren Die innovative Kernidee unseres Vorgehens ist dass sich die Studierenden in der ersten H lfte durch Reverse Engineering in ein existierendes komplexes Softwaresystem einarbeiten und dieses dann in der zweiten H lfte mit einem systematischen Entwicklungsvorgehen erweitern In diesem Beitrag stellen wir unsere Vorgehensweise das bearbeitete Softwaresys tem und die verwendeten Werkzeuge sowie unsere Erfahrungen vor 1 Einf hrung Vor drei Jahren wurde an der Universit t Heidelberg der Bachelor Studiengang Ange wandte Informatik eingef hrt Die Lehrveranstaltung Software Engineering SWE ist eine Wahlpflichtveranstaltung mit 6 Semesterwochenstunden 9 ETCS Punkten ab dem 4 Semester Damit m glichst viele Studierende eine fundierte SWE Ausbildung erhalten sollen alle wesentlichen SWE Inhalte in dieser Veranstaltung praxisnah ver mittelt werden Die Voraussetzung zur Teilnahme an der Veranstaltun
239. rojekt und Teamarbeit Sie sammeln Erfahrungen wie durch die Ent wicklung eines Teamgeists das Arbeiten Freude bereitet und die Qualit t der Arbeit gef rdert wird Vielfach wurde die Erfahrung gemacht wie sehr gute Ideen und L sungsans tze in Diskussionen und durch die gegenseitige Erg nzung in der Teamarbeit entstehen Viele Studierende haben es nach der Durchf hrung des Praktikums nicht nur leichter gehabt Studien und Diplomarbeiten systematisch zu bearbeiten insbesondere hat ihnen das Praktikum den Einstieg in den Beruf vereinfacht Aus den gewonnenen Erfahrungen w re ein vermehrter Einsatz von Projektpraktika mit h herem Stellenwert im Studium sinnvoll Softwaretechnik live im Praktikum zur Projekterfahrung 55 Die Konzepte des Fachpraktikums wurden in den Fakult ten Elektrotechnik und In formatik der Universidade Federal do Amazonas Brasilien sehr positiv bewertet so dass die Konzepte und die Technik zurzeit dort eingef hrt werden In Zukunft wird sich der Ingenieursnachwuchs der Universit t Stuttgart auch mit brasilianischen Studieren den messen k nnen Literatur BrDr95 A P Br hl W Dr schel Hrsg Das V Modell Der Standard in der Softwareentwicklung mit Praxisleitfaden 2 Auflage R Oldenbourg Verlag M nchen Wien 2005 Gohn04a P G hner Skript zur Vorlesung Einf hrung in die Informatik II http Avww ias uni stuttgart de info3 LAS Universit t Stuttgart 2004 Gohn04b P G hner Skri
240. rs come from we have numerous examples of students who will accept any value computed by the Excel sheet no matter how unreasonable it may be Using Personal Software Process exercises to teach process measurement 113 Nevertheless we hope to improve the tool assistance offered for PSP by providing simple tools for collecting the measurements 6 Conclusion We feel that in spite of certain weaknesses PSP forms a useful basis for teaching the art and practice of process measurement to future software engineers While the students may find detailed and rigorous bookkeeping and analysis tedious they are also rewarded with an understanding of how effective even simple means of prediction are in software development With the improvements suggested above we expect the PSP exercises to be even more useful in improving the students awareness of the methods of process improvement References Abr02 P Abrahamsson K Kautz Personal Software Process classroom experiences from Finland In J Kontio R Conradi ed Software Quality ECSQ 2002 number 2349 in Lecture Notes in Computer Science pages 175 185 Springer June 2002 Bor02 J B rstler D Carrington G W Hislop S Lisack K Olson L Williams Teaching PSP challenges and lessons learned IEEE Software 19 5 42 48 2002 Fer97 P Ferguson W S Humphrey S Khajenoori S Macke A Matvya Results of applying the Personal Software Process Computer 30 5 24 31 1997
241. rungen an das zu entwickelnde System allgemeine Pr fanforderungen abgeleitet Danach werden Pr fmethoden und kriterien festgelegt mit denen die Pr fanforderungen zu erf llen sind Au erdem sind f r die einzelnen Komponenten und f r das Gesamtsystem Pr f f lle zu definieren Die Ergebnisse und Auswertungen der einzelnen Tests sind im Pr fprotokoll zu dokumentieren 50 Peter G hner Friedemann Bitsch Hisham Mubarak 4 5 Konfigurationsmanagement Im Bereich Konfigurationsmanagement lernen die Studierenden ein Produkt oder Zwi schenprodukt z B Dokument Quellcode Datei usw beziiglich seiner funktionellen wie auch u eren Merkmale eindeutig zu identifizieren Diese Identifikation dient der systematischen Kontrolle von nderungen und der Sicherstellung der Integrit t Das Konfigurationsmanagement berwacht die Konfigurationen w hrend der gesamten Entwicklung sodass die Zusammenh nge und Unterschiede zwischen fr heren Konfi gurationen und den aktuellen Konfigurationen jederzeit erkennbar sind Dadurch sind nderungen nachvollziehbar und berpr fbar LaG699 S 16 f Zudem muss ein Konzept bereitgestellt werden durch das die Bearbeitung von Zwischenprodukten in der Teamarbeit koordiniert wird 4 6 Zeitmanagement Die f r das Fachpraktikum zur Verf gung stehende Zeit ist insbesondere dadurch be grenzt dass die Studierenden das Praktikum in der Vorlesungszeit des Semesters durch f hren in der sie regul re Vorlesu
242. rwerb am effektivsten und effizientesten See 98 Der Dozent ist nicht mehr nur ausschlie lich Wissens vermittler Er hat zus tzlich die Rollen des Managers des Lernprozesses des Beraters im Lernprozess und des beispielgebenden Senior Engineers Lernteam Coaching ber nommen 3 Erfahrungen aus der ersten Durchf hrung F nf Projektgruppen haben sich vom SS2004 bis zum WS2004 05 im Multimedia Design Projekt gebildet In allen Projektgruppen wurden neben den Ingenieurstudenten Studenten auch aus Gestaltungsstudieng ngen aufgenommen Es wurden insgesamt f nf Entwicklungsprojekte durchgef hrt Aus zwei Projekten soll n her berichtet wer den Ein Projekt besch ftigte sich mit der Entwicklung eines Orientierungssystems f r die Hochschule Ein weiteres Projekt hatte die Aufgabe ein Werkzeug zur Verwaltung von Web Content der Hochschule zur Verf gung zu stellen Beide Systeme werden ab Fr hjahr 2005 an der Hochschule eingef hrt Wie erfolgreich ist dieses Lehrkonzept Die Standish Group Sta 01 gibt Erfolgsfaktoren f r IT Projekte an Die Lern Pro jekte sollen durch Abklopfen dieser Erfolgsfaktoren bewertet werden Es wird berich tet inwieweit die zehn genannten Erfolgsfaktoren in der Projektarbeit thematisiert und bewusst gemacht wurden 4 Literatur CG 04 I Cavalieri H Geupel Selbstgesteuertes Lernen eine das Lernen aktivierende Alternative zur Vorlesung Seminar N rnberg 9 10 Februar 2004 See 98
243. s bewertung 1 Kooperationsf higkeiten 2 Qualit t des Designs und der Implementie rung 3 Grad der bereinstimmung der fertigen Software mit den Designdokumenten und 4 ben tigte Zeit Um diese Kriterien aber vern nftig und gerecht bewerten zu 90 Philipp Bouillon Jens Krinke Stephan Lukosch k nnen muss die Nachvollziehbarkeit f r die Betreuer unbedingt gew hrleistet sein In klassischen Softwaretechnik Projekten bei denen einer Gruppe eine Aufgabe gestellt wird und die am Ende ein fertiges Produkt liefert ist es nahezu unm glich die Studie renden am Ende individuell zu bewerten Mit der hier vorgestellten Plattform wird das anders Der Betreuer ist in der Lage die ben tigten Daten ber die Kommunikations beteiligung aus der persistenten Kommunikation in CURE zu extrahieren Chat Proto kolle Mail Archive alle Versionen der Wiki Seiten Zus tzlich hat der Betreuer Ein sicht in alle Tracker von CodeBeamer und in das CVS Archiv Beispielsweise bietet CodeBeamer grafische Visualisierungen der Vorg nge im CVS Archiv Au erdem kann die Architektur des fertigen Systems mit Hilfe von Reverse Engineering Werk zeugen mit dem urspr nglichen Entwurf verglichen werden Ein Plug in das speziell f r diesen Zweck entworfen wurde ist JRefleX Won03 JRefleX kann sowohl eine Kollaborationsanalyse wie hat das Team zusammengearbeitet als auch eine Evolutionsanalyse wie hat sich das System ber die Zeit hin entwickelt durchf
244. s 10 Minuten dauern Auf einer Folie wird die Funktionalit t noch einmal zusammenfassend dargestellt 98 Axel Schmolitzky Im n chsten Schritt erfolgt die Code Inspektion Das System besteht aus drei Klas sen die ausf hrlich und interaktiv betrachtet werden Alle Teilnehmer sollten die inter ne Struktur der Anwendung verstanden haben Auch dieser Abschnitt sollte nicht l nger als 10 Minuten dauern 3 2 Aufgabe L sungsvorschlag Implementierung Nachdem alle die Ist Situation kennen kann die Aufgabe gestellt werden Es soll das noch fehlende Protokoll implementiert werden das die geklickten Operatoren jeweils mit ihrem Operanden auf Knopfdruck Protokoll anzeigen darstellt Au erdem sollen geklickte Rechenoperationen auch wieder zur ckgenommen werden k nnen Diese Aufgabenstellung wird auf einer eigenen Folie dargestellt Nachdem die Aufgabe vermittelt wurde schl gt der Moderator den Einsatz des Be fehlsmusters zur L sung vor Die Aufrufe an Objekte der Klasse Zwischenergebnis mit ihren Berechnungsoperationen sollen quasi objektifiziert werden Diese Befehls objekte k nnen dann gespeichert werden in lesbarer Form angezeigt und auch gel scht werden Der Moderator zeigt eine Folie mit dem allgemeinen Klassendiagramm des Befehlsmusters und bildet dieses dann gemeinsam mit den Teilnehmern auf einen kon kreten Entwurf an der Tafel ab F r diesen Abschnitt sollen 10 bis 15 Minuten einge plant werden Wenn sich alle Teilne
245. seits soll aber auch eine ausreichende Dokumentation vorhanden sein die eine Einarbeitung unter st tzt Letzteres machte insbesondere den Einsatz von Open Source Software nicht realistisch Aus fr heren Kooperationen hat die Universit t Heidelberg Zugriff auf das System Sysiphus das an der TU M nchen entwickelt wird Sysiphus unterst tzt die Durchf hrung von SWE Projekten Durch die Verwendung von Sysiphus k nnen die Studierenden die Methoden des SWE praktizieren und lernen gleichzeitig die Anwen dungsdom ne des zu bearbeitenden Systems kennen Das System ist auf Nachfrage erh ltlich Insbesondere wurde es f r die Lehrveranstaltung ausgew hlt weil e es f r den Einsatz in der Lehre entwickelt wurde und die gleichzeitige Bear beitung durch mehrere Teams unterst tzt e die Anwendungsdom ne n mlich das SWE f r die Studierenden wichtig ist wenn auch noch nicht vertraut e es mit 100 000 LOC in ber 1000 Klassen komplex ist e es ausreichend dokumentiert ist e es durch seine leicht verst ndliche Schichtenarchitektur gut erweiterbar ist e es ein Web Interface bietet e es in der objektorientierten Programmiersprache Java geschrieben ist JAVA und Web Interface erm glichen den Studierenden neuesten Technologien ken nen zu lernen Nachfolgend werden die Grundkonzepte beschrieben Das Werkzeug Sysiphus Sys 04 unterst tzt die Durchf hrung von Softwareprojek ten indem es die Erstellung von Modellen und Dokumenten mit
246. semblersprache formulieren die von den absoluten Adressen und dem expliziten Kontrollfluss der Maschi nensprache abstrahieren Kenntnisse der theoretischen Informatik k nnen zur Minimierung von Automaten verwandt werden Als Folge h ngt der Turnier erfolg wesentlich von der Qualit t der selbst entwickelten Werkzeuge ab Trotz ihrer weiterf hrenden Merkmale ist die unmittelbar zu l sende Aufgabe ber schaubar W hrend ein ausdifferenzierter Entwurf etwa 30 Klassen enth lt kann ein monbolithischer Entwurf mit 10 Klassen auskommen Abbildung 4 vergleicht die Gr e verschiedener Implementierungen Eine moderate Komplexit t garantiert allen Gruppen ein Erfolgserlebnis selbst wenn die softwaretechnischen Ziele nur ausreichend erreicht werden Die Aufgabenstellung spezifiziert die Syntax und Semantik der Sprache f r endliche Automaten und das Dateiformat der Umwelt Die Spezifikation ist eine Mischung aus informaler Beschreibung Grammatiken zur Definition der Syntax und Programmfrag menten in der funktionalen Sprache ML zur Spezifikation der operationalen Semantik des Simulators Implementierung Code Zeilen Module Methoden Referenz ML 1635 10 141 Referenz C 2223 32 134 22 L sungen C Durchschnitt 2432 24 22 L sungen C Minimum 1146 12 22 L sungen C Maximum 4629 45 Abb 4 Gr e von Implementierungen im Vergleich In der berarbeiteten Aufgabenstellung die die Studenten nach erfolgreichem Entwurf erhielten wu
247. sen und Methoden schlecht Auch der Ent wurf speziell der Zusammenhalt innerhalb der Klassen hatte oftmals M ngel sodass es m hsam war Anpassungen vorzunehmen oder Teile wiederzuverwenden Den Studen ten fehlte in diesen Bereichen offensichtlich noch die Erfahrung Dennoch konnte ein Gesamtsystem integriert werden das bei den Kunden zu Pr sentationszwecken eingesetzt wurde Produktqualit t im Sinne einer unmittelbaren Ver marktung hatten die Abgaben allerdings nicht 2 5 Einsch tzung des Praktikums durch die Studenten Im Anschluss an das Softwarepraktikum wurde eine empirische Untersuchung ber die Einsch tzung des Praktikums durch die Studenten durchgef hrt Dabei wurden die Stu denten in einem Fragebogen nach ihrer Einsch tzung verschiedener Aspekte des Soft warepraktikums befragt Der Fragebogen wurde anonym beantwortet sodass f r die Betreuer des Praktikums und den Auswerter der B gen kein R ckschluss auf die jewei ligen Studenten m glich war Der Fragebogen umfasste 14 teils offene teilweise ge schlossene Fragen Der R cklauf betrug 50 beantwortete B gen bei 57 Teilnehmern am Softwarepraktikum Die darin enthaltenen Antworten k nnen also als repr sentativ gel ten 138 Tilmann Hampp Stefan Opferkuch Rainer Schmidberger Der iiberwiegende Teil der Studenten gibt an dass ihnen das Softwarepraktikum insgesamt Spa gemacht hat Diese Aussage machten 43 der 50 Studierenden Des Weiteren bewerteten die Studenten
248. setzt wodurch die Arbeit des Programmkomitees erheblich erleichtert wurde Dank der Gro z gigkeit unseres Softwaretechnik Kollegen Volker Gruhn Uni versit t Jena konnten wir Paperdyne unentgeltlich benutzen Dank geb hrt ferner unse ren industriellen Sponsoren ohne deren Unterst tzung wir den Workshop nicht in ei nem so angenehmen Rahmen h tten durchf hren k nnen Es sind dies die ABB AG die BOSCH AG der dpunkt verlag und die sd amp m AG Frau Preisendanz vom dpunkt verlag danken wir sehr herzlich f r die gute Zusammenarbeit bei der Erstellung des Tagungsbands Dezember 2004 Klaus Peter L hr Horst Lichter FU Berlin RWTH Aachen Programmkomitee Lokale Organisation Das St ndige Organisationskomitee der SEUH besteht aus Jochen Ludewig Universit t Stuttgart G nter Riedewald Universit t Rostock Andreas Spillner Hochschule Bremen Inhalt Eingeladener Vortrag Ausbildung in empirischer Softwaretechnik unsusssesnsnnnnnnnannnnnnnnnn W F Tichy Univ Karlsruhe Didaktik und Training Methoden und Techniken zum Erreichen didaktischer Ziele in Software Engineering Praktika uruuur000nnnnannnnnnnnnnannnnnnnnnnnnnnnannnnnannn R Stoyan M Glinz Univ Z rich Vier Formen der Erfahrungsvermittlung im Studium csseeeeee K Schneider Univ Hannover Teamtraining f r Software Ingenieure uuusnsssnsnnnnnnnnnnnnnnnnnnnnnnnnnnnnnannn A Fleischmann K Spies TU M nchen K
249. sgesamt deutlich inneffizienter gemacht hat Hier wollen wir beim n chsten Teamtraining noch st rker die Vorteile einer strukturierten Teamsitzung deutlich machen und versuchen bereits im Teamtraining eine Routine zu entwickeln in der Hoffnung dass diese dann von den Studierenden quasi automatisch in die eigentliche Projektarbeit bernommen wird Teamtraining f r Software Ingenieure 39 F hrung Der studentische Projektleiter hatte Schwierigkeiten die mit seiner Rolle verbundene F hrungsaufgabe wahrzunehmen da er dies als unzumutbare Bevormundung seiner Mitstudierenden empfand Sein Laisser faire Stil konnte allerdings das Bed rfnis der Studierenden nach F hrung und Fokussierung nicht ausreichend befriedigen Hier wollen wir beim n chsten Teamtraining in der gesamten Gruppe transparenter machen was genau die F hrungsaufgaben eines studentischen Projektleiters sind und dass sich Basisdemokratie und F hrung nicht notwendigerweise widersprechen Zudem berlegen wir beim n chsten Praktikum der Gruppe die Wahl zu lassen ob sie eine Projektleitung m chten Reflektion Der Zeitdruck im Projekt war von Anfang an sehr hoch so dass sich das Team sehr schnell kaum mehr des Lernumfelds bewusst war vielmehr stand nur noch der erfolg reiche Abschluss des Projekts im Vordergrund Zeit f r Reflektion ber Vorgehen und Techniken des Software Engineering blieb kaum Zurzeit berlegen wir daher ob wir im n chsten Projekt vers
250. sleistung von 720 Entwicklerstunden zur Verf gung 2 2 Vorbereitungen Vor Beginn des Praktikums musste ein Partner gefunden werden der Bedarf f r ein Softwaresystem hat das innerhalb der Rahmenbedingungen des Softwarepraktikums realisiert werden kann Dieser Bedarf sollte einerseits so gro sein dass f r den Partner die Teilnahme am Praktikum interessant war andererseits sollte diese Software nat r lich in keiner Weise unternehmenskritisch sein da keinerlei Gew hrleistung f r die Qualit t der Ergebnisse bernommen werden konnte Zudem sollte keine spezielle Inf rastruktur wie z B spezielle Hardware oder eine spezielle Datenbank erforderlich sein Die Implementierung sollte in Java oder in Ada95 erfolgen weil die Studenten zuvor diese beiden Programmiersprachen gelernt hatten Bedingt durch die Laufzeit eines Praktikums und den Vorlauf den man bei der Partnersuche eingeplant hatte konnten 136 Tilmann Hampp Stefan Opferkuch Rainer Schmidberger keine kurzfristig verf gbaren Ergebnisse in Aussicht gestellt werden Die Zeitspanne zwischen Partnersuche und Ende des Praktikums betrug etwa neun Monate Nach vie len Gespr chen mit m glichen Partnern die alle sehr aufgeschlossen waren konnten die Weiterbildungsabteilung einer gro en deutschen Bank sowie eine Weiterbildungs Akademie als geeignete Partner mit einer passenden Aufgabenstellung gefunden wer den Beide Partner sind Weiterbildungseinrichtungen die die Zufriedenheit d
251. sleiter anstelle zu den Teilnehmern Wenn innere Ab lehnungen bekannt werden dann k nnen sie beantwortet werden Permanente Besch ftigung in der Pr senzzeit Wenn Teilnehmer w hrend l nge rer Zeit nicht selbst aktiv sind lenken sie ihre Aufmerksamkeit auf andere Dinge Moti vation und Lerneffekt sinken und sie werden potenzielle St renfriede 8 Robert Stoyan Martin Glinz 3 3 Didaktisches Ziel Motivation der Tutoren Den Tutoren die Augen ffnen was alles zu ihren Aufgaben geh rt und ihre Arbeit immer wieder pers nlich pr fen und wertsch tzen sind sicher das Wichtigste f r eine hohe Motivation Wie nachfolgend dargestellt kann dies bewirken dass Tutoren ihre Aufgabe als sehr n tzlich wahrnehmen und als ihren ersten professionellen Einsatz in einer F hrungsposition erleben Die Kontrolle ihrer Arbeit zeigt den Tutoren dass ihre Bem hungen wahrgenom men werden und der Praktikumsleitung nicht egal sind Sie sollte nur teilweise den Obertutoren berlassen werden Diese sollten m glichst bereits Erfahrung in der Lehre haben damit sie die Arbeit der Tutoren beurteilen k nnen Einfach pr sent zu sein und irgendetwas im bungsraum zu tun gibt dem Praktikumsleiter eine unauff llige M g lichkeit die Arbeit der Tutoren wahrzunehmen Das h ufigste Problem ist Passivit t in Situationen die nicht per se eine Aktion der Tutoren erfordern zum Beispiel bei Pro grammier bungen Wenn Passivit t akzeptiert wird so f hrt d
252. some practical exercise in process measurement One possible tool for teaching process measurement is the Personal Software Process PSP Hum95 advocated by CMU SEI By doing the set of programming exercises and the corresponding process measurements the students are expected to detect and address the most important problems in their personal process at the same time learning a systematic way of process improvement PSP is taught in courses 106 A Inkeri Verkamo Asko Saura offered by CMU SEI but the course textbook Hum95 describes the method in adequate detail that it can also be applied independently In the University of Helsinki we use PSP as a part of our graduate course for teaching process measurement Our experience and the feedback from our students suggest some changes both in the exercises and in the process itself In this report we describe the experience we have gained in using PSP based on two master s theses that analyzed the measurements and the self evaluations of the students Ros03 Sau04 2 Personal Software Process exercises The material provided in Hum95 is organized as ten programming exercises that are performed using the steps of PSP In each exercise the student collects measurements of his her own process such as lines of code defects detected and time spent in each phase The measurements are analyzed and used for predicting corresponding values in the subsequent exercises The number of measurements and
253. ster bietet unser Lehrstuhl keine Veranstaltungen an und kann sich f r sechs Monate der Forschung widmen Ein Praktikum in den Semesterferien konkurriert nicht mit anderen Veranstaltun gen erm glicht volles Engagement der Studierenden und verk rzt die Studienzeit 3 Risiken vermeiden Ein von 13 auf 6 Wochen reduziertes Software Praktikum muss sich auf den wesentli chen Stoff konzentrieren und l sst allen Beteiligten weniger Raum f r Fehler Anders als im semesterbegleitenden Praktikum k nnen Gruppen kaum Fristverl ngerungen gew hrt werden Eine homogene Struktur minimiert diese Risiken e Zuf llig zusammengestellte Gruppen Im Gegensatz zu fr heren Praktika wo die Studierenden selbst Gruppen bildeten haben wir die Gruppen zuf llig zusammengestellt Dies sorgt f r eine gleichm igere Verteilung der Leis tungen und gr ere Diversit t in den Gruppen Da sich die Gruppen anfangs nicht einsch tzen k nnen werden sorgf ltiger Entwurf und gute Teamarbeit als willkommene Mittel zur Risikominimierung empfunden e Wegfall der Anforderungsanalyse In einem 6 Wochen Praktikum fehlt die Zeit sich in fremde Anwendungsgebiete einzuarbeiten Daher haben wir auf Kunden und die Analyse ihrer Anforderungen im Pflichtteil verzichtet Ein Software Praktikum als Sommerkurs 71 Eine Aufgabenstellung Alle Gruppen bearbeiten eine identische Aufgaben stellung anhand eines Pflichtenheftes fiir das zuvor eine Referenzimplemen ti
254. stimation accuracy increased clearly during the course Figure 3 especially after the size estimation tool was introduced in exercise 4 After exercise 4 only exercise 6 shows major underestimation of effort possibly because it introduces the time consuming reviews to the process Many students heavily underestimated the size of exercise 10 which was considerably larger than all previous exercises Effort estimation errors N oO oO oO Do a O O Estimation error Exercise EN oO 20 Estimation error DS 3 Size estimation errors Exercise Figure 3 Estimation errors by exercise Using Personal Software Process exercises to teach process measurement 111 Hypothesis H4 expected productivity to stay roughly constant for the duration of the course but this proved false Figure 4 There is a noticeable drop in average productivity when PSP1 is introduced exercises 4 and 5 This may be due to the time consuming size prediction and paperwork The average productivity stays low except for the last exercise where as we previously noted students may not spend too much time searching for the last few defects Moreover the additional PSP1 process elements seem to slow down the most productive students more than the others Q3 in Figure 4 Productivity LoC h Exercise Figure 4 Productivity by exercise in LoC per hour In their fina
255. t e Sehr motivationssteigernd wirkte dass das entwickelte Produkt tats chlich ben tigt wurde und von den Teams auch pilotm ig eingesetzt werden musste 3 Ausblick Zusammenfassend ist ein positives Res mee dieses Praktikums zu ziehen Die hochgesteckten Erwartungen bei der Konzeption des Praktikums konnten erf llt werden Das Praktikum wird in dieser Form mit einigen Verbesserungen und Erweiterungen unter anderem ein expliziteres Risikomanagement und h here Anforderungen an die Dokumentation in Sommersemester 2005 erneut durchgef hrt werden Software Engineering Unterricht online lise Schmiedecke Debora Weber Wulff TFH Berlin Labor Online Learning Luxemburger Str 10 13353 Berlin schmiedecke tfh berlin de FHTW Berlin Internationale Medieninformatik Treskowallee 8 10318 Berlin weberwu fhtw berlin de 1 Ist Online Unterricht fur Software Engineering geeignet Der Bedarf an E Learning Modulen w chst st ndig So wurde auch im Rahmen des Bachelor Studienganges Medieninformatik an der Virtuellen Fachhochschule VFH ein Online Modul Software Engineering ben tigt F r das Online Lehrmaterial galten die bekannten Anforderungen an Semesterwochen orientierte Lerneinheiten Tests zur Selbstkontrolle und vor allem die Nutzung der Hyper und Multimediam glichkeiten und des Internets zur didaktisch optimalen Pr sentation des Lernstoffs G M 02 Die gr ere Herausforderung war die angemessene Gestaltung des Online Unter
256. t die im Praxisalltag zwar wichtig sind aber als unbequem empfunden und gerne verdr ngt werden Allerdings pl dieren wir daf r neben den fachlichen und technischen Inhalten verst rkt auch Soft Skills wie Teamwork und Projektmanagement als gleichberechtigt wichtige Lernziele innerhalb des Software Engineering wahrzunehmen oder wie Prof Ludewig etwas plakativer 40 Andreas Fleischmann Katharina Spies Katharina Neumeyer zum Thema Soft Skills sagte Es gibt keinen Gott der Informatik der das Gebot verk ndet h tte Du sollst nur Beweisbares lehren Lud 02 Wir empfehlen allen Lehrst hlen die solche Praktika oder Projekte durchf hren im Rahmen der Vermittlung f r Software Ingenieure wichtiger Soft Skills auch solch ein vorbereitendes Teamtraining in Betracht zu ziehen Wie das Beispiel der TU Darmstadt zeigt k nnen bei der Konzeption eines solchen Trainings Kooperationspartner von Psychologie Lehrst hlen oder Hochschuldidaktischen Stellen der Hochschule unterst t zend hinzugezogen werden damit kann auch der Aufwand bei der Schulung der Trainer und bei der Konzeption eines Teamtrainings eingeschr nkt werden Und auch wir selbst stehen gerne bei der Initiierung von Teamtrainings beratend zur Seite Literatur Aut 02 Homepage des Design und Simulationswerkzeuges AutoFocus M nchen 2004 http autofocus in tum de Aut 04 Homepage des AutoRAID Praktikums M nchen 2004 http wwwbroy in tum de autoraid
257. t abzu schneiden Die qualitative Bandbreite der universit ren Projekte ist durch die Vielzahl der Produkte allerdings sehr gro Quantitativ sind die Applikationen aus externem und internem Praktikum vom Funktionsumfang her hnlich und auch bez glich ausgew hl ter Metriken ergeben sich Gemeinsamkeiten Interessant ist dabei dass die durch schnittlichen Werte f r Lines of Code LOC und Anzahl der Klassen in hnlichen Gr enordnungen liegen externe Gruppen aber durchschnittlich einen geringeren Zeit aufwand f r ihre Arbeit angeben Das kann sowohl auf ein effektiveres Vorgehen als auch auf bessere Voraussetzungen z B bez glich Programmiererfahrungen hinweisen Bez glich technischer Voraussetzungen kann ber keine erheblichen Unterschiede zwischen externem und internem Praktikum berichtet werden Intern ist es den Studen ten freigestellt ob sie im Fakult tsrechenzentrum oder mit eigener Technik arbeiten Die Verwendung von Softwareentwicklungswerkzeugen wird zwar empfohlen und durch Bereitstellung von Lizenzen und Tutorials unterst tzt aber nicht vorgeschrieben Das externe Praktikum weicht nur dann von diesen Gegebenheiten ab wenn die jewei lige Firma den Teams eigene Arbeitspl tze zur Verf gung stellt oder die Verwendung bestimmter Werkzeuge explizit vorschreibt Die Integration der studentischen Projekte in die firmeninterne Infrastruktur kann dabei sowohl von Vorteil als auch von Nachteil sein Einerseits entfallen Entsche
258. t hat sich darauf einzulassen Hier gibt es also einen Merkpunkt f r den n chsten Workshop Ein wichtiges und immer noch junges Thema empirische und experimentelle Softwaretechnik war im Aufruf zur Einreichung nicht genannt worden Walter Tichy Universit t Karlsruhe hat sich dankenswerterweise bereit erkl rt im Rahmen eines eingeladenen Vortrags ber Ausbildung in empirischer Softwaretechnik zu berichten Wir hoffen dass der diesj hrige SEUH Workshop hnlich erfolgreich wie seine Vorg nger verlaufen wird und danken allen die durch ihre Einreichungen dazu beige tragen haben Den Mitgliedern des Programmkomitees geb hrt diesmal besonderer vi Vorwort Dank da sie wegen der zahlreichen Einreichungen mehr an Begutachtungsarbeit zu leisten hatten als urspriinglich vorgesehen e Ruth Breu Universit t Innsbruck e Harald Gall Universit t Z rich e Wolfgang Hesse Universit t Marburg e Horst Lichter RWTH Aachen e J rg Raasch Hochschule f r Angewandte Wissenschaften Hamburg e G nter Riedewald Universit t Rostock e Silke Seehusen Fachhochschule L beck e Johannes Siedersleben sd amp m AG und Fachhochschule Rosenheim e Debora Weber Wulff Fachhochschule f r Technik und Wirtschaft Berlin e Andreas Zeller Universit t Saarbr cken Um die Einreichungen zu verwalten den Begutachtungsprozess zu unterst tzen und das Tagungsprogramm zusammenzustellen wurde das Konferenz Verwaltungssystem Pa perdyne einge
259. teilt und es werden ihnen verschiedene Werkzeuge an die Hand gegeben die es ihnen erm glichen Teile des Gesamtsystems zu meistern An der FernUniversit t in Hagen werden s mtliche Softwaretechnik Kurse als Fern kurse angeboten sei es ber das Internet oder auf dem Postweg bei den Praktika in der Softwaretechnik kommt es aufgrund der Entfernung zu und zwischen den Studie renden aber zu besonderen Problemen die gel st werden m ssen Zurzeit m ssen die Studierenden die an einem Praktikum teilnehmen m chten die FernUniversit t besu chen und sich dann vor Ort zu einer Gruppe zusammenfinden Die ersten Phasen des Praktikums grobes Pflichtenheft und Grobentwurf werden vor Ort in Hagen durch gef hrt Danach reisen die Studierenden zu ihren jeweiligen Heimatorten zur ck von 82 Philipp Bouillon Jens Krinke Stephan Lukosch wo aus sie dann online tiber ein System namens CURE Collaborative Universal Remote Education Environment Haa04a Haa04b weiter an dem Design und der Implementierung des Projekts arbeiten CURE ist die kooperative Lernplattform der FernUniversitat Um die Zusammenarbeit einer Gruppe w hrend eines Praktikums zu erm glichen muss diese in den Bereichen Kommunikation Koordination und Kollaboration unter st tzt werden Diese Bereiche werden h ufig zur Klassifizierung von Groupware heran gezogen Teu95 Bei der Kommunikation steht der Informationsaustausch zwischen den Gruppenmitgliedern im Vordergrund Die K
260. terschiedlich organisiert haben Die Kommunikation untereinander und die Weitergabe von Wissen sind in den Paararbeitsteams sehr viel umfangreicher als bei Nicht Paararbeitsteams Erfahrungen mit XP 123 4 Fazit XP ist f r programmierunerfahrene EntwicklerInnen schwierig und verlangt viel Disziplin Es f llt Anf ngerInnen schwer zu entscheiden welche Stories sich sinnvoll zu einem funktionalen Kern f r eine Iteration zusammenfassen lassen Das Sch tzen der f r die Realisierung einer Story ben tigen Zeit ist f r unerfahrene EntwicklerInnen schwierig Ein leichtgewichtiger Prozess bietet au erdem die Gefahr ins Chaos abzugleiten wenn nicht diszipliniert gearbeitet wird hnliche Beobachtungen schildern auch Lippert et al LRWZO01 Wir konnten beispielsweise beobachten dass bei Zeitdruck auf Test First verzichtet wurde was fatale Folgen hatte VeranstalterInnen sollten dann im Interesse der Lernenden Einfluss nehmen und auf die Einhaltung des Prozesses dringen Ein geplant vorliegender phasenorientierter Prozess Schm01 bietet Anf ngern die ja Softwareentwicklung gerade erst lernen sollen Halt und bersicht Ein XP Projekt ist betreuungsintensiv VeranstalterInnen von XP Projekten m ssen mehrere Rollen einnehmen die nur schwer vereinbar sind Als Lehrende m ssen sie insbesondere auf die saubere Umsetzung der Konzepte achten auch wenn das Projektziel gef hrdet ist Daneben m ssen die Lehrenden im XP Projekt auch die Rolle de
261. tika eingesetzt Im ersten Softwaretechnik Praktikum arbeiteten 6 Gruppen mit 5 bis 7 Studierenden an der Realisierung eines synchronen kooperativen Spiels Die Gruppen nutzten CURE haupts chlich zur Kommunikation und zur Dokumentation von wichtigen Entwurfsentscheidungen Alle Gruppen berichteten dass CURE die Grup penkommunikation erleichtert hat Alle Gruppen gaben zu einzelne Arbeitspunkte und Zust ndigkeiten nicht intensiv genug in CURE dokumentiert zu haben Letzteres f hrte http www eclipse org koi Eine Plattform f r die Softwaretechnik Fernlehre 91 dazu dass die Aufgabenverteilung in den einzelnen Gruppen nicht f r alle Mitglieder klar war und es so zu Missverst ndnissen bei der Koordination gekommen ist Bei der Begutachtung der einzelnen Gruppenergebnisse war jedoch auff llig dass die Gruppen mit dem h chsten Kommunikationsaufkommen in CURE die besten Ergebnisse abge liefert hatten Im zweiten Softwaretechnik Praktikum arbeiten zurzeit 3 Gruppen mit jeweils 7 Studierenden an Erweiterungen der CURE Plattform die synchrones kollaboratives Lernen erm glichen sollen Aufgrund der Erfahrung des ersten Praktikums wurde in der ersten Pr senzphase des Praktikums CodeBeamer vorgestellt und die Wichtigkeit einer klaren Aufgabenverteilung herausgestellt Die Gruppen konnten sich frei entscheiden ob sie zu ihrer Koordination CodeBeamer einsetzen wollten Eine der Gruppen hat sich f r die Nutzung von CodeBeamer entschieden w
262. tionen wie Strg v fl ssig benutzen zu k nnen Aus den bisherigen Erfahrungen mit Teachlets konnten die folgenden Hinweise f r Teachlet Moderatoren destilliert werden e Mache die Aufgabenstellung so deutlich wie m glich Wenn die Aufgabe nicht gut von allen Teilnehmern verstanden ist kommt ein Teachlet oft ins Stocken Idealerweise ist die Aufgabe auf eigenen Folien formuliert Es sollte explizit nachgefragt werden ob alle Teilnehmer die Aufgabenstellung ver standen haben sich nicht u ernde Teilnehmer sollten explizit zum Nachfra gen ermuntert werden wenn noch nicht alles klar ist e Halte die Stille aus Wenn bei einem Teachlet die Teilnehmer ruhig sind dann oft deshalb weil sie sich in den Quelltext einlesen bzw eindenken Das braucht Zeit die auch gelassen werden sollte e Behalte den berblick und die Kontrolle H ufig gibt es ausf hrliche Dis kussionen unter den Teilnehmern Diese sind erw nscht sollten aber nicht zu sehr ausufern Notfalls m ssen schlechte Beitr ge knapp behandelt und langwierige Diskussionen beendet werden Die Choreographie sollte nicht aus den Augen verloren werden Als guter Tipp hat sich erwiesen Die R ck kehr zum Ablauf sollte nicht mit der Vorwegnahme des n chsten Schrittes erzwungen werden sondern mit einer Zusammenfassung des bisher Geschehenen und der Frage wie es nun weitergehen soll 100 5 Axel Schmolitzky Denke laut Es sollten alle Dinge erl utert werden die in der Ent
263. ts erg nzten sie ein vorge gebenes ER Diagramm Bei den Sequenzdiagrammen wurden zu Klassenbeziehungen die notwendigen Sequenzdiagramme erstellt Diese Diagramme wurden zur Spezifikati on Implementierung und Durchf hrung von Integrationstestf llen verwendet In der dritten bung wurden insbesondere auch Testf lle f r Klassen spezifiziert implementiert und ausgef hrt Die Testf lle wurden unter Verwendung der quiva lenzklassenbildung in Kombination mit der Anweisungs berdeckung erzeugt Auf diese Weise bekamen die Studierenden einen ersten berblick ber die Komplexit t des Systems und lernten parallel dazu eine der wichtigsten Arten der Qualit tssicherung kennen Die Techniken der Anforderungsspezifikation wurden in der f nften bung nach dem in Pae 03 beschriebenen aufgabenorientierten Vorgehen eingesetzt Die Studie renden sollten zu gegebenen Aufgabenbeschreibungen zuerst vorhandene Use Case Texte erg nzen und ein Use Case Diagramm ableiten und danach eigenst ndige Use Case Texte erstellen Weiterhin hatten die Studierenden die Aufgabe anhand einer vorgegebenen Checkliste die vorhandene Anforderungsspezifikation die k nstlich eingebaute Fehler enthielt zu inspizieren Die w hrend der Inspektion gefundenen Fehler sollten im Anschluss selbstst ndig beseitigt werden Zum Abschluss der ersten H lfte der bungen erstellten die Studierenden aus den nun vollst ndigen und richtigen Anforderungen die Systemtestf lle Da
264. ts genannt ist die Projektdokumentation Teil des Vorgehensmodells und eines der Lernziele des Fachpraktikums Zur Unterst tzung einer systematischen Do kumentation werden den Studierenden Dokumentvorlagen zur Verf gung gestellt Der Einsatz der Vorlagen ist f r die Studierenden verbindlich wobei lediglich die Doku mentstruktur und Hinweise zum Inhalt der Kapitel vorgegeben werden Auf Basis der erstellten Dokumente werden zu bestimmten Zeitpunkten des Arbeitsverlaufs Meilen steine Reviews durchf hrt Dabei erfolgt eine Diskussion der zu diesem Zeitpunkt vorliegenden Ergebnisse zwischen Studierenden und Betreuern 3 Fahrrobotersteuerung durch unbekannten Hindernisparcours Die Aufgabenstellung des Fachpraktikums ist die Entwicklung einer Steuerungssoft ware die einen Fahrroboter von einem vordefinierten Startpunkt durch einen unbekann ten Hindernisparcours in einen definierten Zielbereich steuern soll F r die Man vrie rung des Roboters durch den Parcours m ssen die Studierenden geeignete Wegfin dungsalgorithmen bereitstellen und als Steuerungssoftware umsetzen Welche Strategie der Roboter dabei anwendet bleibt jedem Team frei berlassen wodurch vielf ltige L sungen f r die Aufgabe entstehen Der Zielbereich den die Roboter ansteuern sollen befindet sich in einem Korridor der durch die Ziellinie vom restlichen Parcours abge trennt ist vgl Abb 2 berf hrt ein Roboter die Ziellinie ist das Ziel im Sinne des Wettbewe
265. ttform f r die Softwaretechnik Fernlehre 89 Kommentare Freihand Zeichnungen und beliebige andere Figuren in die Dokumente integriert werden Kurz gesagt handelt es sich also um eine Kombination aus Shared Whiteboard und UML Diagrammeditor Das Besondere an dem Werkzeug ist dass alle Teammitglieder gleichzeitig sehen k nnen was gerade vor sich geht Gleichzeitig k nnen sie auch wenn sie erst sp ter dazukommen nachvollziehen was sich bereits getan hat da Chat Meldungen ebenfalls von dem Programm aufgezeichnet werden Die Chat Meldungen k nnen gegebenenfalls sogar mit bestimmten Elementen des aktuellen Arbeitsbereichs verbunden werden Wir werden dieses Projekt noch genauer evaluieren und dann entscheiden ob sich eine Integration in unsere Plattform realisieren l sst Phase 4 Implementierung und Modultests Eclipse ist schon hervorragend ausgestattet um den Programmierer bei der Entwicklung von Java Programmen zu unterst tzen Andere Sprachen werden zwar noch nicht so gut unterst tzt aber das wird sich in Zukunft ndern Zum Testen wird JUnit schon mit Eclipse ausgeliefert Unsere Studierenden m ssen JUnit au erdem benutzen um ihre Module zu spezifizieren Unabh ngig von der Programmiersprache gibt es bereits eine Team Schnittstelle in Eclipse die eine Anbindung an ein CVS Sys tem erlaubt An der FernUniversit t gibt es einen CVS oder SubVersion Server auf den die Studierenden dann mit Hilfe der Team Schnittstelle zugreifen K
266. twicklungsarbeit entspricht kleineren bis mittleren Projekten wie sie in der Wirtschaft durchgef hrt werden Selbst wenn be r cksichtigt wird dass Studenten noch nicht die Produktivit t eines in der Wirtschaft angestellten Entwicklers haben und zudem nicht Vollzeit am Projekt arbeiten steht eine Gesamt Entwicklungsleistung von mehreren Entwicklermonaten zur Verf gung Die Aufgabenstellungen der studentischen Projekte stammen meist aus dem T tig keitsfeld des betreuenden Instituts sind k nstlich vom Betreuer erdacht oder von den Studenten selbst gew hlt K nstlich erdachte Aufgabenstellungen haben den Vorteil dass der Gesamtaufwand durch ndern der Aufgabenstellung leicht gesteuert werden kann Man kann die Aufgabe Jahr f r Jahr leicht modifizieren was zu geringerem Betreuungsaufwand f hrt Auch Musterl sungen k nnen leichter erstellt werden Der Nachteil der k nstlich erdachten Aufgabenstellung ist dass eine Verwendung der Projekte der Lehre mit hochschulexternen Kunden 135 Ergebnisse nach Ende des Praktikums praktisch ausgeschlossen ist Damit wird geleis tete Arbeit verschwendet und die Motivation der Studenten gemindert Von Studenten selbst gew hlte Aufgabenstellungen f hren u U zu einer Verwendungsm glichkeit der Ergebnisse die Studenten erhalten aber den fatalen Eindruck dass sie die Anforderun gen an das Produkt selbst festlegen k nnen Sowohl Projekte mit k nstlich erdachten Aufgabenstell
267. u04 A Saura Software fault density and workload estimation in the PSP in Finnish Technical Report C 2004 28 Department of Computer Science University of Helsinki 2004 Sof04 Department of Computer Science University of Helsinki Software Processes and Quality course home page http www cs helsinki fi u verkamo swpr swprs2004_eng html Erfahrungen mit XP Doris Schmedding Ingrid Beckmann LS Software Technologie Fachbereich Informatik Universit t Dortmund 44221 Dortmund Doris Schmedding Ingrid Beckmann udo edu Zusammenfassung In einem Software Praktikum hat ein Studierendenteam versuchsweise unter XP gearbeitet w hrend drei Gruppen einer phasenorientierten modellbasierten Vorgehensweise folgten Wir stellen Ergebnisse unsere Beobachtungen und Befragungen vor und ziehen ein Fazit f r unsere weitere Arbeit 1 Einleitung Das eigene Ausprobieren aktueller Trends in der Softwaretechnik bietet Lehrenden die Chance nicht nur ganz neue Erfahrungen mit den neuen Techniken zu gewinnen sondern auch die bisher praktizierten Vorgehensweisen zu verbessern indem Konzepte des neuen Vorgehens mit den bisher praktizierten und bew hrten Verfahren verkn pft werden Die gr ndliche Auseinandersetzung mit dem extrem anderen kann viele n tzliche Erkenntnisse liefern Extreme Programming XP Beck00 ist in den neunziger Jahren aus der Praxis als Gegensatz zur dokumentationslastigen Vorgehensweise bei der Softwareentwicklung entstand
268. uchen sollen solche Reflektionsphasen zu erzwingen auch wenn wir nicht sicher sind wie sich das auf den Fluss des Projekts auswirken wird Alternativ ist angedacht jeden Studierenden am Ende des Projekts einen individuellen Projektbericht schreiben zu lassen in dem er in formell den Verlauf des Projekts im R ckblick beschreibt Eine weitere Idee w re Absolventen eines solchen Projekts im darauf folgenden Jahr einen Hiwi Job als Be treuer eines n chsten Projekts anzubieten In der Distanz als Betreuer und im noch maligen Erleben eines Projekts liegt ein gro es Lernpotenzial 5 Fazit Zusammenfassend stellen wir fest dass auch wenn noch viele Detailverbesserungen denkbar sind ein Teamtraining ein Software Engineering Projekt in der Lehre signifi kant unterst tzen kann Die Studenten k nnen durch das Teambuilding viel schneller in die eigentliche fachliche Projektarbeit einsteigen sie arbeiten im Team deutlich effizienter und strukturierter sie K nnen souver ner mit sozialen und organisatorischen Herausforderungen umgehen Ein Teamtraining unterst tzt folglich den Lernerfolg eines solchen Projekts zum einen dadurch dass w hrend des Projekts weniger die sozialen Probleme dominieren sondern stattdessen mehr Raum f r das Lernen und Ausprobieren klassischer fach licher Software Engineering Inhalte ist Zum anderen wird der Lernerfolg durch eine explizite Behandlung von sozialen und organisatorischen Themen unterst tz
269. udierenden unvorhergesehenen Proble men im Projekt In diesem Artikel stellen wir unsere Erfahrungen mit einem vorbereitenden Teamtraining vor das wir vor diesem Hintergrund als Vorbereitung zu studen tischen Software Projekten durchgef hrt haben Die Zielsetzung dieses drei t gigen Blockseminars besteht darin die Studierenden als Team zusammen finden zu lassen und ihnen bereits vor Beginn des Projekts grundlegende Techniken f r die Zusammenarbeit im Team sowie eine Einf hrung in Projekt management mitzugeben Teamtraining f r Software Ingenieure 27 1 Einf hrung Die Wichtigkeit der praktischen Durchf hrung von Software Projekten in der universi t ren Ausbildung zuk nftiger Software Ingenieure ist mittlerweile erkannt Dement sprechend werden solche Projekte vielfach durchgef hrt und sind bereits an vielen Uni versit ten fest im Curriculum verankert Fle 02 beispielsweise an der TU Darmstadt als einj hriges Software Projekt an der TU M nchen als einsemestriges Software technik Praktikum oder an der Uni Stuttgart gleich zweimal als Softwarepraktikum und als Studienprojekt Solche Projekte zeichnen sich dadurch aus dass studentische Teams in einem m glichst praxisnahen Setting ber einen gr eren Zeitraum hinweg weitgehend selbst st ndig einen Software Engineering Prozess durchlaufen von der Anforderungsanalyse bis hin zur Abgabe eines Produkts In M nchen beispielsweise treten in dem Bem h
270. ults Various sources report a declining defect density on their PSP courses Hum96 Hay97 Abr02 This means that students learn to produce fewer defects in the first place which is a major PSP objective During the first few exercises as the students proceed from PSPO to PSP1 the defect density declines sharply by over 25 Hay97 Later when moving from PSP1 to PSP2 the decrease is only slight In addition to lowering the number of defects PSP aims to address their impact by finding defects early on Initially over 90 of all defects are found and removed during the late phases compile and test Hay97 After code and design reviews are introduced in PSP2 up to half of all defects are found in the early process phases Hay97 Several studies suggest improvement either in the estimation accuracy of program size or effort Hum96 Hay97 Kam00 PreO1 but contradicting observations have also been reported Abr02 The PSP course mandates frequent process changes seven out of ten new programs are written with an altered process which means that the previously collected data quickly loses its value as a basis for predicting future performance PSP adds a considerable load of new tasks to each programming assignment These include keeping records conducting reviews and making predictions and postmortem analyses While these new tasks initially lower productivity they are expected to pay off in continuously increasing productivity once the
271. undlagen deines Teachlets Wenn sich etwa f r die Umsetzung des Entwurfsmusters Iterator die inneren Klassen von Ja va anbieten dann sollte der Moderator erstens gut ber innere Klassen Be scheid wissen und zweitens Folien in der Hinterhand haben mit deren Hilfe er die notwendigen Grundlagen bei Bedarf erl utern kann Eine Teachlet Werkstatt Lernen durch Lehren I hear and I forget I see and I remember I do and I understand nach Konfuzius Dieses Sprichwort spiegelt die insbesondere in der Informatik g ltige Erkenntnis wider dass ein dauerhaftes Verst ndnis vor allem durch eigenes Handeln im Problembereich gef rdert wird siehe etwa EII98 Als Motivation f r die eingangs erw hnte Veran staltung zu fortgeschrittenen Konzepten objektorientierter Programmierung wurde das Sprichwort durch folgenden Satz erg nzt Iteach and I really understand Eine Werkstatt f r Teachlets 101 Die Grundidee der Veranstaltung beruht somit auf der Annahme dass eine Person die anderen Personen ein Konzept in einer Lehrveranstaltung vermitteln muss noch st rker zur Reflexion gezwungen ist als eine ausschlie lich handelnde Person Die Definition des Begriffs Teachlet Werkstatt in Abgrenzung zum Teachlet Begriff lautet Eine Teachlet Werkstatt ist eine seminarartige Semesterveranstaltung in der die Teil nehmer neue Teachlets ausarbeiten Jeder Teilnehmer muss sich dazu mit mindestens einem Lernziel befassen und f
272. ungen in denen f r Vermittlung des Fachwissens bzw praktische bungen mindestens je ein Semester zur Verf gung steht vgl Ble 99 Dem 99 Bot 01 Spi 01 oder auf Lehrveranstaltungen die innerhalb eines Semesters durchgef hrt werden aber auf Kosten von zu vermittelnden Inhalten oder des Praxisbezugs vgl Kle 01 Bec 03 Met 03 Das Ziel an der Universit t Heidelberg war es Vermittlung von Fachwissen und Praxisbezug trotz der K rze der Zeit gleichrangig zu behandeln In diesem Beitrag stellen wir die Grundidee unseres Vorgehens das bearbeitete Softwaresystem und die verwendeten Werkzeuge Abschnitt 2 die konkrete Durchf h rung Abschnitt 3 sowie unsere Erfahrungen bei der Durchf hrung Abschnitt 4 vor 2 Vorgehensweise Die konkrete Herausforderung ist den Studierenden die folgenden Inhalte in 6 SWS zu vermitteln e SWE Methoden zu Entwicklung Qualit tssicherung Weiterentwicklung und Wiederverwendung sowie Management e Ein komplexes Softwaresystem da nur ab einer gewissen Komplexit t SWE Methoden sinnvoll einge bt werden k nnen e Eine m glichst durchg ngige Werkzeugunterst tzung da komplexe Systeme ohne eine solche nicht sinnvoll zu bearbeiten sind Im Folgenden wird zuerst das Gesamtkonzept dann das bearbeitete Softwaresystem und danach die Entwicklungsumgebung vorgestellt 58 Barbara Paech Lars Borner J rgen R ckert Allen Dutoit Timo Wolf 2 1 Gesamtkonzept Unsere innovative Kernid
273. ungen als auch von den Studenten selbst gew hlte Aufgabenstellungen haben den gravierenden Nachteil dass sie das sp tere T tigkeitsprofil eines Software entwicklers nur unzureichend widerspiegeln vor allem bez glich der Analyse und Spe zifikation Die Aufgabenstellung an einem externen Bedarf zu orientieren und die Kundenrolle des Projekts mit einem externen Partner zu besetzen hat zwei offensichtliche Vorteile Erstens ist es f r die Motivation der Studierenden f rdernd wenn das Ergebnis einge setzt wird oder der Einsatz zumindest nicht grunds tzlich ausgeschlossen ist Zweitens kann die Analysephase weit realistischer als bei institutsinternen oder erdachten Aufga benstellungen durchgef hrt werden da ein echter Kunde als Interviewpartner f r die Studierenden zur Verf gung steht Im Folgenden werden zwei studentische Projekte beschrieben die am Institut f r Softwaretechnologie der Universit t Stuttgart im Studiengang Softwaretechnik durch gef hrt wurden und deren Aufgabenstellung durch externe Partner vorgegeben war In beiden Projekten wurde die Kundenrolle auch durch diese externen Partner besetzt 2 Softwarepraktikum im Grundstudium 2 1 Rahmenbedingungen Das Softwarepraktikum muss von allen Studenten der Softwaretechnik im Grundstudi um absolviert werden Das Praktikum wird in Gruppen mit je drei Studenten durchge f hrt der Umfang betr gt je Student 6 Semesterwochenstunden Pro Gruppe steht damit eine Arbeit
274. ungen und Perspektiven Das Teamtraining wurde von den Studierenden sehr positiv aufgenommen sowohl in der Evaluation direkt nach dem Training im April als auch r ckblickend in der Evaluation am Ende des gesamten Projekts im August Zu Beginn des Projekts konnten wir beobachten dass das studentische Team selbst bewusst und mit optimistischer Stimmung ins Kick off ging W hrend in den Jahren zu vor ohne Teamtraining die Studierenden anfangs sch chtern und desorganisiert waren war das diesj hrige Team sofort in der Lage und f hlte sich auch entsprechend sicher vorbereitet mit der fachlichen Arbeit mit Beginn des STP zu beginnen Die Folge war dass dadurch mindestens ein bis zwei Wochen einspart wurden die dem Team somit zus tzlich f r die Bew ltigung der fachlichen Aufgabe zur Verf gung standen insofern war das Teambuilding erfolgreich In Bezug auf die Umsetzung der Arbeitstechniken zeigte die Beobachtung des Teams w hrend des Projekts dass viele gelernte Techniken nicht voll eingesetzt wurden Daf r sehen wir vor allem drei Gr nde Struktur Die Studierenden hatten bei vielen Meetings das Empfinden die gelernte Systematik Tagesordnung Sitzungsleitung Protokoll nicht einsetzen zu m ssen da es sich ja nur um ein normales bzw einfaches Meeting handele Unsere Beobachtung ergab allerdings dass das Einsparen einiger Minuten Sitzungsorganisation am Beginn des Meetings die Besprechungen in
275. ute Erfahrungen gemacht ber eine Web Lernplattform werden f r jede Praktikumswoche im Schnitt zehn Seiten Software Engineering Inhalte bereitgestellt welche genau auf die jeweilige Praktikumseinheit abgestimmt sind Zu Beginn des Praktikums mehr gegen Ende weniger Diese sind vor der Praktikumseinheit zu lesen und enthalten auch den bungsablauf Dies wurde kombiniert mit einer deutlichen Erwartungshaltung dass jeder sich vorbereitet und einer Gestaltung der Pr senzzeit welche eine hinreichende Vorbereitung erzwingt In fr heren Durchf hrungen des SoPra hatten wir die zu den Praktikumseinheiten geh rende Theorie zu Beginn der Veranstaltung verk rzt vorgetragen weil die meisten Studierenden nicht ausreichend vorbereitet zu den Praktikumsterminen kamen Dies hatte den Nachteil dass vorbereite te Studierende demotiviert wurden und nicht vorbereitete nur einen gek rzten Ersatz f r das nicht Gelesene erhielten Diese Vortr ge wurden im SoPra 2004 nach dem Prinzip Studierende k nnen sel ber lesen auf Organisatorisches und auf Motivation reduziert Den Obertutoren fiel es nicht leicht anstelle von Theorie Motivation zu vermitteln eine nicht allt gliche Auf gabe im Studium Wenn der Praktikumsleiter ber eigene Praxiserfahrung verf gt kann er gelegentlich den Motivationsteil der Einleitung bernehmen und pers nliche Erfah rungen aus der Praxis zu dem Thema der Praktikumseinheit einbringen 3 5 Didaktisches Ziel Individu
276. v der Bundeswehr M nchen B Wittek TU Dresden Projekte der Lehre mit hochschulexternen Kunden urrssnrmeneennn 134 T Hampp S Opferkuch R Schmidberger Univ Stuttgart Kurzvortr ge AMEISE Didaktische Vielfalt f r SESAM J ger et dl eennnnnnnnnennnennnnnn 145 Das Software Engineering Praktikum SEP Kaiser und Klaus 147 Software Engineering Unterricht online Schmiedecke Weber Wulff 149 Selbstgesteuertes Lernen und interdisziplin re Projektarbeit Hopf 151 Eingeladener Vortrag Ausbildung in empirischer Softwaretechnik Walter F Tichy Institut f r Programmstrukturen und Datenorganisation Universit t Karlsruhe Postfach 6980 76128 Karlsruhe tichy ira uka de Zusammenfassung Empirische Untersuchungen sind aus der Softwareforschung nicht mehr wegzu denken Zukiinftige Software Ingenieure sollten daher in der Lage sein empiri sche Studien in der Softwaretechnik zu verstehen und in ihrer Aussagekraft ein zusch tzen Forscher sollten zus tzlich die Methodik des Experimentierens er lernen k nnen Aus diesem Grunde bietet die Universit t Karlsruhe seit SS 2001 die Vorlesung Empirische Softwaretechnik an In dieser Veranstaltung wer den sowohl wichtige Ergebnisse aus der empirischen Softwareforschung als auch die experimentelle Methodik behandelt Aus Motivationsgr nden ist die Vorlesung stark an Beispielstudien orientiert an denen die verschiedenen Me thoden wie
277. venten die nicht nur die fachli chen Grundlagen also die so genannten Hard Skills beherrschen sondern auch ber gewisse Soft Skills wie Teamf higkeit Konfliktf higkeit und F higkeit zur Projekt arbeit verf gen Im heutigen industriellen Umfeld wo Software fast ausschlie lich im Team entsteht wird der Mangel an oben genannten F higkeiten h ufig beklagt Voos03 Leider ist festzustellen dass die Hochschulausbildung in Ingenieurstudien g ngen kaum Elemente aufweist in denen diese F higkeiten gezielt vermittelt und ge f rdert werden Im Gegenteil Die Hochschulausbildung hat diese Herausforderungen bisher vernachl ssigt und sich auf die fachliche Ausbildung des einzelnen Studierenden konzentriert Studierende haben also keine M glichkeit derartige f r die Berufsaus bung nicht unerheblichen F higkeiten im Rahmen ihres Studiums zu erlernen Vor diesem Hintergrund sah sich das Institut f r Automatisierungs und Software technik IAS der Universit t Stuttgart in der Verantwortung eine universit re Lehrver anstaltung zu schaffen die sowohl den Praxisbezug der fachlichen Ausbildung herstellt als auch Aspekte wie die Team und Projektarbeit geb hrend ber cksichtigt und vermit telt Entstanden ist hierbei das Fachpraktikum Softwaretechnik das zur Erg nzung und Vertiefung der Lehrinhalte der Vorlesung zur Ausbildung von Ingenieuren im Bereich der Softwaretechnik dient Gleichzeitig tr gt es zur Vorbereitung de
278. wicklungs umgebung passieren Alle eingesetzten Werkzeuge sollten bei ihrer Benut zung kommentiert werden So jetzt bersetze ich das mal An dieser Stel le setze ich ein Refactoring von Eclipse ein etc Insbesondere eher unge w hnliche oder seltene T tigkeiten m ssen erl utert werden Beherrsche den L sungsraum F r eine spezifische Aufgabenstellung gibt es oft mehrere L sungen Der Moderator sollte gut auf verschiedene L sungs vorschl ge vorbereitet sein Er sollte sich gute Argumente gegen L sungen zurechtlegen die vom Lernziel ablenken w rden aber andererseits auch of fen sein f r gute Vorschl ge die ihm selbst vorher nicht eingefallen sind Setze gezielt Wiederholungen ein Wiederholungen erm glichen Teil nehmern die kurz abgeschaltet haben wieder auf die Spur zu kommen Zusammenfassungen sollten immer wieder eingestreut werden in denen der Moderator das bisherige Geschehen knapp wiederholt Sie k nnen oft mit dem Satz eingeleitet werden Was haben wir bisher gemacht Benutze Klassendiagramme zur Visualisierung Wenn ein Standardmuster aus GHJV95 vorgestellt wird dann sollte auf den Folien zumindest das ge nerische Klassendiagramm des Musters aufgef hrt sein F r das konkrete System ist au erdem oft ein spezifisches Klassendiagramm w nschenswert Je nach Teachlet ist entweder ein Diagramm des Ausgangssystems oder ein Diagramm des fertigen Systems sinnvoll Beherrsche die notwendigen Gr
279. z der kurzen Zeit gelernt selbstst ndig nderungen an einem gro en Softwaresys tem durchzuf hren Der Nachbearbeitungsaufwand ist mit 7 Stunden eine Stunde h her als von uns geplant aber sicherlich nicht h her als bei anderen auf praktische bungen ausgerichteten SWE Veranstaltungen Der Betreuungsaufwand war allerdings sehr hoch und ist sicherlich nur bei diesen geringen Studierendenzahlen zu leisten 5 Zusammenfassung und Ausblick In diesem Beitrag haben wir eine M glichkeit vorgestellt wie man eine SWE Lehrveranstaltung strukturieren kann um sowohl SWE Wissen als auch Praxis inner halb eines Semesters vermitteln zu k nnen Dabei lernten die Studierenden im ersten Schritt ein bestehendes komplexes Softwaresystem durch Reverse Engineering zu ver stehen und im zweiten Schritt in dieses System nderungen durch Forward Engineering einzubauen Auf diese Weise lie sich insbesondere Qualit tssicherung fr h thematisie ren Die Lehrveranstaltung wird im kommenden Sommersemester wiederholt Dazu wird den Studierenden ein Prozesshandbuch zur Verf gung stehen das das Forward Engineering Vorgehen und die einzelnen Techniken erkl rt Weiterhin wollen wir die Rationale Funktionalit t des Werkzeugs verst rkt einsetzen Die Studierenden sollen in der Lage sein ihre getroffenen Entscheidungen und die betrachteten Alternativen f r andere sichtbar zu machen Dies soll insbesondere die Selbstreflexion f rdern Lew 01 Vom Code zu den
280. zur Verf gung hatten Allerdings bietet CURE nicht die Funktionalit t von existierenden Projektmanagement Werkzeu gen Daher setzen wir zum Projektmanagement CodeBeamer ein Dabei handelt es sich um eine serverbasierte L sung die eine Reihe von leicht verst ndlichen Kooperations hilfen anbietet CodeBeamer unterst tzt Projektmanagement durch verschiedene Tracker die zum Verwalten von Anforderungen Aufgaben Bugs usw genutzt werden k nnen Die einzelnen Trackerdaten k nnen in Diagrammen z B Gantt Diagramme visualisiert werden Durch diese Tracker k nnen sowohl die Studierenden als auch die Betreuer leicht sehen wie das Projekt voranschreitet Dieser Aspekt wird auch noch dadurch verst rkt dass CodeBeamer anzeigt welche Dinge zuletzt erledigt worden sind bzw welche Aufgaben als N chstes zu bew ltigen sind Es gibt bereits ein Eclipse Plug in von CodeBeamer das die Tracker Ansicht des Produkts in eine eigene Eclipse Sicht integriert Der CodeBeamer Dienst wird von einem Server an der FernUniversit t angeboten und kann somit von jedem Teilnehmer des Softwaretechnik Praktikums in Anspruch genommen werden Neben dem Plug in muss auf Studierendenseite keine weitere Software installiert werden Abbildung 1 zeigt einige Tracker von CodeBeamer in der unteren Sicht 3 3 Werkzeuge f r die Phasen eines Projekts Neben den zwei oben genannten gro en Komponenten unserer Plattform haben wir einige bereits existierende Plug ins f
281. zuzuschreiben SWP04 als der blichste Ansatz hat uns gezeigt dass eine kleine Zahl sehr deutli cher Interventionen zu bewusst wahrgenommenen Erfahrungen im vollen Sinn der De finition f hren kann Damit hat man zwar nur wenige Aspekte abgedeckt diese aber wirksam vermittelt Wir finden diesen Ansatz sehr vielversprechend zumal er auch noch den Aufwand in Grenzen h lt Wir werden nun mit anderen Interventionen expe rimentieren als beim ersten Durchgang Das Prinzip der Agile Hour zur Erfahrungsvermittlung scheint zu funktionieren Gewiss ist auch der Neuigkeitswert f r die positive Reaktion mitverantwortlich Im n chsten Schritt denken wir ber hnliche Anwendungen nicht nur agile Prozesse nach bei denen Erfahrungen konzentriert erzeugt und kompakt vermittelt werden sol len Die Agile Hour ist geradezu daf r optimiert in k rzester Zeit Gef hle wachzurufen und echte Erfahrung m glich zu machen So einen Ansatz kann man freilich nicht st n dig einsetzen weil das Abrufen von Gef hlen auch anstrengend ist und sich nicht be liebig h ufig wiederholen l sst In Hannover werden wir weiter gezielt nach Techniken forschen die Erfahrungen erzeugen sie durch Speicherung und Verteilung frisch halten und f r die Nutzung bereit machen F r Anregungen und Gedankenaustausch auf diesem Weg sind wir dankbar Literatur ASE 04 Abteilung Software Engineering SESAM Projektseite htip www iste uni stuttgart de se resea

Software Engineering im Unterricht der Hochschulen

Contents

Download Pdf Manuals

Related Search

Related Contents