SEUH 2011
Software Engineering im
Unterricht der Hochschulen
Tagungsband 12. Workshop SEUH München, 24. – 25. Februar 2011
Herausgeber: Jochen Ludewig*, Axel Böttcher**
Redaktion: Holger Röder*
* Universität Stuttgart, Institut für Softwaretechnologie
** Hochschule München, Fakultät für Informatik und Mathematik
Inhaltsverzeichnis
Vorwort 2
Eingeladene Beiträge
Effizientere Software-Entwicklung durch Industrialisierung der Prozesse Oliver F. Nandico
3 – 8
Praxis lehren und Forschung umsetzen: Wie können Hochschullehrer diese Kluft überbrücken?
Heinz Züllighoven
9
Referierte Beiträge
Planspiel und Briefmethode für die Software Engineering Ausbildung – ein Erfahrungsbericht Georg Hagel, Jürgen Mottok
10 – 15
Teamentwicklung in studentischen Projekten Doris Schmedding
16 – 20
Dynamische Klassendiagramme – Nutzung der Metapher vom „Konsumieren und Produzieren“
in BlueJ
Axel Schmolitzky, Chris Stahlhut
21 – 26
Ein Dashboard für Learning-Management-Systeme Daniel Kulesz
27 – 32
Kompetenzorientierte Lehre im Software Engineering Axel Böttcher, Veronika Thurner, Gerhard Müller
33 – 39
Vier Jahre Software-Engineering-Projekte im Bachelor – ein Statusbericht Stephan Kleuker, Frank M. Thiesing
40 – 44
Vorwort
Jochen Ludewig, Universität Stuttgart ludewig@informatik.uni-stuttgart.de
1992 fand in Stuttgart die SEUH statt; damals war nicht abzusehen, dass daraus eine Institution wer- den würde. Kurt Schneider, damals Mitarbeiter, heute Kollege, und ich haben freihändig ein Kon- zept entworfen, das bei den folgenden Tagungen dieser Reihe verfeinert, aber kaum geändert wurde.
Heute sind die Invarianten der SEUH:
•
Die SEUH findet alle zwei Jahre am letzten Donnerstag und Freitag im Februar der ungera- den Jahre statt.•
Tagungssprache ist Deutsch; wer nicht Deutsch spricht, trägt auf Englisch vor.•
Die Tagung wird durch einen Tagungsband do- kumentiert. (Erstmals liegt hier ein virtueller Tagungsband vor!)•
Veranstaltungsort ist abwechselnd eine Univer- sität und eine Fachhochschule. Ist der Ort eine Fachhochschule, dann wird das Programm- komitee von einer Person aus der Universität geleitet, und umgekehrt. Alle Mitglieder im Programmkomitee haben SEUH-Erfahrung.•
Die Teilnahmegebühren sind sehr niedrig.•
Nach dem Vorabendtreffen am Mittwoch steht am Donnerstag das eigentliche „soziale Ereig- nis“ auf dem Programm.•
Die Diskussion nimmt breiten Raum ein, mindestens die Hälfte der Zeit. Es gibt in der Diskussion keine heiligen Kühe.•
Die Kontinuität sichert ein Lenkungskreis aus (normalerweise) drei Personen.In Zukunft wird darüber nachzudenken sein, wie Form, Rhythmus und Ausrichtung der Tagung weiterentwickelt werden sollten. Insbesondere ist das Verhältnis zur deutschen Software-Engineer- ing-Konferenz zu klären.
Im Programm dieser zwölften SEUH liegt der Schwerpunkt bei den studentischen Projekten.
Denn inzwischen hat sich herumgesprochen, dass wir im traditionellen Unterricht nur Grundlagen vermitteln können, die dann praktisch erprobt, eingeübt und stabilisiert werden müssen. Weitere Beiträge befassen sich mit dem durchgängigen Beispiel in der Lehre, einer Entwicklungsumge- bung für die Programmierausbildung und einer Software zur Verwaltung der Lehrveranstaltungen.
Im ersten eingeladenen Vortrag von Oliver F.
Nandico (CapGemini) geht es um die Software- Prozesse in der Praxis, im zweiten von Heinz Züllighoven (Universität Hamburg) um die Chan- cen für die Lehre, die entstehen, wenn der Hoch- schullehrer und seine Mitarbeiter auch ein Soft- ware- und Beratungsunternehmen betreiben.
Das Programm dieser SEUH wurde wie üblich von einem Komitee gestaltet, dessen sämtliche Mitglieder mit dem Thema Software-Engineering- Lehre hauptberuflich befasst sind:
•
Axel Böttcher, Hochschule München (lokale Organisation)•
Ralf Bruns, Fachhochschule Hannover•
Marcus Deininger, Hochsch. f. Technik Stuttgart•
Ulrike Jaeger, Hochschule Heilbronn•
Jochen Ludewig, Universität Stuttgart (Vorsitz)•
Barbara Paech, Universität Heidelberg•
Axel Schmolitzky, Universität Hamburg•
Kurt Schneider, Leibniz Universität Hannover•
Silke Seehusen, Fachhochschule Lübeck•
Olaf Zukunft, HfAW HamburgHolger Röder, Universität Stuttgart, hat die Vor- bereitung und Organisation unterstützt. Für die Verwaltung und Begutachtung der Einreichungen wurde das System ConfISS eingesetzt, das 2008/09 im Rahmen eines Studienprojekts der Software- techniker in Stuttgart entwickelt wurde. (ConfISS steht für Conference Information System Stuttgart.)
Allen, die bei Planung und Vorbereitung mitgewirkt haben, ist zu danken, auch all jenen, die – mit oder ohne Erfolg – Manuskripte eingereicht haben. Ganz besonderer Dank gebührt Axel Böttcher, der die Durchführung in München mög- lich gemacht hat.
2010, im SEUH-freien Jahr, ist die Tagung voll- jährig geworden. Ich freue mich, dass nach zwei Töchtern im engeren Sinne auch diese dritte attrak- tiv und erfolgreich ist und in Zukunft des Vaters nicht mehr bedarf. Bei meinem Sohn, dem 1996 entstandenen Studiengang Softwaretechnik, hätte ich noch vor kurzem das Gleiche gesagt. Aber er ist leider in der Pubertät unter schlechten Einfluss geraten (Bologna!). Hoffen wir, dass er diese kritische Phase ohne bleibende Schäden übersteht!
Effizientere Software-Entwicklung durch Industrialisierung
der Prozesse
Oliver F. Nandico
oliver.f.nandico@capgemini.com
Zusammenfassung
Es gibt heu te keine Branche, kein Unternehm en u nd keine Geschäftsp rozesse, bei d enen nich t „ein Stück Software― involviert ist. Wir können u ns eine ganze Reihe alter u nd vor allem neu er Geschäfts- m od elle ohne IT-Unterstü tzu ng gar nicht m ehr vorstellen.
Trotz, od er gerad e au fgru nd d ieser Alltäglich- keit befind et sich d ie Entw icklu ng von Softw are in einem gru nd sätzlichen Wand el als Reaktion au f w id ersp rü chliche Anford eru ngen . Verfallend e Marktp reise u nd steigen d er Prod u ktivitätsd ru ck verlangen d ie Ind u strialisieru ng d er Entw ick- lu ngsp rozesse. Das bed eu tet Wied erholbarkeit, Stand ard isieru ng u nd Au tom atisieru ng. Gleich zei- tig ford ern d ie Anw end er von Softw are d ie sch ne l- le, innovative u nd ganz sp ezifische Reaktion d es Softw areentw icklers au f ihre besond ere Au fgaben- stellu ng u nd ihr Gesch äftsm od ell. So erzielen sie ihrerseits einen Vorsp ru ng im Wettbew erb vor d er Konku rrenz.
Softw areentw icklu ng m u ss also heu te Stand ar- d isieru ng u nd Au tom atisieru ng geeignet m it Flexi- bilität, Reaktionsfähigkeit u nd N u tzernähe kom bi- nieren.
Diese Veränd eru ng in d er Softw areentw icklu ng w irkt sich konsequ enterw eise au f d ie Tätigkeit u nd d as Beru fsbild d es Softw are-Ingenieu rs au s. Zu d iesem Wand el form u liert d ieser Artikel sieben Thesen.
These 1: Standardisierter Prozess
These 1: Software-Entwicklung findet heute in einem wiederholbaren, standardisierten und arbeitsteiligen Prozess statt.
Mit „The greatest improvements in the prod uctive p ow ers of labou r, and the greater p art of the skill, d exterity, and ju d gm ent, w ith w hich it is anyw here d irected , or ap p lied , seem to have been the effects of the d ivision of labour.― beginnt schon Ad am Sm ith sein Werk „Wealth of N ations―.
Vorau ssetzu ng fü r eine p rod u ktivitätssteiger n- d e Arbeitsteilu ng ist ein klar d efinierter Prozess, in d em d ie Au fgaben u nd d ie Tätigkeiten fü r jed e Rolle, u nd Vor- u nd N ach bed ingu ngen festgelegt sind . Unter d em heu te herrsch end en Prod u ktivi- tätsd ru ck in d er Softw areentw icklu ng ist d am it d ie arbeitsteilige Erstellu ng von Softw are in einem stand ard isierten Vorgehen Pflicht fü r jed e IT- Abteilu ng u nd erst rech t fü r jed en IT-Dienstleister.
Die ind u strialisierte Arbeitsw eise hat d en geni- alen Einzelp rogram m ierer od er d as hervorragend e Forschu ngsteam als Schöp fer neu er Program m ier- verfahren u nd Algorithm en in d er täglichen Arbeit, im „Brot- u nd Bu tter―-Geschäft d er Infor m atik abgelöst.
In d er Konsequ enz ersetzt d er Sp ezialist fü r be- stim m te Tätigkeiten im Entw icklu ngsp rozess od er fü r bestim m te inhaltliche Fragestellu ngen d en Ge- neralisten. Diesen Verlu st ganzheitlicher H an d - w erksku nst kann m an bed au ern, aber er ist ein Zeichen fü r d ie gew achsene Reife u nserer Branche.
N icht zu letzt m acht ein stand ard isierter u nd ar- beitsteiliger Prozess d ie Softw areentw icklu ng p lan - u nd kalku lierbarer, d am it letztend lich erst erfolg- reich.
H and w erklicher Vorgehensw eise sind zu d em natü rliche Grenzen im H inblick au f Kom p lexität u nd Größe eines Vorhabens gesetzt. Gerad e d ie fast vollständ ige Du rchd ringu ng aller Fu nktionsberei- che von Unternehm en m it Softw are m ach t d ie Er- stellu ng von n eu en Program m en heu te so schw ie- rig u nd u m fangreich, d ass eine arbeitsteilige Vor- gehensw eise geboten ist.
Der arbeitsteilige u nd stand ard isierte Entw ick- lu ngsp rozess bringt einen w eiteren Vorteil: Er ist m ess- u nd qu antifizierbar. Erst w enn etw as w ir k- lich m essbar ist, kann m an es op tim ieren, klar p la- nen u nd scharf kalku lieren. Dies w ied eru m ist u n- ter d en verfallend en Marktp reisen fü r jed es Ent- w icklu ngshau s ü berlebensnotw end ig.
Welcher Prozess ist aber d er Richtige? Der Ra- tional Unified Process ist sicher w eit verbreitet u nd ein gew isser Stand ard , nich t zu letzt bei Cap gem ini.
Im d eu tschen öffentlichen Dienst ist d as V-Mod ell XT als Stand ard vorgegeben. COBIT u nd ITIL sind gu te Referenzm od elle fü r d ie Softw areentw icklu ng.
N atü rlich p raktizieren eine Reihe von Entw ick- lu ngsteam s, bei u ns u nd and ersw o, u nd ganze Firm en agile Vorgehensw eisen. Wichtig ist: Der d efinierte Prozess m u ss d er Kom p lexität u nd Au f- gabe angem essen, u nd d am it entsp rechend konfigu rierbar sein. Eine Cu stom er -Relationship - Managem ent-Lösu ng fü r ein globales Unterneh- m en ist and ers zu en tw ickeln als ein e And roid - Sales-Ap p .
Alle starren, d efinierten Prozesse sind entsp r e- chend zu verw erfen, and ere Anford eru ngen b e- trachten w ir in d er Disku ssion d er w eiteren Thesen.
Was verlangt nu n d ie Einfü hru ng stand ard i- sierter Prozesse von einem angehend en Softw are- ingenieu r? Zu m einen m u ss er d ie Disku ssion u m d en Softw areentw icklu n gsp rozess kennen, u nd gestalten können. Softw ared ienstleister w ie etw a u nser H au s erw arten von ihren angehend en Be- sch äftigten Wissen u m Aktivitäten u nd Z u sam - m enhänge in d er Softw areentw icklu ng. Der Soft- w areingenieu r m u ss nach seiner Au sbild u ng w is- sen, w as d ie Branche u nter bestim m ten Arbeitser- gebnissen versteht, w elche Anford eru ngen an d iese sein Team u nd d er Ku nd e stellt u nd ü ber w elche Aktivitäten, Method en u nd Techniken sie zu stand e kom m en. Ku rzu m d er angehend e Softw areingeni- eu r brau cht eine Au sbild u ng in d en „ind u str iellen Fertigu ngsp rozessen― d er Softw areentw icklu ng.
These 2: Verringerte Wertschöpfung
These 2: Die W ertschöpfungstiefe in der Entwicklung verringert sich
―There’s only really one metric to me for fu ture softw are d evelop m ent, w hich is — d o you w rite less cod e to get the same thing d one?‖ sagte Bill Gates 2005 im H inblick au f d ie Veränd eru ngen in d er Softw are-Entw icklu ng.
Weniger Cod e bed eu tet eine Verringeru ng Wertsch öp fu ngstiefe in d er eigentlichen Entw ick- lu ng. Diese Tend enz besteht seit Jahrzehnten u nd hat sich im m er w eiter verstärkt. Das fü hrte zu r N u tzu ng von au sgefeilteren tech nischen Prod u kten w ie Tran saktionssteu eru ngen, Datenbankm anage- m entsystem en u nd Bibliotheken fü r fast jed en A n- w end u ngszw eck. Schließlich zu im m er „höheren―
Program m iersp rachen.
Diese Frage d er Wertschöp fu ng d isku tieren d ie Anw end er im m er w ied er u nter d er d ichotom ischen Sichtweise von „Stand ard -Software―, also (Halb-) Fertigsoftw are, u nd Ind ivid u alsoftw are, „m ake or buy―. Die eine Seite führt immer Preis, Erstellu ngs- u nd Wartu ngsau fw and , d ie and ere Seite d ie op t i- m ale Unterstü tzu ng d er sp ezifischen Gesch äftsp r o-
zesse u nd d en d ifferenzierend en Charakter als w esentliche Entscheid u ngskriterien an.
Dieser hebt sich aber zu nehm en d au f: Längst sind Softw arep akete kom p lexe, konfigu rierbare u nd d am it an d ie jew eiligen sp ezifischen Anford e- ru ngen anp assbare System e, d enen im Übrigen d er Kostenvorteil zu nehm end abhand enkom m t. Ind i- vid u alentw icklu ng setzt d agegen im m er stärker u nd nicht nu r als Lip p enbekenntnis au f Wied e r- verw end u ng von bestehend en (Teil-) Lösu ngen, au f d om änensp ezifische Sp rachen u nd Progra m - m ieru ng.
Längst gibt es d arü ber hinau sw eisend d ie A n- gebote „au s d er Wolke―. Salesforce.com überzeugt seine Ku nd en seit m ehr als 10 Jahren, d ass sie ü berhau p t nichts m ehr m it Softw areentw icklu ng zu tu n haben m ü ssen. Was bed eu tet d as fü r d ie interne IT-Abteilu ng?
Die Softw areentw icklu ng ist d am it in Zu ku nft in d er ü berw iegend en Breite m ehr d as Zu sam m en- fü gen von großen u nd kleinen Bau steinen zu einer d em N u tzer op tim al angep assten Lösu ng. Integr a- tion von Softw are au s ganz u nterschied lichen Qu el- len bekom m t so eine viel w ichtigere Rolle als d ie Program m ieru ng von Fu nktionen. Es gilt d as Gru nd p rinzip d er Wied erverw end u ng: Schon w e- nige Tage Recherche nach einer angebotenen Lö- su ng können Monate an En tw icklu ngsarbeit erset- zen.
Das Parad igm a fü r d en Um gang m it d ieser Entw icklu ng ist d ie serviceorientierte Architektu r:
Der Service, d ie angebotene, in sich abgeschlossene u nd elem entare fachliche Leistu ng ist d er Bau stein, u m d en sich d ie Softw areentw icklu ng d reht. Soft- w arep akete m ü ssen solche integrierbaren Services anbieten, d ie Ind ivid u alentw icklu ng erstellt sie u nd Clou d -Betreiber stellen sie ü ber d as Web zu r Ver- fü gu ng. Entw icklu ng w ird d am it m ehr u nd m ehr zu r Architektu rarbeit, zu r r ichtigen Orchestrieru ng von Services.
Der Prozess d er Softw areentw icklu ng m u ss entsp rechend d ieser Entw icklu ng serviceorientierte Architektu r u nterstü tzen. Das heißt er m u ss insbe- sond ere Integration u nd d ie Schaffu ng einer Integ- rationsp lattform angem essen berü cksichtigen. Im Weiteren u nterscheid et d ann d er Prozess d er Soft- w areentw icklu ng nicht m ehr zw ischen ind ivid u a l- entw ickelten od er fertig bereitgestellten Services.
Bed eu tet es nu n, d ass w ir fü r d ie Au sbild u ng in d er Softw areentw icklu ng d ie intensive Beschä fti- gu ng m it d en Prod u kten eines H ersteller s erw ar- ten? Sicherlich nich t, d enn alles Sp ezialw issen ist am End e d er Au sbild u ng m it hoher Wahrschein- lichkeit schon w ied er völlig veraltet. Wichtig sind d agegen Fertigkeiten zu m Um gang m it Softw are- p aketen, zu r Integr ation von Softw arep aketen au s verschied enen Qu ellen m it ind ivid u ell entw ickelter Softw are. Klar form u liert: N icht d er XY-
Mod u lexp erte m u ss Ziel d er Au sbild u ng sein, son- d ern d er Arch itekt von Anw end u ngsland schaften.
Dabei gilt n atü rlich: Dieser Architekt kennt d ie am Markt angebotenen Prod u kte, ihre Stärken u nd Schw ächen.
These 3: Wachsende Automatisie- rung
These 3: Der A utomatisierungsgrad in der Softwareent- wicklung muss steigen
„Der Einsatz von geeigneten Werkzeugen ist ein er d er entscheid end en Faktoren, u m eine system at i- sche Unterstü tzu ng u m zu setzen, w ie sie von Vo r- gehensm od ellen beschrieben w ird . Werkzeu ge w erd en in verschied enster Form in allen w esentli- chen Phasen d er Entw icklu ng u nd d arü ber hinau s eingesetzt.― So beschreibt d er „Leitfad en und d ie Orientierungshilfe― d er BITKOM zum Thema „In- d ustrielle Softw areentwicklung― d en Aspekt Au- tom atisieru ng.
In d er Fertigu ngsind u strie ist eine Vorgabe fü r d ie Prod u ktivitätssteigeru ng u nd entsp rechend e Rationalisieru ng von 10-15% im Jahr völlig norm al u nd allgem ein ü blich. Will d ie Softw arebran che d iesem Beisp iel folgen , ist vor allem eine Au tom ati- sieru ng in d er Entw icklu ng notw end ig, neben d er Stand ard isieru ng d es Prozesses u nd d er Verring e- ru ng d er Wertschöp fu ngstiefe.
Au tom atisieru ng in d er Softw areerstellu ng be- d eu tet d ie m öglich st form ale, konsistente u nd voll- ständ ige Beschreibu ng d er Au fgabenstellu ng au f m öglich st hohem sem antischem N iveau , u m alles w eitere d arau s au tom atisch zu generieren.
Dahinter steht d ie sch on im m er verfolgte Ab- sicht, d ie tatsäch liche Program m ierarbeit in ihrer Kom p lexität u nd Fehleranfälligkeit zu verm eid en.
Diese Absicht leitete sch on d ie Entw icklu ng d er ersten Com p iler.
H eu te bed eu tet Au tom atisieru ng vor allem Einsatz von m od ellgetriebenen Tech niken. Gru n d - lage ist ein e von d er technischen Im p lem entieru ng u nabhängige, im Regelfall grafische Sp ezifikation d er Softw are-Lösu ng. Entsp rechend e Werkzeu ge transform ieren d iese in m ehreren Schritten zu r ablau ffähigen Im p lem entieru ng.
Teil d er Au tom atisieru ng ist d ie A u tom atisie- ru ng fü r d en Test von Softw are. Regressionsfähig- keit von Test u nd angem essener Abd ecku ngsgrad lassen sich ü berhau p t nu r ü ber au tom atisierte Tests erreichen. H ier ist d er allgem ein anzu treffen d e Reifegrad bei d en Anw end eru nternehm en eher nied rig.
Mod ellgetriebene Softw areentw icklu ng u nd Testau tom atisieru ng sind heu te in vielen Bereichen d er Softw areentw icklu ng Stand ard , d ie Wer k- zeu gw elt fast u nü berschau bar. Dennoch zeigen sich noch Sch w achstellen : Du rch satzop tim ieru ng
verlangt Anp assu ngen an d ie ko nkrete H ard w are- Plattform . Darau s resu ltierend e m anu elle Eingriffe in d en au tom atisch erzeu gten Cod e zu erhalten, bed eu tet im m er noch eine H erau sford eru ng fü r d ie Werkzeu ge.
Mod ellgetriebene Entw icklu ng ist heu te d am it ganz selbstverständ lich Teil d es Softw areentw ick- lu ngsp rozesses, Cod egenerieru ng ist Stand d er Technik. Diese Entw icklu ng w ird u nd m u ss sich fortsetzen, im Sinn einer w eiteren Ind u strialisie- ru ng. Das schränkt d ie m anu ellen Cod ieru ngsa r- beiten ein, u nd veränd ert so sicher d en Beru f d es Softw are-Ingenieu rs w eiter.
In d er Konsequ enz m u ss d ie Au sbild u ng fü r Softw arenentw icklu ng d en Um gang u nd Einsatz m it Werkzeu gen zu r Au tom atisieru ng in jed er Be- ziehu ng lehren. Mod ellgetriebene Softw areen t- w icklu ng ist in u nserer Branche ebenso w ich tig, w ie d er Um gan g m it Fertigu ngsrobotern u nd CN C- Masch inen im Masch inenbau .
These 4: Geografische Verteilung
These 4: Software-Entwicklung erfolgt geografisch ver- teilt
„It’s the combination of flexibility, the right com p etencies, the blend of onshore and offshore resou rces and cost savings that m ake Rightshore® su ch an attractive p rop osition.‖ Stefan Fransson, CIO, Mölnlycke H ealth Care
Es ist kein Geheim nis, d ass d ie Verlageru ng von Softw areentw icklu ngsarbeiten in Regionen m it geringeren Lohnkosten internen IT-Abteilu ngen erhebliche Kostenvorteile bringen u nd IT- Dienstleistern nied rigere Preise erm öglichen. Dies ist, trotz d er zu nehm end en Au tom atisieru ng, d em sehr hohen Lohnkosten anteil von 70% (Sch w eizeri- sche Tech nische Zeitschrift) in d er Softw areent- w icklu ng gesch u ld et.
Dazu fallen fü r Softw are keine im eigentlichen Sinn Logistikkosten an. N atü rlich m u ss in d en en t- sp rechend en Länd ern d ie Infrastru ktu ranbind u ng gew ährleistet sein, also Internetverbind u ng existie- ren. H ier leistet etw a in Ind ien d er Staat hohe Vor- leistu ngen. Das gilt analog fü r d ie Au sbild u ng d er Entw icklerinnen u nd Entw ickler.
Viele Ku nd en haben d ie Erfahru ng gem acht, d ass eine einfache Verlageru ng d er Arbeiten in Stand orte m it nied rigeren Löhnen nicht zu d en gew ü nsch ten Ergebnissen fü hrt. Das fachliche Ver- ständ nis w ar häu fig nich t gegeben, Kom m u nikat i- onsp roblem e haben d ie d ie Fertigstellu ng d er Soft- w are verzögert u nd d en Au fw and d afü r erhöht.
Geografische Verteilu ng d er Softw areentw ick- lu ng verlangt einen sehr angep assten Entw ick- lu ngsp rozess, in d em Au fgaben u nd d ie Interaktion zw ischen d en Prozessbeteiligten in ihren Rollen sehr sorgfältig d efiniert sein m ü ssen.
Die Arbeit in einem räu m lich, d .h. geografisch verteilten Team verlangt einen w ohld efinierten u nd arbeitsteiligen Prozess in d er Entw icklu ng, d er allen Beteiligten hinreichend klar ist.
Von d en Beteiligten in d er Softw are- Entw icklu ng erford ert er zu sätzliche soziale Kom - p etenzen, vor allem interku ltu relle Fähigkeiten, d ie ü ber reine Sp rach kenntnisse hinau sgehen.
Genau d ieser Asp ekt ist in d er Au sbild u ng zu verstärken. Das sind d ann Sp rachku rse, d as sind m ehr Au sland sp raktika. Interku ltu relle Fähigkeiten kann m an nicht au s d em Bu ch lernen, m an m u ss sie erleben. Die Erw artu ngen au s d em Bologna - Prozess harren allerd ings leid er noch ihrer Erfü l- lu ng.
These 5: Mehr Kundennähe
These 5: Die N ähe zum Kunden und die V ertrautheit mit seiner A ufgabenstellung müssen sich erhöhen
„We are u ncovering better ways of d eveloping softw are by d oing it and help ing others d o it.
Throu gh this w ork w e have com e to v alu e:
Ind ivid u als and interactions over p rocesses and tools, Working softw are over com p rehensive d ocu m entation, Cu stom er collaboration over contract negotiation, Resp ond ing to ch ange o ver following a p lan.― steht im „Agilen Manifest― von 2001.
Während d ie bisherigen Thesen alle au f einen w ohld efinierten, d etaillierten, eben ind u strialisie r- ten Softw areentw icklu ngsp rozess w eisen , zeigt d ie Disku ssion u nd d er Erfolg agilen Vorgehens, d ass Ku nd ennähe u nd d ie schnelle Reaktion au f verän- d erte Anford eru ngen u nverzich tbar fü r d en Erfolg eines Softw arep rojektes sind .
Vorgehensm od elle, d ie ein Vorhaben nötigen an einer einm al getroffenen fachlichen Entsche i- d u ng od er an d em am Beginn festgelegten fu nktio- nalen Um fang festzu halten , sind zu m Scheitern veru rteilt. Au s d iesem Gru nd hat niem and Wasser- fallm od elle, bei ehrlicher Betrachtu ng d es tatsäch li- chen Vorgehens, w irklich p raktiziert. Lange Sp ezi- fikationsp hasen u nd bei Fertigstellu ng veraltete Softw are w aren u nd sind verbreitete Abbru ch s- grü nd e.
Der Kern fü r d en Erfolg von agilen Method en ist d ie frü he u nd konsequ ente Einbeziehu n g d es Ku nd en u nd Anw end ers. Dazu kom m t d ie Kon- zentration au f lau ffähige Softw are, u m ihm d ie Beu rteilu ng u nd Steu eru ng d es Projektes zu erm ö g- lichen.
Gru nd sätzlich bed eu tet Agilität nich t w ie bis- her d ie Abw ehr aller „störend en― Änd eru ngsa n- ford eru ngen, sond ern d ie bew u sste Au snu tzu ng d er Flexibilität d er Softw areentw icklu ng, u m d en N u tzen fü r d en Ku nd en zu m axim ieren. Im schlechtesten Fall erhält d er Ku nd e am Schlu ss ein
System m it d er H älfte d es gew ü n sch ten Fu nktion s- u m fangs, d as aber d ennoch lau ffähig ist. Das ist besser als eine vollständ ige Sp ezifikation, m it d er er ü berhau p t nichts anfangen kann.
Es gibt jed och Gefahren beim agilen Vorgehen.
Das Entw icklu ngsteam kann Details ü bersehen.
Lokale u nd ku rzfristige Op tim ieru ngen können u m fassend e u nd nachhaltig tragfähige Gesam tlö- su ngen verhind ern. Entscheid u ngsschw ache od er fachlich inkom p etente Ku nd enansp rechp artner verhind ern d en Erfolg.
Mit agilem Vorgehen sind au ch Missverstän d - nisse verbu nd en. Agilität heißt nicht u ngeord netes, au f bloßer d irekter Kom m u nikation basierend es Vorgehen u nd Verzicht au f jegliche Doku m entat i- on. Vielm ehr verlangen agile Prozesse, w ie zu m Beisp iel SCRUM, w eitau s m ehr Wissen u nd Erfa h- ru ng m it d em Prozess u nd m ehr Diszip lin von allen Beteiligten.
Eine Kontroverse besteht, inw iew eit agile Vo r- gehensw eisen bezü glich Projektgröße u nd Projek t- kom p lexität skalieren. Erfahru ngen au s u nserem H au s d eu ten in d ie Richtu ng, d ass w ir im Einsatz von agilen Tech niken sehr genau nach Projekttyp u nterscheid en m ü ssen. Das heißt, d ass agile Tech- niken d ort am besten w irken, w o in einem eher kleinen Team in ku rzer Zeit hoch innovative Lö- su ngen entstehen sollen. Dessen u ngeachtet kö n- nen agile Vorgehensw eise d ie Effektivität u nd Effi- zienz bei großen u nd u m fangreichen Lösu ngen erhöhen. H ier befind en w ir u ns noch in einer Phase d er Disku ssion u nd Forsch u ng.
Eine and ere Frage stellt sich: Interessiert es d en Ku nd en ü berhau p t, nach w elchem Prozess ein Dienstleister fü r ihn d ie Softw are entw ickelt? Die Erfahru ng bestätigt d as. Wenn, w ie in u nserer Branche ein Übergangsstad iu m zu r Ind u strialisie- ru ng gegeben ist, u nd gleichzeitig d er Anteil von gescheiterten Entw icklu ngsp rojekten nach w ie vor sehr hoch ist, d ann ist d as Vorgehen u nd d am it d er Prozess ein w esentliches Argu m ent in d er Au f- tragsvergabe. Zu sich eru ngen in Bezu g au f zeitver- kü rzter Abw icklu ng u nd d ie Anford eru ng nach inten siver Mitw irku n g d es Ku nd en im agilen Pr o- zess verlan gen d ie Darstellu ng von Pr ozess u nd Vorgehen. Folgerich tig gibt es ein sehr vitales Inte- resse d es Ku nd en in Bezu g au f d ie Um setzu ng entsp rechend d em zu gesicherten Verfahren.
Fü r d ie Au sbild u ng gilt hier eine einfache A n- ford eru ng: Kenntnisse u nd Erfahru ng in agilen Techniken. Erfahru ng heißt hier, ein Projekt, also etw a ein Praktiku m nach einem solchen Vorgehen im Team p raktiziert zu haben. Das stellt natü rlich entsp rechend e Anford eru ngen an d ie Au sbild er.
These 6: Schneller!
These 6: Umsetzungsgeschwindigkeit ist essentiell
„Während ein Projektleiter vor einiger Zeit noch stolz sein konnte, w enn er nach einem Jahr ein fe r- tiges System abliefern konnte, m u ss er heu te d iese Au fgabe in längstens einem halben Jahr erled igen können― (CIO eines Kund enunternehmens, 2007).
Aller Prod u ktion, u nd d as sch ließt Softw ar e- entw icklu ng ein, ist gem einsam , d ass d ie Anw e n- d er eine Verringeru ng d er Prozessd u rch lau fz eiten ford ern. Ein e w irtsch aftliche Ch ance hat typ i- scherw eise ein begren ztes Zeitfenster, ein Wettbe- w erbsvorsp ru ng besteht nu r in einem engen zeitli- chen Rahm en. Wenn Softw are d afü r notw end ig ist, u nd d as ist fast im m er d er Fall, d ann m u ss sie jetzt zu r Verfü gu ng stehen.
Stand ard isieru ng, Au tom atisieru ng, selbst d ie Qu a- lität d er Softw are steht au s Sicht d er Anw end er hinter d er Au snu tzu ng d es Chancenfensters z u - rü ck.
Diese gru nd sätzliche Anford eru ng hat es schon im m er gegeben. Darau f hat d as Softw arep rojekt m it Stu fenkonzep ten u nd System d u rchstichen re a- giert. Die Erw artu ngshaltu ng d er Anw end er hat sich ü ber d ie Zeit verstärkt: Wo d iese Anw end er d ie Entw icklu ngszeiten fü r neu e Au tom od elle od er au ch neu e Flu gzeu gtyp en red u zieren m ü ssen, gibt es kein Verständ nis, w enn d ie Softw are, d ie d am it einhergeht, nicht d iese Zeitvorgabe sch afft.
Unter d em gegebenen zeitlichen Dru ck sind d ie Ku nd en häu fig bereit, Ansp rü che an d ie Qu alität d er Softw are zu rü ckzu stellen. Das fü hrt langfristig zu sch lechten Lösu ngen, d ie w ed er anp assbar noch betreibbar sind . H ier ist es d ie Au fgabe d er Soft- w areentw icklu ng, ü ber d ie Gestaltu ng d es Prozes- ses eine Mind estqu alität von vornherein zu sichern.
Dafü r gibt es entsp rechend e Techniken, d ie eben- falls ihre Wu rzeln in d er Disku ssion u m agile Techniken haben. Beisp ielhaft seien hier nightly Bu ild s, frü he Unit Tests u nd Prototyp en genannt.
Trotz d er Au srichtu ng au f d en w ohld efinierten Prozess sind Um fang, sow ie Art u nd Weise d er Doku m entation einer kritischen Betrachtu ng zu u nterziehen. Doku m ente, d ie keine Wirku ng haben u nd keine Entscheid u ng beeinflu ssen, benötigt au ch niem and . Fü r jed es im Prozess zu lieferend e Zw ischenergebnis m u ss am Beginn eines Entw ick- lu ngsp rojektes d ie Projektleitu ng Sinn u nd Zw eck bestim m en können. Ergebnisd oku m ente, d eren einziger Zw eck d ie Erfü llu ng einer Anford eru ng au s d er Prozessd efinition ist, halten d ie Entw ick- lu ng nu r u nnötig au f.
Zu sätzlich zu d en Anford eru ngen an d ie Au s- bild u ng au s d er Disku ssion d er and eren Thesen ergibt sich hier nu r noch einm al hervorzu heben: In d er Au sbild u ng ist nicht nu r Lösu ngs- sond ern
zu kü nftig u nd vor allem Prozesskom p etenz gefo r- d ert.
These 7: Angemessen!
7: A ngepasste Prozesse sind der Schlüssel zum Erfolg
„The d anger of stand ard process is that peop le will m iss ch ances to take im p ortant shortcu ts." Dieses Zitat von Tom DeMarco zeigt sch on rich tig eine d er w esentlichen Gefahren eines w ohld efinierten En t- w icklu ngsp rozesses au f: Er ist nicht an d ie eigentli- che Au fgabe angep asst.
Viele Vorgehensm od elle in d er Vergangenheit, w ie etw a d as V-Mod ell, u nd verschied ene Au sp r ä- gu ngen von Vorgehensm od ellen bei verschied enen Firm en haben oft eine Gem einsam keit: Sie sind relativ starr, ihre Doku m entation ist kom p lex u nd u m fangreich u nd kein betroffener Softw areent- w ickler hat sie angew end et od er au ch nu r versta n- d en.
Das hängt d am it zu sam m en, d ass Theoretiker in verschied enen Definitionen d er Prozesse ver- su cht haben, au f d er abstrakten Ebene jed es En t- w icklu ngsp roblem zu lösen od er zu m ind est d en Lösu ngsw eg ü ber Aktivitäten u nd Ergebnisd ok u - m ente vorzu geben. Das hilft d en Entw icklern nicht u nd m acht d ie Beschreibu ngen nu r u nverständ lich.
Die Id ee, fü r d ie ganz u nterschied lichen Au f- gabenstellu ngen in ganz u nterschied lichen Soft- w arep rojekten d en gleichen Prozess au fzu setzen, ist zu m Scheitern veru rteilt. Das Softw arep rojekt, d as in einem engen vorgegebenen Zeitrahm en ein Preisvergleichsp ortal erstellt, hat m it einem Projekt fü r d ie Entw icklu ng d er Steu eru ngssoftw are fü r einen Laborau tom aten nu r w enige Gem einsam kei- ten.
Das Angebot, einen w ohld efinierten Stand ar d - p rozess zu konfigu rieren , hilft d ann nu r bed ingt w eiter, w enn d er Au sgan gsp u nkt zu kom p lex u nd abstrakt ist.
Es gibt, w ie d ie Disku ssion d er Thesen gezeigt hat, versch ied ene Asp ekte, d ie au f u nterschied liche Entw icklu ngsp rozesse hind eu ten. In u nserem H a u - se sehen w ir sechs Dim ensionen, d ie fü r d en ang e- m essenen Entw icklu ngsp rozess relevant sind :
Priorisieru ng zw ischen Fu nktionsu m fang u nd Zeit
Änd eru ngsd ynam ik bei d en Anford eru ngen
Ku nd enku ltu r
Einbind u ng d es fach lichen Au ftraggebers
Grad d er Abhängigkeiten zw ischen einzelnen Teilkom p onenten u nd –fu nktionen
Projektgröße
Au s d iesen Dim ensionen ergeben sich d ie Asp ekte fü r d en jew eils angem essenen Entw icklu ngsp r o- zess. Im Einzelnen heißt d as insbesond ere, d ass d er Grad an agiler Vorgehensw eise u nd d er Einsatz von bestim m ten agilen Techniken, d er Einsatz von
Offshore-Entw icklu ngskap azitäten u nd d ie Einbin- d u ng von Softw arep aketen bzw . Clou d -Angeboten d arau s abzu leiten ist.
Darau s ergeben sich u nterschied liche Typ en von Projekten u nd Entw icklu ngsp rozessen. Eine nicht abschließend e Liste ist:
Entw icklu ng relativ kleiner, technisch w ie fach- lich hoch-innovativer System e, d ie in einem engen Zeitrahm en p rod u ktiv w erd en m ü ssen.
Entw icklu ng fu nktional u m fangreicher, fach- lich u nd architektonisch kom p lexer System e, d ie d ie d ifferenzierend en Kernleistu ngen eines Unternehm ens u nterstü tzen.
Integration von verschied enen sch on existie- rend en od er neu zu entw ickelnd en Services m it d en Angeboten au s Softw arep aketen u nd Clou d -Angeboten.
Fü r so zu id entifizierend e Projekttyp en gilt es nu n fü r d as Managem ent d er Softw areentw icklu ng , einfache u nd verständ liche Prozessd efinitionen zu erstellen. Au f d em Weg zu m ind u strialisierten Pr o- zess ist nach d er Definition d ann d er zw eite Schritt d ie H erstellu ng d er Au tom atisieru ng u nd Unter- stü tzu ng d er Entw ickler in d er Au sw ahl d es ang e- m essenen Prozesses, sow ie d er Konfigu ration u nd Um setzu ng d ieses so au sgew ählten Prozesses.
Die Konsequenzen für Software- Entwickler
Was bed eu tet nu n d ie Ind u strialisieru ng in d er Softw areentw icklu ng fü r d as Beru fsbild d es Soft- w are-In genieu rs?
Zu nächst einm al heißt es, d ass d ie Reflektion d es Entw icklu ngsp rozesses zu m selbstverständ li- chen Kanon in d er Au sbild u ng gehört. Die Gru n d - lage d ieser Reflektion sind vertiefte Kenntnisse zu d en Stand ard vorgehensm od ellen. H ierzu gehört sicherlich d er Rational Unified Process u nd d as V- Mod ell XT. Dazu kom m en d ie heu te ganz sta n- d ard m äßig vorau sgesetzten Referenzp rozessm o- d elle ITIL u nd COBIT. Ein e Wu nschvorstellu ng ist es, w enn Absolventen au s d er H ochschu lau sbil- d u ng hier schon entsp rechend e Zertifizieru ngen m itbringen.
Genau so, w ie statt einer bestim m ten Progra m - m iersp rache d ie d ahinter stehend en Konzep te w ie Objekt- u nd Asp ektorientieru ng gefragt sind , ist es fü r Vorgehensm od elle entscheid end , ihren Zw eck u nd beabsichtigten Einsatzrahm en zu kennen u nd zu w issen, w o u nd w ie sie anzu p assen sind .
Die Softw areentw icklu ng hat einen hohen Be- d arf an Prozessingenieu ren u nd –ingenieu rinnen.
Diese brau chen w ir fü r d ie Au fnahm e, Mod ellie- ru ng u nd Op tim ieru ng von fachlichen Prozessen in d en verschied enen Branchen, nicht zu letzt fü r d ie eigene, d ie Softw areentw icklu ng.
H eu te fü hren w ir fü r u nsere Beschäftigten in- terne Schu lu ngen zu d iesem Them a d u rch . Dazu leistet eine eigene Gruppe „Prod uktionssteueru ng―
d ie notw end ige Unterstü tzu ng d er Projekte. Diese Unterstü tzu ng ist notw end ig, w eil w ir in u nserem H au se feste Vorgaben fü r d ie Abw icklu ng u nd Du rchfü hru ng von Softw areentw icklu ngsp rojekten m achen. Die Weiterentw icklu ng von Method en u nd Vorgehensm od ellen ist schließlich in d er Kom p etenz u nserer Entw icklu ngsabteilu ng. Insge- sam t betreiben w ir einen hohen Au fw and in d er Um setzu ng von d efinierten u nd stand ard isierten Prozessen. Wie sch on beschrieben, sind fü r u ns d ie ständ ige Verbesseru ng d er Prod u ktivität, u nd d ie schnelle Reaktion au f neu ere Entw icklu ngen , d ie d arau f beru hen, essentiell.
Gerad e im Rahm en einer w eiteren Ind u striali- sieru ng bleiben fü r Softw areingenieu r e d ie sozialen Kom p etenzen w ichtig. An vord erster Stelle stehen d abei Team fäh igkeit u nd Kom m u nikationsfreu d e.
Trotz aller Stand ard isieru ng u nd Au tom atisieru ng bleibt Softw areentw icklu ng ein kreativer Prozess, bei d em ein hochqu alifiziertes Team in d er Zu - sam m enarbeit op tim ale Lösu ngen su cht u nd find et.
Zu nehm end w ichtiger ist d abei d ie globale Au s- richtu ng, d ie interku ltu relle Kom p etenz ü ber bloße Sp rachkenntnisse hinau s verlangt.
Literatur
Agile Manifesto (2001) u nter:
http :/ / agilem anifesto.org
BITKOM 2010, Ind u strielle Softw areentw icklu ng, u nter:
http :/ / w w w .bitkom .org/ files/ d ocu m ents/ Ind u strielle_Softw areentw icklu ng_w eb.p d f DeMarco, T.; Lister, T. (1999): Peop lew are:
Prod u ctive Projects and Team s, Dorset H ou se Pu blishing Com p any, 2nd ed ition, N ew York N .Y. 1999
Krem er, M. (2010): eee@Qu asar: efficient, effective, and econom ic softw are d evelop m ent, Vortrag Cap gem ini Ku nd enforu m Architektu r
Sm ith, A. (2005): An Inqu iry into the N atu re and Cau ses of the Wealth of N ations, Pennsylvania State University, H azelton 2005
Ud ell, J. (2005): Interview w ith Bill Gates, Info- w orld 25. Sep tem ber 2005
Softw are m ad e in Ind ia (2008)
in: Schw eizerische Tech nische Zeitschrift – Sw iss Engneering, Au sgabe N ovem ber 2008, S.10-11
Praxis lehren und Forschung umsetzen: Wie können
Hochschullehrer diese Kluft überbrücken?
Heinz Züllighoven, Universität Hamburg und C1 WPS zuellighoven@informatik.uni-hamburg.de
Zusammenfassung
Die Softwaretechnik an Hochschulen versteht sich meist als anwendungsorientierte (Ingenieur-) Wissen- schaft. Was sind aus heutiger Sicht ihre wissenschaftli- chen Fundamente für die Lehre, und wie stabil sind sie?
Professionelle Softwareentwicklung sollte sich an wissenschaftlichen Konzepten und Ergebnissen orientie- ren. Umgekehrt sollte die Praxis auch Impulse für die anwendungsorientierte Wissenschaft geben. Welche Im- pulse sind dies für die Softwaretechnik?
Der Versuch, anwendungsorientierte Wissenschaft und forschungsorientierte Praxis in Forschung und Lehre zusammenzubringen, läuft in Hamburg seit zwanzig Jahren. Was ist dabei herausgekommen? Was könnte man auf andere Standorte übertragen?
Planspiel und Briefmethode für die Software Engineering Ausbildung -
ein Erfahrungsbericht
Georg Hagel, Hochschule Kempten georg.hagel@fh-kempten.de
Jürgen Mottok, LaS³, Hochschule Regensburg juergen.mottok@hs-regensburg.de
Zusammenfassung
Die konstruktivistische Perspektive unterstützt ei- nen Paradigmenwechsel der akademischen Lehre hin zu einer Lerner- und Lernprozesszentrierung.
Dabei thematisieren Selbstgesteuertes Lernen und aktivierende Lehre das studentische Lernen neu.
Das Zusammenspiel von Lehren und Lernen mit dem Ansatz einer konstruktivistischen Didaktik wird mit Beispielen erprobter Lernkonzepte der Software Engineering Ausbildung der Vortragen- den unterlegt: Planspiel und Briefmethode werden exemplarisch diskutiert.
Die gezeigten konstruktivistischen Methoden las- sen sich auf Lebenslanges Lernen des Software En- gineering im Berufsumfeld übertragen.
Einführung – Lernarrangements für selbstgesteuertes Lernen
Inzwischen ist eine Wende der didaktischen Wahr- nehmung erkennbar. Während die curriculumtheo- retische Didaktik auf der Überzeugung basierte, dass Lernprozesse Erwachsener zielgerichtet plan- bar und steuerbar sind, zielt der konstruktivistisch- didaktische Ansatz auf die Ausgestaltung von Lernumgebungen (Siebert, 2009). In diesen Lern- umgebungen, auch Lernsettings, genannt, sollen selbstgesteuerte und kreative Lernprozesse ange- regt werden. Dabei ist nicht nur das Expertenwis- sen der Referenten eine Ressource, sondern auch das Vorwissen, die Erfahrungen und die Fragestel- lungen aller Beteiligten. Dieser methodisch didakti- sche Ansatz gestaltet einem Paradigmenwechsel
„The Shift from Teaching to Learning“ (Welbers, 2005) aus.
Konstruktivismus
Der Konstruktivismus ist eine Theorie über den Er- werb von Wissen, das Lernen und Lehren. Kern- aussage ist, dass jeder Mensch durch die Kommu- nikation mit seiner Umgebung eine eigene persön- liche Wirklichkeit erschafft; diese unterscheidet sich von der Wirklichkeit anderer Menschen. Ler- nen wird als die Konstruktion von Bedeutung und damit als dynamisches Weiterentwickeln der per- sönlichen Wirklichkeit gesehen. Lernen im didak- tisch konstruktivistischen Kontext unterscheidet:
1. Konstruktion („Wir sind Erfinder unserer Wirklichkeit“),
2. Rekonstruktion („Wir sind die Entdecker unserer Wirklichkeit“) und
3. Dekonstruktion („Es könnte auch anders sein!
Wir sind die Enttarner unserer Wirklichkeit!“).
Die grundsätzliche Ausrichtung ist: „Selbst erfah- ren, ausprobieren, untersuchen, experimentieren, immer in eigene Konstruktion ideeller oder materi- eller Art überführen und in den Bedeutungen für die individuelle Interessen-, Motivations- und Ge- fühlslage thematisieren.“ (Reich, 2008)
In der Perspektive der Rekonstruktion lautet die Frage: „Wer hat es damals so und wer hat es anders gesehen? Welche Handlungsmöglichkeiten haben Beobachter damals festgestellt und welche fallen uns hierzu ein? Welche unterschiedlichen Experten kommen zu welcher Aussage und wie stehen wir dazu?“ In dieser Perspektive wird gefragt, welche Motive der damalige Beobachter hatte um seine Festlegungen zu treffen. Faktenwissen steht dabei nicht im Vordergrund.
Die Dekonstruktion stellt sich die Frage der selbst vollzogenen Auslassungen, die möglichen anderen
Blickwinkel, die sich im Nachentdecken der Erfindungen anderer oder in der Selbstgefälligkeit der eigenen Erfindung so gerne einstellen. In dieser Perspektive will der Enttarner kritisch gegenüber den eigenen blinden Flecken sein.
Als idealtypischer Grundsatz für die konstruktivis- tische Didaktik gilt somit (Reich, 2008):
„Jeder Sinn, den ich selbst für mich einsehe, jede Regel, die ich aus Einsicht selbst aufgestellt habe, treibt mich mehr an, überzeugt mich stärker und motiviert mich höher, als von außen gesetzter Sinn, den ich nicht oder kaum durchschaue und der nur durch Autorität oder Nicht-Hinterfragen oder äu- ßerlich bleibende Belohnungssysteme gesetzt ist.“
Der konstruktivistische Methoden- baukasten in der Software Enginee- ring Ausbildung
Die Software Engineering Studenten müssen von Anfang an nicht nur in Erkenntnistheorie, sondern auch in Problemlösung vertraut werden (Ludewig, 2009). Dies wird durch den Perspektivwechsel von der Input- zur Output-Orientierung unterstützt, wobei durch den Einsatz geeigneter fachdidakti- scher Methoden die Lernenden ihren Lernprozess in Selbststeuerung aktiv ausgestalten.
Den Lehrenden stehen mit den konstruktivistischen Methodenbaukästen „Methodenpool“ (Reich, 2008) und der „Methodensammlung“ (Macke, 2009) Ideenquellen zur Ausgestaltung eines aktivieren- den Lernprozesses zur Verfügung. Erste positive Versuche im Einsatz dieser Methoden findet man beispielsweise in (Mottok, 2009 und Hagel, 2010).
Im Folgenden werden die Erfahrungen mit den Methoden Planspiel und Briefmethode im Fach Software Engineering vorgestellt.
Planspiel
In Planspielen im Fach Software Engineering sollen Studierende durch Simulation einer Praxissituation einen möglichst realistischen und praxisbezogenen Einblick in Probleme und Zusammenhänge der methodischen Softwareentwicklung gewinnen, eigene Entscheidungen treffen und Konsequenzen ihres Handelns erfahren.
Planspiele erfordern zudem eine hohe Partizipation aller Beteiligten. Sie sollten auf eine Erhöhung der Handlungsfähigkeit in dem Sinne zielen, dass sie Konsens und Dissens, Entscheidungsabläufe und Transparenz bei der Bildung von Gruppenentschei- dungen aufdecken und diskutierbar werden lassen (Reich, 2008). Die Studierenden werden im Plan- spiel mittels aktivierender Methoden beteiligt und in ein Software-Projekt involviert. Die Aufgaben- stellung eines Softwareprojekts und die einzuneh-
menden Rollen sind vorgegeben. Das Ergebnis des Planspiels bleibt insofern offen, als dass die Lernen- den verschiedene Lösungswege auffinden können.
Im Curriculum des Bachelorstudiengangs Mecha- tronik der Hochschule Regensburg wird im vierten Semester die Vorlesung Software Engineering im Umfang von 2 SWS/3 ECTS und im fünften Semester das Praktikum/Seminar als Blockveran- staltung Software Engineering im Umfang von 4 SWS/5 ECTS angeboten. Das Praktikum/Seminar Software Engineering verlangt also eine Arbeitszeit von 150 Stunden.
Die Blockveranstaltung Software Engineering (50 Stunden) hat zwei vorgelagerte Vorlesungstermine (je 4 Stunden) zur Vorbesprechung. Danach be- ginnt schon eine selbstgesteuerte Arbeitsphase der Studierenden. Als Vor- und Nachbereitungszeit der Studierenden verbleiben damit 92 Stunden.
Alle Studierenden haben als Vorkenntnisse die Programmiersprachen C und C++ (10 SWS V+Ü), sowie Mikrokontrollertechnik (6 SWS V+Ü). Sie haben dagegen keine Erfahrung über die bei der Programmierung hinausgehenden Schritte der Software-Entwicklung. Praktika und Projekte sind deshalb für die Lehre von Software Engineering zentral (Ludewig, 2009).
Die Vorlesung Software Engineering bereitet auf ei- ne schriftliche Prüfung vor. Dagegen wird die Blockveranstaltung Praktikum/Seminar Software Engineering mit einem studienbegleitenden Lei- stungsnachweis abgeschlossen. Der studienbeglei- tende Leistungsnachweis wird erbracht durch die Vorbereitung eines Fachvortrages, die Vorberei- tung eines Posters, die erfolgreiche Mitwirkung am Planspiel und die Erstellung von Arbeitsprodukten, wie qualitätsgesicherter Dokumentationen, sowie funktionierender Software.
Die Blockveranstaltung Praktikum/Seminar Soft- ware Engineering an der Hochschule Regensburg findet an fünf Tagen statt. Zwei Lehrende gestalten mit Pair-Teaching als interdisziplinäres Team (In- formatiker und Pädagoge/Projekttrainer) diese Veranstaltung. Insbesondere diese Verzahnung im Führungstandem lässt für die Studierenden das Wechselspiel zwischen Konkurrenz versus Zusam- menarbeit/Dialog in einem Klima offener Kom- munikation sichtbar werden. Eine Übertragung auf die eigene Situation im Planspiel wird möglich.
Während in den ersten beiden Tagen Fachthemen erarbeitet und vermittelt werden, werden in den letzten drei Tagen in einem Planspiel die Kenntnis- se und Fertigkeiten in den Fachthemen vertieft und angewendet.
Bereits vier Monate vor der Blockveranstaltung fin- den zwei Vorbesprechungen im Umfang von jeweils 4 Stunden mit den Studierenden statt. Dabei
werden Fachthemen zur Vorbereitung der Block- veranstaltung an die Studierenden vergeben. Diese Fachthemen werden von den Studierenden eigen- ständig bearbeitet. Als Ergebnis werden die Fach- vorträge als Folienpräsentation und Poster in die Lernplattform moodle abgelegt. Der Lehrende gibt zu diesen Ergebnissen Rückmeldung in moodle.
Den Studierenden werden zusätzlich Literaturhin- weise zur Bearbeitung der Aufgaben in der Lern- plattform moodle zur Verfügung gestellt. Die Lernplattform ist vor und während des Planspiels im Einsatz.
Abbildung 1: Software-Architektur mit c’t-Bot, Server-PC und Web-Clienten für das Planspiel Das durchgeführte Planspiel im Fach Software En- gineering behandelt eine Projektaufgabe mit dem Embedded Roboter System c't-Bot. In dieser Auf- gabe soll eine Fernsteuerung- und Fernüberwa- chung des Roboters c't-Bot über einen Server-PC und zusätzlich über Web-Clienten, also Browserap- plikationen, erstellt werden (Abbildung 1). Biblio- theken und einfache Beispiele liegen bereits vor.
Zur Durchführung eines Planspiels im Software Engineering müssen folgende Spielmaterialien be- reitgestellt werden:
• Eine Fallstudie, in der kurz die vorgegebene Softwareaufgabe skizziert wird und Software- Bibliotheken, sowie bestehende exemplarische Teillösungen vorgegeben werden.
• Eine Arbeitskarte mit Erläuterungen zum Ver- lauf des Softwareprojekts (Spielverlauf).
• Rollenkarten, durch welche den Teilnehmern spezifische Rollen übertragen werden (Die Softwareentwicklungsprozesse V-Modell 97 und V-Modell XT wurden bereits in der Vorlesung angesprochen.). Die Studierenden nehmen damit die Positionen einer Rolle (Projektleiter, Software Entwickler,
Qualitätsmanager, Konfigurationsmanager, …) an.
• Ereigniskarten, die als Impulskarten durch den Spielleiter in die Gruppen gereicht werden können (beispielsweise die Änderungen von Anforderungen).
• Quellen und Literatur
Die einzelnen Phasen des Planspiels bestehen aus:
1. Spieleinführung
Die Semestergruppe der Studierenden wird zu Be- ginn des Planspiels in mehrere Planspielgruppen mit jeweils ca. 10 Studierenden aufgeteilt. Der Leh- rende gibt die Ausgangslage schriftlich vor und klärt Verständnisfragen. Das Spielmaterial wird vorgestellt.
2. Informations- und Lesephase, Rollenvertei- lung
Die Gruppen erhalten die Rollen- und Arbeitskar- ten. Das Arbeitsmaterial wird durchgelesen und auftretende Verständnisfragen werden geklärt. Die Teambildung und Rollenverteilung wird von den Lehrenden begleitet.
3. Meinungsbildung und Strategieplanung innerhalb der Gruppe
Die Informationen werden gruppenintern struktu- riert und die Projektaufgabe der Softwareentwick- lung wird analysiert.
4. Interaktion zwischen den Rollen
In dieser intensivsten Spielphase agieren die Rollen der jeweiligen Planspielgruppe miteinander. Inte- ressenkonflikte zwischen den Rollen treten auf.
Diese Interessengegensätze sind typisch bei der Durchführung eines Planspiels. Durch Ereigniskar- ten kann der Spielleiter nun gezielte Impulse und Veränderungen ins Spiel bringen. Alle Planspiel- gruppen treffen sich zweimal am Tag zu einem Jour Fix. Die Rolleninhaber müssen dabei unter Zeitdruck Entscheidungen treffen.
5. Vorbereitung eines Plenums / Konferenz Jeder Rollenträger/Positionsinhaber der jeweiligen Gruppe trägt intern seine Ergebnisse zusammen und verarbeitet und bewertet in dieser Phase die erreichten Ergebnisse.
6. Durchführung eines Plenums / Konferenz Die Ergebnisse des Software-Projektes werden aus der Perspektive des jeweiligen Rollenträgers vor- gestellt. Eine Demonstration mit dem realen soft- ware-intensiven System eines Roboters ist ge- wünscht.
7. Spielauswertung
Auswertung des Spielverlaufs mit dem Lehrenden als neutralen Moderators. Diese Reflexion über den
eigenen Lernprozess ist ein weiteres Merkmal eines Planspiels.
Während der Blockveranstaltung Praktikum/ Sem- nar Software Engineering stehen ausreichend Sem- nar- und Rechnerräume für die einzelnen Plan- spielgruppen zur Verfügung.
Der Ergebnispräsentation am Ende des Planspiels folgt eine Reflexion über den Lernprozess.
In der Reflexion wurden folgende Erfahrungen ge- sammelt und evaluiert:
• Die Lernthemen können von den Studierenden mitbestimmt werden (Rolleninhaber bereiten Themen vor)
• Der Lehrende übt als Spielleiter keine domi- nante Rolle aus, sondern ist Begleiter des Lern- prozesses und berät bei Rückfragen (Aviram, 2000).
• Offene Form des Lernens ermöglicht die einzel- nen Aufgaben zu differenzieren und zu indivi- dualisieren (Macke, 2009).
• Qualitätssicherung durch Literaturvorgaben, sowie Begleitung und Rückkopplung mit der Lernplattform moodle, - auch schon vor der Blockveranstaltung.
• Eigene Lernprojekte konnten aus der Vorberei- tung der Fachthemen eingebracht werden.
• Die Lernorganisation des Planspiels lässt meh- rere Lernwege offen, - Anknüpfung an die Le- bens- und an die Praktikumserfahrung der Lernenden.
• Förderung der Handhabung verschiedenster Arbeitstechniken.
• Die Lerninhalte sind mit dem Anwendungsfall der Projektarbeit fassbar reduziert.
• Die angebotenen Lerninhalte können selbsttä- tig erschlossen werden.
• Handlungsbezogene Problemstellungen im Planspiel sind explizit Thema in der Blockver- anstaltung.
• Bereichsübergreifendes Denken und Handeln wird gefördert, ebenso wie ein Verständnis für gruppendynamische Prozesse und ihre Aus- wirkungen.
• Komplexe Themen, wie Projektmanagement, Qualitätssicherung und Konfigurationsma- nagement können in der zur Verfügung stehen- den Zeit nur in grundlegender Weise vermittelt werden. Eine Vertiefung kann für Mechatronik- Studierende erst im Masterangebot erfolgen.
• Jede Planspielgruppe entwickelt eine andere Kultur.
• Lernen in multiplen Kontexten
• Mit Verlassen des 90-Minutenrythums entsteht Raum, Zeit und Gelassenheit zum Lernen.
Das Planspiel beinhaltet eine große Menge anderer Methoden und Techniken (Methodeninterdepen- denz), in denen sich der Studierende üben kann. Im Einzelnen sind dies die Arbeitsform der Gruppen- arbeit, Strukturierung der Gruppenarbeit durch Moderation, Ideenentwicklung durch Clustering und Concept Learning, sowie Feedback zur Klä- rung von Gruppenkonflikten.
Der Unterschied zu Lernformen wie der Projektarbeit besteht darin, dass es noch stärker die Entwicklung von Handlungs- und Entscheidungs- kompetenzen und das Einüben entsprechender Verhaltensweisen betont (Markowitsch, 2004). Die Begründung von Architekturentscheidungen, die Auswahl möglicher Alternativen in Design und Im- plementierung, die Festlegung eines Testkonzeptes, aber auch die Ausgestaltung qualitätssichernder Review-Sitzungen sind als Beispiele zu nennen.
Diese Beispiele finden sich zwar auch in Projektar- beiten wieder, aber im Planspiel wird die soziale Interaktion der Rolleninhaber und die gemeinsame Reflexion über den Lernprozess am Spielende als methodisches Merkmal genannt. Insofern kann die dargestellte Lernform als projektorientiertes Plan- spiel klassifiziert werden.
An der Blockveranstaltung Software Engineering haben bereits Semestergruppen mit 20 bis 60 Studierenden teilgenommen.
Mithilfe eines standardisierten Fragebogens konn- ten Werte für die Zufriedenheit der Studierenden mit der Blockveranstaltung Software Engineering ermittelt werden. Insbesondere wurden Fragen zur Veranstaltung selbst, den technischen Lernein- heiten und zur Begleitung durch den Lehrenden gestellt. Bei der Zufriedenheit handelt es sich um Einschätzungen der Beteiligten selbst, d.h. die relativen Werte für die Zufriedenheit sind sehr re- präsentativ und spiegeln die Stimmungen ange- messen wieder. An der Umfrage nahmen 80% aller Studierenden teil, sodass die Ergebnisse für den ganzen Kurs geltend gemacht werden können. Die Evaluationsergebnisse waren durchweg positiv.
Kritisch zu bewerten ist, dass die Studien- und Prüfungsordnung für Bachelorstudierende der Mechatronik insgesamt nur 2 SWS Vorlesung und 4 SWS Praktikum/Seminar für das Lehrgebiet Software Engineering vorsieht. Deshalb können die Studierenden sich nur grundlegende Kenntnisse in der disziplinierten Software-Entwicklung bei An- wendung von Softwareprozessmodellen aneignen.
Briefmethode
Auch die Briefmethode stammt aus dem Konstruk- tivistischen Methodenpool (Reich, 2008). Diese Me-
thode wird häufig im Deutschunterricht der Schu- len, aber auch in Geschichte und Literatur einge- setzt. Wir wollten untersuchen, ob sich diese Me- thode auch für den Einsatz in einem technischen Fach, wie Software Engineering an einer Hochschu- le eignet. Dabei wurden seitens der Dozierenden mehrere Ziele verfolgt: Die Studierenden sollten
• einen Sachverhalt, den sie sich vorher erar- beitet hatten, wiedergeben können und
• lernen, Briefe mit technischer Information zu verfassen.
Das Erstellen technischer Dokumentation kommt aus Sicht der Autoren in den Lehrveranstaltungen zum Software Engineering zu kurz und beschränkt sich meist auf die Erstellung von UML-Diagram- men. Texte mit technischem Inhalt, oder gar Benut- zerdokumentation wird sehr selten im Rahmen der Software Engineering-Ausbildung in den Hoch- schulen verfasst. Ein Versuch, wie eine Ausbildung im Technischen Schreiben aussehen kann, findet man in (Schmidt, 2009). Auch werden an verschie- denen Hochschulen inzwischen explizit Veranstal- tungen wie „Software Engineering und Techni- sches Schreiben“ angeboten.
In der Vorbereitung muss zunächst ein hinreichend komplexer Sachverhalt gefunden werden, der sich in Briefform gut vermitteln lässt. In unserem Bei- spiel bat der Dozierende die Studierenden um ein Antwortschreiben auf einen fiktiven Brief (siehe Abbildung 2). Im Brief bittet ein Freund der Studie- renden um Hilfe bei einer betriebswirtschaftlich- mathematischen Aufgabe aus dem Projektmanage- ment.
Abbildung 2: Brief
Die Studierenden, die eine Marginalrenditerech- nung schon mehrmals in Übungen gelöst hatten, sollten "ihrem Freund" in Briefform antworten, also durch selbstständiges Handeln ein neues Produkt, nämlich die technische Lösung der Aufgabe als Brief erstellen.
Ergebnis war, dass lediglich 20% der Studierenden einen Antwortbrief verfasst hatten. Auf Nachfrage seitens des Dozierenden stellte sich heraus, dass viele mit einer so gestellten Aufgabe nichts anfan-
gen konnten. Daher ist es speziell in technischen Fächern sinnvoll, den Einsatz der Methode zu mo- tivieren. Ist den Studierenden der Sinn dieser Art Aufgabenstellung transparent, erhöht sich der Rücklauf beträchtlich.
Diejenigen Studierenden, die das Antwortschreiben verfasst hatten, haben sehr gut verständliche tech- nische Dokumente abgeliefert. Dabei wählten sie selbstständig und unabhängig voneinander unter- schiedliche Formate für das Antwortschreiben. Die einen antworteten mit einem kommentierten Excel- Sheet, die anderen mit Word-Dokumenten. Der Do- zierende hat auf die Antwortbriefe wieder per Brief individuell Feedback gegeben.
In der Reflexion der Methode mit den Studierenden stellte sich heraus, dass sie das Verfassen des Brie- fes schwierig fanden: Sie mussten
• einen technischen Text sauber formulieren und übersichtlich strukturieren,
• erkennen, wo sie noch Lücken hatten, sich die Terminologie nochmals aneignen,
• ohne direkte Kommunikation einen Sach- verhalt schildern und
• Empathie entwickeln für jemanden, der die gestellte Aufgabe nicht eigenständig lösen kann.
Positive Rückmeldungen seitens der Studierenden waren
• Sie verstehen das Thema jetzt, wo sie es je- mand anderem erklären mussten wesent- lich besser.
• Sie fanden das konstruktive Feedback des Dozierenden sehr hilfreich.
Das durchweg positive Feedback der Studierenden, die diese Aufgabe gelöst hatten ermutigt den Dozierenden, diese Methode zukünftig häufiger einzusetzen, damit die Studierenden mit dieser Art der Aufgabenstellung vertraut werden. Damit wird der Rücklauf bei der Methode sicherlich erhöht.
Eine spezielle Ausprägung der Briefmethode ist ein Online-Forum, das die Studierenden in Eigenini- tiative eingerichtet haben. Dort sind Studierende und Dozierende angemeldet. Studierende können hier Fragen, Anregungen oder Kritik jederzeit äußern. Speziell zu technischen Problemen kom- men häufig Fragen im Forum und werden oft von den Studierenden selbst beantwortet, so dass diese einiges an Erfahrung in technischer Dokumentation aufbauen. Allerdings ist der Schreibstil im Forum nicht immer technisch und formal korrekt, was auch nicht beabsichtigt ist. Auch Anrede und Grußformel fehlen. Allerdings kann durch den Einsatz von Emoticons eine Aussage unterstrichen und die Kommunikation aufgelockert werden. Die-
se Möglichkeit der Hilfe zur Selbsthilfe wird auch seitens der Dozierenden sehr begrüßt und unter- stützt: Auf Fragen wird geantwortet und Kritik und Anregungen zukünftig berücksichtigt.
Damit das Forum funktioniert und regelmäßig benutzt wird, ist es notwendig, dass die Dozieren- den regelmäßig und zeitnah antworten. Es wird seitens der Studierenden eine fast ständige Verfüg- barkeit erwartet, auch wenn das nicht direkt kom- muniziert wird. Außerdem muss gewährleistet werden, dass alle Studierenden Zugang zum Fo- rum erhalten. Das muss seitens des Dozierenden überprüft werden, um eine Gleichbehandlung der Studierenden zu gewährleisten, da über das Forum zusätzlich zur Vorlesung Informationen seitens der Dozierenden verteilt werden.
Diese Art Forum läuft schon seit mehreren Jahren und der rege Gebrauch seitens vieler Studierender zeigt, dass sich dieses Medium bewährt hat.
Eine Möglichkeit, die Briefmethode in größerem Rahmen einzusetzen, wäre die Erstellung eines Wiki zusammen mit den Studierenden. In diesem könnten Studierende die Sie interessierenden Themen für alle technisch dokumentieren.
Zusammenfassung und Ausblick
Planspiel und Briefmethode sind zwei konstrukti- vistische Methoden, die nach Meinung der Autoren sehr gut für die Ausbildung im Softwareenginee- ring geeignet sind. Die Lernenden lassen sich für das Planspiel einfacher motivieren als für die Brief- methode.
Planspiele im Software Engineering konfrontieren möglichst realistisch mit einer Praxissituation. Die Studierenden können dabei zum kreativen, weitge- hend autonomen und selbstorganisierten Handeln in Bezug auf konkrete Probleme und deren Lösung motiviert werden und nehmen dabei unterschied- liche Positionen in einem komplexen Softwareent- wicklungsprozess ein.
Die Briefmethode führt zu besserem Verfassen technischer Dokumentation und eignet sich sehr gut, um sich ein Thema anzueignen, oder zu wie- derholen. Auch der Spezialfall eines Forums für Studierende und Dozierende wird positiv aufge- nommen.
Die Reflexion der Studierenden über den eigenen Lernprozess kann zukünftig durch die Führung ei- nes individuellen Lernjournals unterstützt werden.
Die Dozierenden werden beide Methoden zukünf- tig häufiger einsetzen. Außerdem sind sie durch die gemachten Erfahrungen mit dem konstruktivis- tischen Methodenpool hoch motiviert, weitere Ver- suche mit diesen Methoden für die Software Engi- neering-Ausbildung durchzuführen.
Literatur
Aviram, A. (2000): Beyond Constructivism:
Autonomy-Oriented Education. Studies in Phi- losophy and Education, 19: 465-489., Kluwer Academic Publishers.
Dewey, J. (1910): How we think (deutsch: Wie wir denken, Zürich 1951).
Hagel, G., Mottok, J., Utesch, M., Landes, D., Studt, R. (2010): Software Engineering Lernen für die berufliche Praxis - Erfahrungen mit dem kon- struktivistischen Methodenbaukasten, im Ta- gungsband des Embedded Software Enginee- ring Kongress' 2010.
Ludewig, J. (2009): Erfahrungen bei der Lehre des Software Engineering, in Jaeger, U. (Hrsg.) und Schneider K. (Hrsg.): Softwareengineering im Unterricht der Hochschulen: SEUH 11, Hannover 2009, dpunkt Verlag.
Macke, G., Hanke, U., Viehmann, P. (2009): Hoch- schuldidaktik, Lehren, vortragen, prüfen, Beltz Verlag, Weinheim.
Markowitsch, J., Messerer, K., Prokopp, M. (2004):
Handbuch praxisorientierter Hochschul- bildung, WUV Universitätsverlag, Wien.
Mottok, J., Hagel, G., Utesch, M., Waldherr, F.
(2009): Konstruktivistische Didaktik - Ein Re- zept für eine bessere Softwareengineering Aus- bildung?, im Tagungsband des Embedded Software Engineeing Kongress' 2009, S. 601-610.
Reich, K. (2008): Konstruktivistische Didaktik – Lehr- und Studienbuch mit Methodenpool, 4.
Auflage, Beltz Verlag, url: http://
methodenpool.uni-koeln.de.
Schmidt, G., Hollweg, G. (2009): Ein integrativer interdisziplinärer Lehrversuch: Softwareengi- neering und Technisches Schreiben, in Jaeger, U. (Hrsg.) und Schneider K. (Hrsg.): Software- engineering im Unterricht der Hochschulen:
SEUH 11, Hannover 2009, dpunkt Verlag.
Service-Stelle Bologna (2004): Hochschulrektoren- konferenz - Texte und Hilfestellungen zur Um- setzung der Ziele des Bologna-Prozesses an deutschen Hochschulen, Beiträge zur Hoch- schulpolitik.
Siebert, H. (2009): Selbstgesteuertes Lernen und Lernberatung, ZIEL, Augsburg.
Welbers, U.; Gaus, O. (2009): The Shift from Teaching to Learning, Bertelsmann, Bielefeld.
Teamentwicklung in studentischen Projekten
Doris Schmedding, TU Dortmund Doris.schmedding@tu-dortmund.de
Zusammenfassung
Teamfähigkeit ist eine der Anforderungen an Soft- ware-Entwickler, die sehr häufig in Stellenanzeigen genannt wird. Unter Teamfähigkeit wird bei Wikipedia die Fähigkeit verstanden, mit anderen zusammen sozial zu agieren und sich und sein Können im Sinne einer Gruppenaufgabe optimal einzubringen.
Studentische Software-Entwicklungsprojekte bieten die Möglichkeit durch Learning-by-doing neben den technischen Fähigkeiten auch die Soft- skills der Studierenden auf dem Gebiet der Team- arbeit zu trainieren. Dieser Artikel stellt in einem Software-Praktikum erfolgreich erprobte Methoden vor, mit denen Lehrende ohne großen Aufwand die Teamentwicklung in studentischen Projekten un- terstützen und die Reflexion der Erfahrungen anlei- ten können, um daraus neue Impulse für eine bes- sere Zusammenarbeit zu gewinnen.
Einleitung
Das Software-Praktikum an der TU Dortmund (https://sopra.cs.tu-dortmund.de/wiki/) ist eine langjährig etablierte Lehrveranstaltung, die neben der Anwendung von Methoden und Verfahren aus der Software-Technik in Software-Entwicklungs- projekten darauf abzielt, die Teamfähigkeit der Studierenden zu verbessern. In Gruppen zu je 8 Studierenden werden unter Anleitung eines erfah- renen Tutors nacheinander zwei Software-Projekte durchgeführt. Gleichzeitig nehmen 5-12 Gruppen am Praktikum teil. Das Praktikum hat laut Prü- fungsordnung einen Umfang von 4 SWS. Konkret heißt das, dass sich eine Gruppe an zwei Terminen pro Woche im Seminarraum trifft, um am Projekt zu arbeiten. Daneben arbeiten die Studieren auch zuhause oder im Rechnerpool an der Universität an dem Projekt.
In einem Projekt sind technische, fachliche, or- ganisatorische und soziale Probleme zu lösen. Pro- jekte scheitern weniger an mangelndem techni- schen oder fachlichem Wissen, vielmehr stellt die Lösung von organisatorischen und sozialen Prob- lemen eine größere Herausforderung dar (Fleisch- mann u.a., 2005). Da ich diese Beobachtung aus
eigener Erfahrung nur bestätigen kann, möchte ich die Studierenden ebenso, wie wir die Einarbeitung in bis dahin noch unbekannte Werkzeuge wie SVN oder einen GUI-Builder durch speziell vorbereitete Tutorials unterstützen, auch auf die bis dahin noch unbekannte Arbeit in einem Projektteam vorberei- ten. Für das Lernen ist es wichtig, die eigenen Er- fahrungen mit den neuen Arbeitstechniken zu re- flektieren und bei Bedarf die Vorgehensweisen zu verändern. Nur so lassen sich aus den Erfahrungen im ersten Projekt Konsequenzen für das zweite Projekt ziehen. In (Lewerentz u. Rust, 2001) wird ausführlich auf die Bedeutung der Reflexion der Erfahrungen in der Projektarbeit eingegangen. Den Vorschlag der Autoren, neben einem gemeinsamen Reflexionsbericht zusätzlich am Ende jedes Teilpro- jekts persönliche Reflexionsberichte von allen Stu- dierenden einzufordern, halte ich für wenig prakti- kabel. Zumindest Dortmunder Informatik- Studierende möchten lieber Java-Code als Selbstre- flexionen schreiben.
In diesem Artikel gebe ich zunächst eine Ein- führung in die Teamentwicklung. Dann stelle ich zwei Beispiele für Übungen zur Teambildung vor, mit denen ohne großen Aufwand die Teambildung unterstützt werden kann. Zu einer derartigen Übung gehört auch die Reflexion der Erfahrungen.
Das Thema Reflexion wird vertieft, indem eine Methode vorgestellt wird, die zur Halbzeit des Praktikums eingesetzt wird.
Teamentwicklung
Ein Team unterscheidet sich von einer Gruppe durch die Tatsache, dass die Mitglieder eines Teams gemeinsam eine Aufgabe lösen und/oder ein gemeinsames Ziel verfolgen. In diesem Sinne können wir also bei einem studentischen Software- Entwicklungsprojekt mit mehreren Studierenden von einem Team ausgehen.
Die Entwicklung von einer zufällig zusammen- gestellten Gruppe von Studierenden mit heteroge- nem Vorwissen zu einem gut funktionierenden Team läuft in einer Abfolge von Phasen ab (siehe Abb. 1), die in der Literatur in Anlehnung an die Teamuhr von Tuckman (Tuckman, 1965) gerne mit
