Auflistung nach Autor:in "Schmedding, Doris"
1 - 6 von 6
Treffer pro Seite
Sortieroptionen
- KonferenzbeitragAgile Vorgehensweisen in Ausbildungsprojekten(INFORMATIK 2013 – Informatik angepasst an Mensch, Organisation und Umwelt, 2013) Schmedding, DorisAls agile Vorgehensweisen noch ziemlich neu und besonders spannend waren, haben wir damit auch in der Ausbildung experimentiert. Aus meinen Beobachtungen und dem Erfahrungsaustausch mit agil arbeitenden EntwicklerInnenn schließe ich, dass ein agiler Entwicklungsprozess für ein Ausbildungsprojekt mit Anfängern ungeeignet ist. Meine Gründe dafür möchte ich gerne darlegen. Unsere Studienordnung sieht im 3. Semester die Lehrveranstaltung Software-Praktikum vor, in der die Informatik-Studierenden in Teams zu Acht erste Software-Entwicklungs- projekte durchführen. Die Studierenden verfügen dann schon über erste Programmier- und UML-Kenntnisse aus vorangehenden Veranstaltungen. Das Hauptziel des Software- Praktikums ist die Vermittlung von erfahrungsbasiertem Wissen über Vorgehensweisen in Projekten. Obwohl Ausbildungsprojekte die Realität simulieren, sollte allen Beteiligten immer klar sein, dass nicht das Produkt sondern das Lernen von Methoden und Verfahren im Vordergrund steht. Nach meiner Beobachtung sind die Studierenden im Projekt hoch motiviert, vergessen aber manchmal, dass es nicht wirklich um das Produkt geht. Die Lehrenden sollten außerhalb des Entwicklungsprozesses stehen. Da sie die Verantwortung für die Lernprozesse der studentischen Projektmitglieder tragen, müssen sie beobachten und die Fortschritte der Lernenden begleiten, nur dann in Projektentscheidungen des Teams eingreifen, wenn diese den Lernzielen entgegenstehen, z.B. wenn ein Teammitglied sich nur damit beschäftigt, bunte Bildchen zum Schmücken des Produkts zu gestalten. Jedes Teammitglied muss sich m.E. aus Ausbildungszwecken an allen anfallenden Tätigkeiten beteiligen. Effizienz sollte nur eine untergeordnete Rolle spielen. Wenn ein Ausbildungsprojekt auf die Vermittlung von Methodenwissen ausgerichtet ist, muss sein Ergebnis nicht die Qualität eines an Kunden auslieferbaren Produkts haben. Hiermit meine ich nicht unzureichende Tests sondern Details in der Aufgabenstellung, die in der Realität wichtig sind, für die Ausbildung aber keinen zusätzlichen Nutzen bringen. Studentische Projekte dürfen auch mal scheitern, wenn in der anschließenden Reflexion die Gründe für alle deutlich herausgearbeitet werden. Agile Vorgehensweisen sind iterativ und inkrementell. Der Kunde und seine Bedürfnisse sind Teil des Prozesses. Die Anforderungen werden als Stories skizziert und ihr Aufwand geschätzt. Die Vorgehensweise ist produktgetrieben, effizient und gekennzeichnet von einer hohen Dynamik. Lange Meetings und umfangreiche Dokumentation werden vermieden. Unsere Studierenden haben wenig Erfahrung in der Programmierung und normalerweise keine in Ablauf, Organisation und Zusammenarbeit in Software-Entwicklungsprojekten. Das macht für sie das Schätzen ihrer eigenen Effizienz und des Aufwands für eine Story sehr schwierig. Erfahrung brauchen sie auch zur Festlegung der Anforderungen, die den funktionalen Kern des Produkts ausmachen und deshalb zuerst entwickelt werden sollen. Ein Scrum-Prozess mit den Rollen Product Owner, Scrum-Master, Kunde, Benutzer, Management und Entwicklungsteam lässt sich nur schwer in ein Ausbildungsprojekt transferieren. Wenn die Studierenden das Entwicklungsteam bilden, sollen dann die Lehrenden die restlichen Rollen ausfüllen? Diese Rollen wurden in den Prozess integriert, weil sie Ziele wirtschaftlicher Art oder produktorientierte Ziele verfolgen. Diese Ziele sind nicht unbedingt mit den Ausbildungszielen vereinbar. Der Scrum-Prozess setzt sich aus Sprints von 2-4 Wochen zusammen. Ein realitätsnahes Ausbildungsprojekt sollte schon mehrere Sprints umfassen, damit Sprint Review und Retrospektive ihren Sinn machen und das Schätzen geübt wird. In den Semesterablauf mit konkurrierenden Lehrveranstaltungen lässt sich m.E. ein Scrum-Projekt nur schwer integrieren. Auch wenn ein agiles Projekt in den Ferien als Blockveranstaltung (bei uns 6 Wochen) machbar wäre, bleibt das Problem, dass es dann relativ klein sein muss. Da ein agiler Prozess auf Effizienz ausgerichtet ist, werden Meetings und Dokumentation möglichst kurz gehalten. Für ein Unterrichtsgespräch sollten sich alle Beteiligten ausreichend Zeit nehmen, um bei Entscheidungen das Für-und-Wider ausgiebig zu diskutieren und um Wissenslücken zu schließen. Ausführliche Dokumentation hilft Lehrenden bei der Kontrolle des Lernfortschritts. Zusammenfassend stelle ich fest, dass agile Prozesse nur von erfahrenen Entwicklern beherrschbar sind, da sie durch ihre starke Produktgetriebenheit leicht ins Chaos abdriften können. Deshalb sind sie bestenfalls für fortgeschrittene Studierende geeignet. Die Abbildung von agilen Entwicklungsprozessen auf Ausbildungsprojekte ist wegen unter- schiedlicher Rollen und Ziele schwierig. Agile Methoden wie Retrospektive, Paararbeit und Unit-Tests lassen sich aber durchaus auch sinnvoll in nicht agile Ausbildungsprojekte integrieren.
- KonferenzbeitragEffekte von Paararbeit(Software Engineering 2006, Proceedings der Fachtagung des GI-Fachbereichs Softwaretechnik, 2006) Bipp, Tanja; Lepper, Andreas; Schmedding, DorisWir berichten über eine umfangreiche Studie zur Paararbeit in Software- Entwicklungspraktika an der Universität Dortmund. An unserer Studie haben 13 Software-Entwicklungsteams mit insgesamt etwa hundert Studierenden teilgenommen, von denen die Hälfte ihre Projekte in Paararbeit durchgeführt hat. Die Paararbeitsgruppen haben in der gleichen Zeit nur geringfügig weniger Code produziert als die Nicht-Paararbeitsgruppen, obwohl sie an nur halb so vielen Rechnern gearbeitet haben. Dabei war der erstellte Code besser verständlich und leichter lesbar, was die Fehlersuche und die Wartung erleichtert.
- KonferenzbeitragExperimente mit XP in der Lehre(Informatik 2004, Informatik verbindet, Band 2, Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 2004) Beckmann, Ingrid; Schmedding, Doris
- KonferenzbeitragDer Unified Process im Grundstudium - Didaktische Konzeption, von Lernmodulen und Erfahrungen(DeLFI 2004: Die 2. e-Learning Fachtagung Informatik, Tagung der Fachgruppe e-Learning der Gesellschaft für Informatik e.V. (GI) 6.-8. September 2004 in Paderborn, 2004) Kopka, Corina; Schmedding, Doris; Schröder, JensEin umfassendes, lehrveranstaltungsübergreifendes didaktisches Konzept zur Vermittlung eines komplexen Lehrinhalts aus der Softwaretechnik, dem Unified Process, wird vorgestellt. Dazu werden im Grundstudium die traditionellen universitären Lehrveranstaltungen wie Vorlesung, Übung und Praktikum mit Mitteln des eLearnings wie multimediale Lehrbücher und Werkzeuge unterstützt. Dass Vorgehen wird zusammen mit dem Hochschuldidaktischen Zentrum der Universität Dortmund evaluiert.
- ZeitschriftenartikelUnified Process versus Extreme Programming – Erfahrungen mit den Extrema(Vol. 32, Vorgehensmodelle in der Softwareentwicklung – Regulation, Agilität, Best Practice, 2007) Schmedding, DorisDurch das Experimentieren mit sehr unterschiedlichen Vorgehensmodellen, wie sie die Softwareentwicklung nach dem Unified Process und das Extreme Programming darstellen, konnten wir interessante Erfahrungen in der Lehre gewinnen, die wir hier zusammenstellen.
- KonferenzbeitragVom Clean Model zum Clean Code(Modellierung 2016, 2016) Vasileva, Anna; Schmedding, DorisIn diesem Beitrag wird der Zusammenhang zwischen Code-Qualität und UML- Modellen in einem Software-Entwicklungsprozess in der Informatik-Ausbildung vorgestellt. Es wird untersucht, welche der im Code sichtbar werdenden Mängel bereits im Modell erkannt werden können. Werkzeuge zur statischen Code-Analyse und Refactoring-Techniken unterstützen die Studierenden beim Entdecken und Beseitigen der Qualitätsmängel im Programm-Code. Eine Analyse der studentischen Projekte hat gezeigt, dass sich manche Code-Mängel im Nachhinein nur schwer beseitigen lassen. Aus diesem Grund müssen Qualitätsaspekte bereits beim Modellieren in Betracht gezogen werden. Frühzeitig erkannte Mängel lassen sich mit geringeren Kosten beseitigen als spät erkannte Defekte.