Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

de:mobil_in_der_stadt:dokusemester2

Mobil in der Stadt oder Barrierefreiheit messen!

Von der Evolution eines Semesterprojektes

Spätestens zum Ende des ersten Semesters war es klar, dass die Idee des Messens von Barrierefreiheit in einer eher generischen Form mit solch einem Aufwand verbunden sein dürfte, der den Rahmen der vorliegenden Semesterarbeit sprengen würde. Die Aufgabe liegt also eigentlich eher darin, die Idee des Messens von Barrierefreiheit konzeptionell zu erfassen und entsprechende Ideen zu entwickeln, wissend, dass das Stadium der Idee nicht unbedingt verlassen werden kann. Die verschiedenen Ansätze, die von uns im zweiten Semester untersucht wurden, DXF-Format, Plug-In-Entwicklung für CAD-Zeichnung, Diskussionen zur Spracherkennung, führten zu der Erkenntnis, dass eine generische Lösung der Problemstellung nur durch „intelligente“ Systeme zu erzielen ist. Da sich sowohl auf Seiten der Normen als auch auf der der Dateiformate permanent Änderungen ergeben, ist auch eine permanente Anpassung der Systeme erforderlich.

Vorgehensmodell

Wir haben uns entschlossen, in der Projektbearbeitung nach dem Scrum-Vorgehensmodell zu arbeiten. In einem Produkt-Backlog sind alle bekannten Anforderungen an das zu erstellende System hinterlegt. Dieses Backlog pflegt der Product-Owner. Der Product-Owner stellt die Schnittstelle zum Kunden dar. In einem von den Teammitgliedern gemeinsam festgelegten Sprint-Backlog werden die innerhalb einer Sprintplanung festgelegten Aufgaben für einen definierten Zeitraum, den Sprint, festgehalten. Bei dem Scrum-Vorgehensmodell ist ein Daily-Scrum vorgesehen. Hierbei treffen sich alle Teammitglieder und berichten kurz über die aktuelle Tätigkeit, deren Abarbeitungsstand und eventuell Besonderheiten/Probleme. Innerhalb eines Sprints sollen keinerlei neue Anforderungen oder andere Störungen zum Team durchdringen. Innerhalb eines Sprints gibt es also idealerweise keinerlei Änderungen am Backlog. Nach Ablauf eines Sprints wird dem Product-Owner das entsprechende Ergebnis präsentiert. Es gibt entweder eine Abnahme oder eine Abnahmeverweigerung für das Sprint-Ergebnis. Danach beginnt die Erstellung eines neuen Sprints mit entsprechendem Sprint-Backlog. Zu diesem Zeitpunkt könnten Änderungen eingebracht werden. In regelmäßigen Abständen finden Sprint-Retrospektiven statt, um die Vorgehensweisen und Umstände kritisch zu würdigen. Eine weitere Rolle in dem Modell ist die des Scrum-Masters. Er hat keine direkte Weisungsbefugnis auf die Teammitglieder. Er soll das Team unterstützen, Problem erkennen und beseitigen, moderieren. Bei dem Scrum-Modell handelt es sich um Vorgehensmodell der agilen Softwareentwicklung. Es ist flexibel in Bezug auf Änderungen der Anforderungen und kann durch die häufige Eigenkontrolle Fehlentwicklungen vorbeugen. [GlBo09] Wir haben zu Beginn des Semesters mit Hilfe des Scrum-Servers der FH Anforderungen definiert und versucht in entsprechende Sprints umzusetzen. Das „daily-scrum“ fand wöchentlich statt. Zu Beginn wurden auch entsprechende Einträge auf der Scrum-Plattform gepflegt. Auf Grund der Kürze des Semesters und der teilweise länger dauernden Aufgaben schien die Verwendung der Plattform jedoch als etwas aufwendig bzw. weniger sinnvoll, da immer dieselben Eintragungen vorgenommen werden mussten. Das führte dazu, dass das Modell nicht mit voller Konsequenz angewendet wurde. Zum Teil ist das natürlich auch dem fehlenden Rahmen geschuldet. So müssen Funktionen wie die des Product-Owners von dem gesamten Team übernommen werden, und andere nach dem Modell essentielle, wie die des Scrum-Masters komplett entfallen. Zudem wäre eine der wichtigsten Komponenten, der Daily-Scrum, unter den gegebenen Umständen nur mit sehr hohem Aufwand umzusetzen. Der Daily-Scrum wurde so zum Weekly-Scrum, auch wenn dadurch der gewünschte Verbesserungseffekt der der Gruppenarbeit und deren Zusammengehörigkeitsgefühl womöglich leidet.

Bearbeitete Themen

Die in den Anforderungen genannten Aufgaben wurden von den Teammitgliedern bearbeitet. Zu den Themen wurden entsprechende Dokumentationen erstellt:

Schnittstelle zwischen DIN-Normen und Gebäudeplänen
Entwurf 3D-Modell
DXF-Formate
AutoCad-Plugin/ObjectARX
3D-Laserscanner
Punktwolken
Abschlusspräsentation Semester 2

Besuch bei der Behindertenbeauftragten der Stadt Frankfurt

