Veröffentlicht: von

Als Abschluss der Veranstaltung Anforderungsmanagement (SS18) ist das Lastenheft „Digitale Unterstützungssysteme für Angehörige und Pflegekräfte in der Lebenswirklichkeit von demenziell veränderten Personen“ verfügbar:

AM_DUAL_Anonym

Es handelt sich um die veröffentlichungsfähige Version; hier sind sämtliche Namen und Kontaktdaten von Stakeholdern und Interviewpartnern aus datenschutzrechtlichen Gründen entfernt. (Wenn Sie die Version mit allen Kontaktdaten benötigen und dafür ein begründetes Interesse haben, wenden Sie sich bitte per Email an mich.)

Auf Basis dieses Lastenhefts wird im nächsten Schritt in der Lehrveranstaltung Fachspezifischer Architekturentwurf (FAE) im WS18/19 eine Architekturspezifikation mit Proof-ofConcept erstellt.

Veröffentlicht: von

Häufig bekomme ich die Frage, wie der Bericht zu einem (von mir betreuten) Praxisprojekt (PP) im AI-, MI- oder WI-Bachelor aussehen sollte. Deshalb dazu ein paar Gedanken und Hilfestellungen. Disclaimer: Der nachfolgende Text gibt lediglich meine persönliche Meinung wieder und stellt keine rechtsverbindliche Grundlage einer Bewertung dar.

Das Modulhandbuch Informatik Bachelor (Stand: 31.08.2013) sagt zum Praxisprojekt: „Die Studierenden sollen lernen, Methoden und Techniken, die sie im Studium erlernt haben, in einem realitätsnahen Projekt weitgehend selbstständig anzuwenden“. Inhalt ist die „Anwendung von Modulinhalten des ersten bis fünften Semesters anhand von realen Anforderungen in einem praxisrelevanten Kontext“ (Hervorhebungen alle von mir).

Die Forderung der Realitätsnähe und Praxisrelevanz bedeuten, dass das PP die Gelegenheit eröffnet, sich ein komplexes Themenfeld systematisch zu erschließen. Das gilt insbesondere, wenn es die Vorbereitung auf eine thematisch darauf aufbauende Bachelorarbeit (BA) darstellt. Ein PP beginnt man also selten mit einer ganz klar definierten Themenstellung. Vielmehr arbeitet man oft explorativ („mal nach links, mal nach rechts schauend“) und sucht nach Übersicht sowie nach den Aspekten, die für die BA relevant sein können.

Die BA hat eine klar dokumentierte und kontrollierte Dauer; hier ist eine fokussierte Themenstellung essentiell. Das PP sorgt (im Idealfall) dafür, dass diese fokussierte Themenstellung entstehen kann. Inhalt eines PP kann daher beispielsweise sein:

  • Recherche eines komplexen Themenfeldes, um Forschungsfrage und –Design der BA sauber definieren zu können,
  • einen Proof-of-Concept für einen Problemlösungsansatz, der in der BA dann vertieft betrachtet und ausgearbeitet wird,
  • Spezifikation und Implementation eines Basisfunktionalität / Plattform / Library / …, die für die zeitlich begrenzte Arbeit an der BA gebraucht wird,

Beim PP zählt weniger die Dauer, sondern die die Menge an investierter Arbeit, die den 15 CP (= 450 Arbeitsstunden, = ca. 2-3 Monate Vollzeit-Arbeit) entspricht.

Wie sollte jetzt eine gute PP-Dokumentation aussehen?

  • Sie sollte eine Arbeit von 450h angemessen dokumentieren, d.h. so viel inhaltliche Tiefe aufweisen, dass sich die Menge der investierten Arbeit wiederspiegelt.
  • Das ist nur schwer in Seitenzahlen zu übersetzen. Ich kann mir kaum vorstellen, dass man obige Forderung in nur 10 Seiten erreicht. Andererseits können 25 Seiten mit gut geschriebenem, kompakten Text einen hervorragenden Überblick geben, während 80 Seiten Blähtext überhaupt nichts aussagen. Lassen Sie also bitte Ihre eigene Intuition entscheiden, oder – fragen Sie mich einfach im konkreten Fall.
  • Die PP-Dokumentation folgt den denselben strengen Anforderungen an wissenschaftliches Arbeiten – sinnvolle Auswahl der Quellen, keine Wikipedia-Referenzen, Zitate kennzeichnen, etc.
  • Die Gliederung einer PP-Dokumentation ist oft allerdings weniger „geschlossen“ als die einer BA. Sie kann durchaus einen etwas episodischen Charakter haben. Schließlich geht es darum, die geleistete Arbeit zu dokumentieren. Dazu gehören auch auch Teilergebnisse, die dann nicht mehr weiterverfolgt wurden.

