Child pages
  • Guided Project SS21_B04 - EVATool: Entwicklung eines Ethical Value Assessment Tools mit DDD und moderner UX

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Current »

Guided Project SS21_B04 - EVATool: Entwicklung eines Ethical Value Assessment Tools mit DDD und moderner UX

Diese Seite beschreibt alle Rahmenbedingungen des Projekts SS21_B04. Bitte bookmarken Sie als Teilnehmer die Seite, sie wird laufend aktualisiert. 

Current News on the GP

Erstes Review und Planning für das GP heute (19.3.), ausnahmesweise um 9:30

https://th-koeln.zoom.us/j/4425088059?pwd=K3hQOXRFa0YzUmZYSVRIejlZRklKdz09
Meeting ID: 442 508 8059, Passcode: 420

Projektbeschreibung

In modernen Softwareprojekten wird von Auftraggebern zunehmend eine Berücksichtigung ethischer Kriterien gefordert. In der Praxis wird dieses komplexe Thema häufig auf Datenschutz reduziert. Außerdem erhalten die Entwicklungsteams zu wenig Mitsprachemöglichkeiten.

Wir wollen das mit einem neuen Ansatz ändern. Die Grundidee ist hier beschrieben. Zusammen mit der Berliner UX-Firma UID entwickele ich ein „Ethical Value Assessment Tool“ (EVATool) als Open-Source-Projekt, das UID für seine Beratungsprojekte und ich für Forschungsaktivitäten nutzen möchte.

Das Frontend existiert als detailliertes Wireframe (s.u.). Es soll als Angular-Projekt umgesetzt werden.

Für das Backend existiert ein erster Prototyp, der als Fallstudie in der Veranstaltung „Fachspezifischer Architekturentwurf“ streng nach Domain-Driven Design (DDD) umgesetzt wurde.

Inhalt des Projekts

In diesem GP wollen wir das Frontend umsetzen und das Backend finalisieren und anbinden. Durch die Firma UID wird es dazu ein Praxis-Coaching „UX Design“ geben. Im Backend werden wir weiter strikt nach DDD vorgehen und die Praxis von expliziten Architekturentscheidungen in einem Decision Log fortführen. Ziel des Projekts ist es, den Stand eines MVP (Minimum Viable Products) zu erreichen. Diesen MVP können wir je nach zeitlichem Verlauf in zwei Forschungsprojekten (GINA oder INTIA) verproben.

Voraussetzungen zur Teilnahme

  • Erfahrungen in der Entwicklung (sowohl Front- wie Backend-Entwicklungserfahrung sind willkommen)
  • Erfahrung in Angular und/oder Spring sind von Vorteil, aber kein Muss
  • Bereitschaft zur Teamarbeit

Projektpartner

UID (https://www.uid.com/), Peter Klein (Head of Innovation)

Learning Outcome

Das formale Learning Outcome lässt sich so zusammenfassen: 

  • As a software developer on Master level, I can 
    • design and implement a reasonably complex greenfield application in a multi-team approach, using the domain-driven design paradigm,
  • by ...
    • analysing the domain and proactively clarify open issues with the relevant stakeholders, 
    • exploring backend and frontend technologies used in the project, so that I can make a useful contribution, 
    • documenting my architecture and technology decisions in a way that future developers can build on this documentation, 
    • using modern design principles and good practices to write "clean", well-maintainable code
  • so that the MVP that is jointly created during the project can be used for a first pilot project

Benotung

Das Projekt wird nach folgendem Schema bewertet:

Dabei gelten folgende Randbedingungen: 

  1. Die Teilaspekte MVP-Qualität und Dokumentation werden getrennt nach den Zweierteams ("Pairs") bewertet, durch ein Code-Review in den Epics Analysis, Impacts, Requirements und Variants. 
  2. In den anderen Epics (z.B. Cross-Cutting Concerns, DevOps etc.) können auch andere als die festen Pairs zusammenarbeiten. Dies wird über JIRA nachgehalten. Dafür ist es wichtig, dass Sie sich als Assignee oder Co-Assignee (ist egal welches von beiden) eintragen. Hier werden ebenfalls die Teilaspekte MVP-Qualität und Dokumentation bewertet, nach den oben genannten Kriterien. 
  3. Die Abschlusspräsentation wird für das gesamte Team bewertet.
  4. Wenn in einem Teilaspekt Einzelne erkennbar und belegbar deutliche Mehrleistung zeigt, ist ein individueller Notenbonus in dem entsprechenden Teilaspekt möglich.
  5. Punkt (4) gilt nur dann, wenn die Mehrleistung erkennbar und belegbar auf die Verbesserung des (Teil-)Teamresultats zielt. Eine reine Optimierung der eigenen Leistung ohne Betrachtung des (Teil-)Teams ist in keinem Fall ein Anlass für einen Notenbonus. 

Diese Regeln gelten deshalb, weil ein Guided Project dediziert eine Teamleistung ist, die eine entsprechende berufliche Situation abbilden soll. Dort laufen Vorhaben ebenfalls fast immer in Teamstrukturen ab. 

Projektorganisation und Zeitplan

Wir werden das Projekt in drei Block-Entwicklungssprints und einem Nachbereitungssprint fahren, gemäß untenstehender Tabelle. Sprint-Review und Planning ist jeweils Freitags.

Sprint No.

von - bis

Inhalt

Feste Tage, bitte blocken

1

08.03. - 19.03.



Entwicklungssprints, jeweils 3 Arbeitstage pro Woche

  • Mo 8.3. 13:00: Kickoff
  • tbd: Kickoff mit UID (Angular-Intro, Rückkopplung Backlog)
  • Fr 19.3. 10:00 - 13:00: Sprint-Review & -Planning

2

22.03. - 2.4.

  • Do 1.4. 13:00 - 16:00: Sprint-Review & -Planning (nicht Freitag wegen Feiertag)

3

5.4. - 16.4.

  • Fr 16.4. 10:00 - 13:00: Sprint-Review & -Planning

4

tbd

Nachbereitung, falls möglich Pilotanwendung des MVP

  • tbd: Präsentation

Organisation

Das Projekt teils sich in vier Pairs, die jeweils eine der ursprünglichen Domänen bearbeiten. Jedes Pair macht 3 feste Arbeitstage aus (kann Sa umfassen). 

Daily

Ich schlage vor, dass wir jeden Tag ein Daily machen, z.B. um 10:00 im Discord, Gruppentalk 1. Wer gerade Arbeitstag hat, kommt. 

Workshops

Kickoff 8.3. 

ZeitTopic
13:00 - 13:30Orga, Formales
13:30 - 16:00 (max.)Backlog-Planung

Sprint Review / Planning 19.3.

ZeitTopic
9:30 - 10:00Demo der erreichten Funktionalität
10:30 - 11:30Planung
11:30 - 12:00

Sonstiges

  • Bewertung
  • Branching-Regeln
  • a.o.b