Gemeinsam fand ein Besuch bei der Behindertenbeauftragten der Stadt Frankfurt, Frau Schlegel, statt. Es wurde gemeinsam festgestellt, dass eine mehr oder weniger automatisierte Prüfung von Plänen und Baustellen sehr sinnvoll sein kann und entsprechenden Arbeitsaufwand einsparen hilft, der durch die Prüfung durch einen Sachverständigen anfällt. Eine solche automatisierte Prüfung, die durch unsere Gruppe skizziert wurde (siehe auch Dokumentation Semester 1), kann aber lt. Frau Schlegel die Überprüfung durch eine Sachverständige nicht ganz ersetzen. Auch Lösungen, die nach den geltenden Vorschriften akzeptabel sind, können aus gestalterischen und/oder Gründen der Achtung vor den Menschen nicht annehmbar sein. Das klassische Beispiel hierzu ist der behindertengerechte Eingang im Hinterhof neben den Müllbehältern. Die automatisierte Prüfung könnte aber helfen, im Vorfeld schon grundlegende Probleme zu erkennen und auch Defizite des Prüfers im Hinblick auf sich laufend ändernde Normen und Vorschriften zu beheben. Solche Defizite können selbstverständlich immer auftreten, z.B. bei kleineren Verwaltungseinheiten: Von besonderem Interesse sind Außenräume wie z.B. Bushaltestellen, Bahnsteige, Ampelquerungen und Zugänge zu Gebäuden. Zu prüfende Pläne werden häufig als PDF-Dateien eingereicht, wobei der Auftraggeber gegebenenfalls auch alternative (Austausch-)Formate wie z.B. DXF verlangen könnte.

Besuch MdB. Müntefering

Im Rahmen des Besuchs von Herrn Müntefering an der FH Frankfurt wurde von zwei Teammitgliedern das Konzept des „Barrierefreiheit Messen“ vorgestellt. Zu der Veranstaltung wurden die verschiedenen Fachbereiche, die sich mit Fragen des Alterns und von Behinderungen intensiv beschäftigen, umfassend vorgestellt. Es ergaben sich lebhafte und fruchtbare Diskussionen, wobei zum Teil auf die einzelnen Vorträge nicht im Speziellen eingegangen werden konnte. Da es sich bei unserem Projekt um eine eher konzeptionelle Arbeit handelt, die noch keine spektakulären Ergebnisse vorzuweisen hätte, wurden die vorgestellten Ideen denn auch eher im Lichte von vorgestellten architektonischen Lösungen im Zusammenhang mit Barrierefreiheit/Inklusion mitbetrachtet als Möglichkeit zur effizienteren Bearbeitung.

Besuch Konferenz Technik und „Emotionale Robotik“ im Alter an der FH Frankfurt aus der Vortragsreihe Alternsforschung in Frankfurt

Da unsere Zielvorstellung ein System für Fachleute ist, und in diesem Zusammenhang später einmal die Frage nach der Mensch-Maschine-Interaktion unter Berücksichtigung von Emotionen eine Rolle spielen könnte, besuchten zwei Teammitglieder den Fachvortrag. Die Beiträge handelten aber alle von der Rolle der Emotionen im Umgang mit Älteren, Betroffenen im Sinne von Erkrankten und Pflegebedürftigen. So war der Besuch interessant und informativ, brachte aber im Zusammenhang mit dem Projekt keine nennenswerten Erkenntnisse.

Treffen mit Herrn Mehler von der Goethe Universität Frankfurt

Inhalt des Gespräches war eine erste Einschätzung der Möglichkeiten des an der FH Frankfurt entwickelten Agenten für den Einsatz zum Spracherwerb von Künstlichen Intelligenten Systemen. Nach Vorstellung des Agenten durch Herrn Abrami fand eine eher allgemeine Diskussion zum Thema Spracherwerb von Agenten in einer Simulationsumgebung statt. Wie können die Agenten ihre Umwelt erkunden? Wie kann eine Kommunikation zwischen den Agenten erfolgen? Welche Art von Interaktion zwischen den Agenten ist hierzu erforderlich? Da in der Simulation Entscheidungen nach abstrakten Mustern vorgenommen werden, ist für den Bezug zu einer Simulation oder einer anderen „realen“ Welt ein Mapping zwischen den Agenten und der Welt erforderlich. An dieser Stelle taucht das Problem des Symbolic Groundings auf, also wie die Begriffe in der Welt, natürlich oder als Simulation, ihre „wirkliche“ Bedeutung erhalten. Da in einer Welt von Agenten nur symbolische Repräsentationen und ihre formale Behandlung unabhängig von ihrer „Bedeutung“ möglich sind, besteht das Problem, die Simulaton mit der Welt in diesem Bedeutungssinne zu verknüpfen. Die Agenten in einem künstlichen System haben keinen Begriff von der Bedeutung der Worte oder Symbole, die ihnen zur Verarbeitung vorgelegt werden. Weitere Schritte wären die Prinzipien der Kompositionalität und das Kontextualität, nach dem die Bedeutung von Sätzen entsteht aus dem Gebrauch von Wörtern in einer absichtsvollen Aneinanderreihung und Zusammensetzung, zu berücksichtigen. [WWWS11] Da, wie bereits mehrfach angedeutet, eine solche Arbeit den Rahmen der uns für das Projekt zur Verfügung stehenden Zeit sprengt, nehmen wir von der expliziten Bearbeitung dieses Bereiches Abstand. Es sei jedoch angemerkt, dass die FH Frankfurt und die Goethe Universität Frankfurt eine dauerhafte Zusammenarbeit auf diesem Gebiet vereinbart haben und Studenten und Absolventen des BASYS/AIIPS-Studienganges in diesem Projekt aktiv mitarbeiten. Es sollen monatliche Projekttreffen stattfinden.


Dokumentation unseren Arbeiten

—-

Quellen [WWWS11] http://plato.stanford.edu/entries/compositionality/ abgerufen am 05.07.2011

[GlBo09] Gloger, Boris (2009): Scrum. Produkte zuverlässig und schnell entwickeln. 2nd ed. München: Hanser.

de/mobil_in_der_stadt/dokusemester2.txt · Zuletzt geändert: 2014/11/24 13:20 (Externe Bearbeitung)