Noch eine (für mich) sehr wichtige Anforderung zum Schluss: Der PP-Bericht ist ein eigenständiges Dokument. Sie können (und sollten!) es in der BA als Quelle referenzieren. Ein wortwörtliches Kopieren von Textteilen aus dem PP-Bericht in die BA ist ein (Selbst-)Plagiat, und gehört damit zu den schlimmeren Sünden des Wisssenschaftsbetriebs.

Veröffentlicht: von

Drei Studierende eines Informatikprojekts, das ich betreue, untersuchen im Moment die (subjektive) Eignung von Programmiersprachen. Sie würden diese Arbeit sehr unterstützen, wenn Sie folgende kurze Umfrage ausfüllen (auch wenn Sie noch nicht viel Programmiererfahrung haben sollten – die Umfrage bezieht ausdrücklich auch Studierende mit ein):

https://docs.google.com/forms/d/e/1FAIpQLSerwhgBLaGm8IOdQNw4w9B_lsEJuqfesZBKDxoEdeLIQS2Mmg/viewform?usp=sf_link

Veröffentlicht: von

Problembeschreibung

Machine Learning und Deep Learning haben sich in den letzten Jahren rasant entwickelt. Insbesondere im Bereich der natürlichen Sprachverarbeitung (Natural Language Processing, NLP) sind ChatBots konkrete Anwendungsbeispiele dieser Technologien. Sie bilden für den Menschen erlebbare Schnittstellen, um direkt mit „der Maschine“ zu kommunizieren.

In der Zurich Gruppe Deutschland wird derzeit schon an einem ChatBot für Schadenmeldungen geforscht. Dieser nutzt ML Methoden des NLP, um die Klassifizierung des Gesagten vorzunehmen und Entitäten aus dem Text zu extrahieren. Der Nutzer wird dann abhängig von dem so gebildeten Kontext intelligent durch einen Entscheidungsbaum geführt. Zurzeit wird hierzu eine kommerzielle Software genutzt.

Die Nutzung eines Entscheidungsbaums in Kombination mit einem Kontext ermöglicht die Entwicklung von komplexen und genau definierten State Machines. Und genau das ist die Herausforderung dabei: Kleine Änderung in der Abfragelogik ziehen z.T. umfassende Änderungen in der gesamten Entscheidungslogik mit sich. Die Skalierung eines solchen Vorhabens ist kaum möglich, da es schwierig (unmöglich) ist, alle möglichen Konversationen explizit zu modellieren.

Projektdefinition

Eine mögliche Lösung dieses Problems besteht darin, ein probabilistisches Modell basierend auf historischen Konversationen zu entwickeln. Dies beruht auf der Idee, dass es einfach ist, innerhalb einer Konversation zu spezifizieren, ob eine Antwort richtig oder falsch ist. Ein solches Modell kann mit Hilfe von Supervised, Reinforcement oder Interactive Learning Methoden entwickelt werden.

Die Projektarbeit gliedert sich in zwei Ziele:

  1. Eine Weiterentwicklung der aktuellen State Machine in ein probabilistisches Modell mit Hilfe des Open Source Stacks ai. Dazu zählen u.a. die Überführung der (aktuell in der kommerziellen Software erstellten) „Dialogflows“ nach Rasa.
  2. Die Entwicklung einer Zielarchitektur zur Einbindung des ChatBots in die bestehende Systemlandschaft einer großen Versicherung. Eingehende Chats sollen von verschiedenen Endpoints möglich sein (z.B. FB, Webchat, Alexa, Telegram,…). Die Einbindung ermöglicht eine Integration bestehender Backendsystem, wie z.B. Kundendatenbanken, ausgehend von einer lokal integrierten Cloud Server Architektur.Weiterhin soll die Zukunftsfähigkeit der Plattform sichergestellt werden um weitere Use Cases, wie z.B. die Klassifizierung von Emails oder transkribierter (oder text-to-speech) Telefonate mittels der Rasa NLP Engine zu realisieren.

Projektform

Der Projektpartner Zurich wird das Projekt sehr aktiv begleiten und bei der Einarbeitung in Konzepte und Technologien unterstützen.

  • Ein Zurich-Mitarbeiter mit Projektvorwissen wird dauerhaft im Team mit coden.
  • Der Sponsor (Jeronim Morina, https://www.linkedin.com/in/jeronim-morina/) wird in der „heißen“ Projektphase ca. 1d / Woche für das Projekt.

Das Projekt wird in agilen Sprints durchgeführt. Die Scrum-Master-Rolle wird von einem TH-Köln-Betreuer eingenommen, der Product Owner wird J. Morina sein.

Aufgrund dieser schon sehr konkreten Planung und gewisser organisatorischer Bedingungen auf Seiten der Zurich sind für das Projekt zeitliche Rahmenbedingungen gesetzt, die leider nicht veränderlich sind.

  • Das Projekt beginnt am Mo 3.9.
  • In der Zeit von 3.9. bis 10.10. (6 Wochen) sind jede Woche die Tage Mo, Di und Mi als Vor-Ort-Arbeitstage zu reservieren.
  • Danach wird es noch einen Produktifizierungs- und Finalisierungs-Sprint geben, der zeitlich noch nicht fixiert ist; es kann aber davon ausgegangen werden, dass das Projekt früh endet.

Wer diese Randbedingungen nicht einhalten kann, kann an dem Projekt leider nicht teilnehmen.

Learning Outcomes

  • Kenntnisse in Machine Learning, NLP und ChatBots
  • Praktische Erfahrungen in Cutting Edge Software Development / Architecture
  • Arbeiten im agilen Team

Voraussetzungen

  • Python
    • Aus der Dokumentation von rasa.ai (https://core.rasa.com/motivation.html):
      • Why python? Because of its ecosystem of machine learning tools. Head over to But I don’t code in python! for details.
      • Is this only for ML experts? You can use Rasa if you don’t know anything about machine learning, but if you do it’s easy to experiment.
      • How much training data do I need? You can bootstrap from zero training data by using interactive learning. Try the tutorials!
    • Kenntnisse moderner Softwaretechnologien wie z.B. Web-Services
    • Bereitschaft, sich in Konzepte der AI und des NLP einzuarbeiten
    • Bereitschaft, agil und teilweise im Blockformat zu arbeiten

Externe Projektpartner

Zurich Gruppe Deutschland

Veröffentlicht: von

Problembeschreibung

Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabhängigen vertikalen Modulen aufzubauen. Diese können (weitgehend) unabhängig voneinander deployed und betrieben werden und benötigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt über leichtgewichtige Protokolle wie etwa REST.

Dieser Architekturstil erlaubt es, ganze Anwendungslandschaften nach Geschäftsfähigkeiten zu segmentieren. Die resultierenden Teilfunktionalitäten können dann in Form von Microservices implementiert und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können.

Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von Räumen, Praktika, Veranstaltungen, Projekten, Prüfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.

Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gewähren, wäre ein Architektur-Blueprint für Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine große Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.

Projektbeschreibung

Ziel des Projekts ist es, für die Applikationslandschaft „Campus Gummersbach“ einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.

Dieses Konzept soll am Beispiel der Projektbörse Campus GM pilotiert und iterativ-inkrementell erarbeitet werden.

In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierfür eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Im SS 18 wurde in einem Guided Project mit der eigentlichen Implementierung der Projektbörse begonnen, erste Microservices wurden umgesetzt und nötige Infrastruktur geschaffen.

Die Teams des folgenden Guided Projects übernehmen die Verantwortung für einzelne (bereits bestehende) Microservices und kümmern sich sowohl um Weiterentwicklung/Betrieb der Services als auch der Entwicklungs- und Ausführungsinfrastruktur. Je nach Bedarf werden neue Microservices entwickelt, Umsysteme eingebunden und die Infrastruktur verfeinert. Die entwickelten Microservices basieren dabei auf dem Spring Boot Framework (Java).

Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu verfeinern, zu validieren und offene Fragen zu identifizieren.

Projektmethodik

Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die Teams werden hierbei durch wissenschaftliche Mitarbeiter in der Rolle des Scrum Masters betreut. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.

Learning Outcomes

  • Praxiserfahrung mit Microservice-Architekturen
  • Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
  • Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
  • Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
  • Expertise in Kommunikation und Dokumentation
  • Teamwork- und Projektmanagement-Erfahrung

Voraussetzungen

  • Programmierkenntnisse
  • Grundkenntnisse Linux
  • Interesse an professioneller Software-Entwicklung
  • Interesse an der Softwarearchitektur
  • Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
  • Bereitschaft sich eigenständig in neue Frameworks, Tools und Konzepte einzuarbeiten
  • Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
  • Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen

Externe Projektpartner

Veröffentlicht: von

Bei der Veranstaltung DiTeS Open 2018 habe ich in einem Vortrag den aktuellen Stand des Lehr-/Forschungsprojekts DUAL vorgestellt. Die Vortragsfolien finden Sie hier.

Auf der Veranstaltung wurde auch das obige Poster zu DUAL und seiner Verzahnung mit dem Vorgehensmodell der Lehrveranstaltung Anforderungsmanagement (AM) im Informatik Master gezeigt.