This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Projektauftrag

Dieses Dokument beinhaltet den Projektauftrag (PA) für TandeMD. Das Dokument ist in die folgenden Sektionen gegliedert und basiert zu großen Teilen auf dem Projektvorschlag und dem dazu gegeben Feedback.

[[TOC]]

Projektbezeichnung und Entwicklerteam

TandeMD soll eine einfache zu bedienende und abgerundete Alternative zu konventionellen, webbasierten Markdown-Editoren bieten. Dabei soll ein besonderer Fokus auf zwei Features gelegt werden: Dem Benutzer soll eine Realtime-Collaboration mit anderen ermöglicht werden und der Editor soll komplett ohne Registrierung (Erstellung eines Accounts) verwendet werden können.

Matrikelnummer	Name	Rolle	Stellvertretende Rolle
12216451	Jeremiasz Źrółka (@12216451)	Teamcoordinator	Backend Tech Lead
12314167	Florentin Schäfer (@12314167)	Backend Tech Lead	CI/CD Lead
12225128	Nick Fischer (@12225128)	CI/CD Lead	Testing Lead
12123662	Benjamin Goisser (@12123662)	Documentation Lead	Backend Tech Lead
12314645	Alex Wilfinger (@12314645)	Testing Lead	Teamcoordinator
12226596	Jakob Matijasevic (@12226596)	UI/UX Lead	Frontend Lead

Ausgangssituation

Anmerkung: Wir beschränken uns im Folgenden nur auf webbasierte Markdown-Editoren. Wir betrachten ausschließlich Webseiten und browserbasierte Applikationen. Es soll nicht um Desktopapps, Commandline-Editoren und ähnliche gehen.

Aktuell findet man im Internet eine Unmenge an Online-Markdown-Editoren. Schaut man sich diese Lösung jedoch ein wenig genauer an und versucht sie in seinen (z.B. studentischen) Alltag zu integrieren, stößt man sehr schnell auf Limitationen und Probleme, welche einem das Leben schwer und unnötig kompliziert machen.

Viele bestehende Markdown-Editoren sind funktional nicht so ausgeprägt, wie man es von einem modernen Editor erwarten würde oder setzen zwingend Benutzerkonten voraus. Besonders fehlt auch oft die Möglichkeit, Dokumente in Echtzeit gemeinsam zu bearbeiten. Sie sind isolierte Einzellösungen für spezielle Bereiche, welche die Bedürfnisse unserer Zielgruppen großteils nicht abdecken: Entweder fehlt Realtime-Collaboration, die Exportmöglichkeiten sind eingeschränkt oder es besteht Account-Zwang.

Projektbeschreibung

TandeMD soll die in der Ausgangssituation beschriebenen Schwächen und Probleme aus der Welt schaffen. Ziel ist es eine vollständige, webbasierte Applikation zu entwickeln, welche es einem Benutzer ermöglicht schnell, unkompliziert und vor allem ohne großes Setup sein Markdown zu bearbeiten.

Dabei sind uns die folgenden Sachen besonders wichtig:

Kein Account-Zwang: Man kann alle zentralen Features des Editors verwenden ohne sich jemals registriert und eingeloggt zu haben.
Realtime-Collaboration: Es soll die Möglichkeit geben, ein Dokument seinen Mitarbeiten/Studienkollegen freizugeben und dieses dann gleichzeitig zu bearbeiten. Als Vorbild wird hier die Funktionsweise von Google Docs genommen.
Exportmöglichkeiten: Es soll die Möglichkeit geben, sein Markdown direkt im PDF oder HTML Format herunterzuladen. Dies ist besonders für Studierende nützlich, da Abgaben des Öfteren im Format eines PDFs verlangt sind.

Im Allgemeinen soll der TandeMD eine abgerundete, all-in-one Lösung zum Markdowneditieren werden. Er soll leicht zu verwenden sein, soll aber trotzdem ein leistungsfähiges und qualitativ hochwertiges Produkt sein.

Zielgruppen

Entwickler*innen/Tech-Affine Teams profitieren von Realtime-Collaboration, Versionsverlauf und vielen anderen Features für Wikis, Projektplanung und Dokumentation direkt in Markdown.

Studierende/Akademiker*innen können unseren TandeMD für gemeinsame Mitschriften und Ausarbeitung von Dokumenten verwenden. Die Realtime Collaboration und Export in verschiedene Formate machen das Tool ideal für Gruppenarbeiten und um Inhalte direkt zu teilen.

Funktionale Anforderungen

Name	Beschreibung
Toolbar	Diverse Textformatierungen (Bulletpoints, Tables, Links usw.) über eine graphische Oberfläche zugreifbar
Edit-View	Editor mit Markdown-Unterstützung und Syntaxvorhebung
Preview	Preview von Markup
Statistik-Leiste	Statistik über Anzahl Wörter, Zeilen, Character usw.
Laden	Laden von .md-Dokumenten
Realtime Collaboration	Mehrere Benutzer können gleichzeitig dasselbe Dokument bearbeiten und die Änderungen in Echtzeit sehen.
Export	Die Möglichkeit, Dokumente in Markdown (.md), PDF und HTML zu exportieren.
Sharing-Permissions mit Links	Das Teilen von Dokumenten über generierte Links mit verschiedenen Berechtigungsstufen (z.B. Anzeigen, Bearbeiten).
LateX-Math Integration	Unterstützung für die Eingabe und Darstellung mathematischer Formeln und Symbole mit LaTeX-Syntax.
Bilder/Videos	Die Möglichkeit, Bilder und Videos in Dokumente einzubetten oder einzufügen.
Custom Keybinds	Benutzerdefinierte Tastenkombinationen zur schnelleren Ausführung von Befehlen und Aktionen innerhalb der Anwendung.
Dateiverwaltung (Sub-Dokumente)	Eine Verwaltung von Dokumenten, die keine Ordnerstruktur verwendet, sondern eine hierarchische Struktur ermöglicht, bei der Dokumente Unterdokumente enthalten können.
Cheatsheet	Eine Übersicht mit einer Liste der verfügbaren Befehle, benutzerdefinierten Tastenkombinationen und Markdown-Syntax.
Versionsverlauf	Die Möglichkeit, frühere Versionen eines Dokuments einzusehen und gegebenenfalls wiederherzustellen.

Nichtfunktionale Anforderungen

Browser-Kompatibilität: Die Anwendung muss mindestens in Chrome 136 und Firefox 137 ohne Fehler lauffähig sein.

Sicherheit: Kein Zugriff auf Dokumente/Daten anderer Nutzer ohne Token. Markdown-Rendering am Client und Server soll gegen Angriffe geschützt sein (XSS, Injection-Angriffe). Datei-Uploads müssen serverseitig validiert werden.

Logging: Log-Einträge müssen mit sinnvollen Loglevels versehen werden. Z.B:

error für schwere, unerwartete Fehler, zum Beispiel:
Datenbank nicht zugreifbar
Programmierfehler
warn für Fehler, die bei normalem Betrieb auftreten können und die keine Beeinträchtigung des Systems darstellen. Zum Beispiel:
- Validierung von Anfragedaten schlägt fehl
- Anfrage kann nicht durchgeführt werden, wegen eines Konflikts mit anderen Daten des Systems
info für vom User durchgeführte Aktionen, zB. am Anfang einer REST-Endpointmethode
debug für Nachrichten in komplexeren Codestücken die beim Suchen von Problemen wertvoll sein können
trace am Anfang aller Methoden die nicht schon anderweitig geloggt wurden

Dokumentation: Die gesamte technische Dokumentation, einschließlich Code-Kommentaren für öffentliche APIs und komplexe Logik, Architektur-Beschreibungen, Setup-Anleitungen und API-Spezifikationen, ist in englischer Sprache verfasst.

Schichtentrennung: Die Anwendungsarchitektur muss klare Verantwortlichkeiten und Abhängigkeiten zwischen den einzelnen Komponenten und Schichten aufweisen, um Wartbarkeit und Testbarkeit zu fördern. Die Verwendung von Dependency Injection ist im gesamten Backend-Code konsistent umgesetzt.

Datenspeicherung: Benutzerdaten und Dokumente müssen dauerhaft, zuverlässig und konsistent gespeichert werden. Insbesondere bei gleichzeitigen Bearbeitungen muss die Konsistenz der Daten gewährleistet sein. Änderungen dürfen nicht verloren gehen oder in einen inkonsistenten Zustand überführt werden. Transaktionen werden für alle kritischen Schreiboperationen verwendet.

Iceberglist

ID	Feature	Anwendungsfall	Priorität	Aufwand	Version / Meilenstein	Zuständig
1	Editor	Markdown schreiben mit Syntaxhighlighting	H	5	2	Benjamin Goisser (@12123662)
2.1	Editor-Zugriff	Anonymer Zugriff auf den Editor ohne Login	H	4	2	Jeremiasz Źrółka (@12216451)
2.2	Editor-Zugriff	Dokumentassoziation zu Benutzer	H	3	2	Jeremiasz Źrółka (@12216451)
2.3	Editor-Zugriff	Benutzerassoziation übertragbar	N	2	2	Jeremiasz Źrółka (@12216451)
3	Persistenz	Dokumentzustand in Datenbank speichern	H	4	2	Alex Wilfinger (@12314645)
4	Preview	Markdown als HTML gerendert anzeigen	H	3	2	Benjamin Goisser (@12123662)
5.1	Side-By-Side	Live-Änderungen des Editors in der Preview anzeigen	H	1	2	Benjamin Goisser (@12123662)
5.2	Dateiverwaltung	Hierarchische Sub-Dokumente verwalten	M	4	3	Jeremiasz Źrółka (@12216451)
6.1	Dateiverwaltung	Neues Dokument erstellen	H	2	3	Jeremiasz Źrółka (@12216451)
6.2	Dateiverwaltung	Dokument umbenennen	M	2	3	Jeremiasz Źrółka (@12216451)
6.3	Dateiverwaltung	Dokumente löschen	H	2	3	Jeremiasz Źrółka (@12216451)
6.4	Kollaboration	Echtzeitbearbeitung durch mehrere Nutzer	H	7	3	Benjamin Goisser (@12123662)
7.1	Kollaboration	Anzeigen von Cursor anderer Nutzer	H	3	3	Benjamin Goisser (@12123662)
7.2	Kollaboration	Anzeigen von Nutzer in der aktuellen Session	H	2	3	Benjamin Goisser (@12123662)
7.3	Kollaboration	Anzeigenamen in Session ändern	N	1	3	Benjamin Goisser (@12123662)
7.4	Teilen & Rechte	Linkfreigabe mit Leseberechtigung	H	3	3	Nick Fischer (@12225128)
8.1	Teilen & Rechte	Linkfreigabe mit Bearbeitungsrecht	H	3	3	Nick Fischer (@12225128)
8.2	Teilen & Rechte	Linkfreigabe zurücknehmen	H	2	3	Nick Fischer (@12225128)
8.3	Versionierung	Vorherige Versionen eines Dokuments wiederherstellen	H	5	3	Alex Wilfinger (@12314645)
9.1	Versionierung	Vorherige Versionen eines Dokuments einsehen	H	2	3	Alex Wilfinger (@12314645)
9.2	Cheatsheet	Cheatsheet mit Markdown-Syntax (+Custom Keybinds) anzeigen	N	3	4	Jakob Matijasevic (@12226596
10	Custom Keybinds	Einbinden der Keybinds in Editor	M	4	4	Jeremiasz Źrółka (@12216451)
11.1	Custom Keybinds	UI zum Setzen/Ändern von Custom Keybinds	M	3	4	Jeremiasz Źrółka (@12216451)
11.2	Custom Keybinds	Persistente Speicherung von Custom Keybinds für User	M	3	4	Jeremiasz Źrółka (@12216451)
11.3	Export	Exportieren der Markdown-Datei als PDF	H	6	4	Florentin Schäfer (@12314167
12.1	Export	Exportieren der Markdown-Datei als Markdown	M	2	4	Florentin Schäfer (@12314167
12.2	Export	Exportieren der Markdown-Datei als HTML	M	2	4	Florentin Schäfer (@12314167
12.3	Medien	Bilder persistent speichern	M	2	4	Alex Wilfinger (@12314645)
13.1	Medien	Bilder in Preview anzeigen	M	2	4	Alex Wilfinger (@12314645)
13.2	Medien	Bilder in Export einbetten	M	4	4	Florentin Schäfer (@12314167
13.3	Medien	Bilder einfügen	M	3	4	Florentin Schäfer (@12314167
13.4	Toolbar	Textformatierungen (fettgedruckt, kursiv, durchgestrichen, unterstrichen	M	2	4	Jakob Matijasevic (@12226596
13.5	Toolbar	Tabellen einfügen	M	2	4	Jakob Matijasevic (@12226596
14.1	Toolbar	Bulletpoints einfügen	M	2	4	Jakob Matijasevic (@12226596
14.2	Toolbar	Links einfügen	M	2	4	Jakob Matijasevic (@12226596
14.3	Dateiimport	Lokale Markdown-Dateien hochladen	N	2	5	Alex Wilfinger (@12314645)
14.4	LaTeX	Mathematische Formeln mit LaTeX darstellen	H	4	5	Nick Fischer (@12225128)
15	Medien	YouTube-Videos einbetten	N	3	5	Jakob Matijasevic (@12226596
16	Side-By-Side	Editor und Preview gemeinsam scrollen	N	6	5	Jeremiasz Źrółka (@12216451)
17	Statistik	Wörter, Zeichen, Zeilen zählen und anzeigen	N	2	5	Nick Fischer (@12225128)

Domänenmodell

class User {
  usertoken
}

class Document {
  documentId
  title
}

class DocumentVersion {
  versionId
  createdAt
}

class DocumentAction {
  actionType
  actorId
}

class LinkShare {
  linkId
  permission
  expiresAt
}

class Settings {
  customKeybinds
}


class MediaFile {
  fileId
  fileType
  storagePath
}

class ExportedFile {
  fileId
  mediaType
  content
}

' ========== Relationships ==========
User --> Document : owns
User --> DocumentAction : performs
User --> LinkShare : creates
User --> Settings : configures

Document --> DocumentVersion : has versions
Document --> MediaFile : embeds
Document --> LinkShare : can be shared by

Document --> ExportedFile : is exported as

DocumentAction --> Document : targets
LinkShare --> Document : grants access to
@enduml

Komponentendiagramm

interface UserDAO {

}

interface DocumentDAO {

}

interface LinkShareDAO {

}

interface DocumentService {

}

interface LoginService {

}


interface LiveCollaborationService {

}

interface LinkShareService {

}

interface ExportService {

}

interface MediaFileService {

}


class UserDTO {
  usertoken
}

class DocumentDTO {
  documentId
  title
}

class DocumentVersion {
  versionId
  createdAt
}

class DocumentAction {
  actionType
  actorId
}

class LinkShare {
  linkId
  permission
  expiresAt
}

class Settings {
  customKeybinds
}


class MediaFileDTO {
  fileId
  fileType
  storagePath
}

class ExportedFile {
  fileId
  mediaType
  content
}

' ========== Relationships ==========
UserDAO <-- LoginService
LinkShareDAO <-- LinkShareService
DocumentDAO <-- DocumentService
DocumentDAO <-- LiveCollaborationService
ExportService --> ExportedFile : renders
LoginService --> UserDTO : returns uppon login
LinkShareService --> LinkShare : manages
LiveCollaborationService --> DocumentAction : syncs between users
LiveCollaborationService --> DocumentVersion : auto-saves
DocumentService --> DocumentDTO : manages
MediaFileService --> MediaFileDTO : manages
DocumentService --> DocumentVersion : manages
@enduml

Arbeitsstruktur & Grober Projektplan

Das Projektteam besteht aus 6 Entwicklern, die Expertenrollen (und damit verbundene horizontale Verantwortlichkeiten) wurden bereits im Projektvorschlag definiert. Es wurde entschieden eine Kombination aus dem Rational Unified Process (RUP) und SCRUM anzuwenden: Zu Projektbeginn hat RUP mehr Einfluss (Anforderungen, Expertenwissen/Rollen), während in der Construction Phase von RUP hauptsächlich SCRUM eingesetzt werden soll.

Rollenverteilung

siehe Projektbezeichnung und Entwicklerteam

Aufgrund dieser Expertenrollen muss die Projekt- (SCM, Tracker) und Produktinfrastruktur (Maven) aufgebaut werden. Auch das Verfassen von Artefakten bzw. Dokumentation unterliegt bestimmten Experten (siehe Grober Projektplan), jedoch reviewen und beitragen muss jeder.

Horizontale Verantwortlichkeiten

Technische Architekten Backend & Frontend: Florentin Schäfer & Jakob Matijasevic

Technische Architekten verwalten die Programm Infrastruktur des Projekts, z.B. Ordnerstruktur und Abhängige JAR Bibliotheken der Software (Dependencies). Zum Expertenwissen der Technischen Architekten zählen eindeutig sehr gute Kenntnisse der verwendeten Programmiersprachen, Toolkits und Frameworks, sowie Architekturelles Design und Software Patterns. Spezifische Horizontale Verantwortlichkeiten für dieses Projekt sind:

Projekt Objekt Model (Maven pom.xml)
- Dependency Management, vor allem Versionen
- Plugins, z.B. JTidy
- verwendete externe Maven Repositories
Expertenwissen zu allen verwendeten Technologien der Technischen Entwicklung, z.B. Eclipse, Maven.
Erstellung von Kodierungs-Richtlinien (Checkstyle).
Erstellung von Richtlinien zur Sourcecode-Dokumentation (Javadoc).
Verwaltung aller Enhancement-Tickets im Tracker
Design der Programmarchitektur und -komponenten
- UML Komponentendiagramm auf Interface-Ebene
- Verteilungsdiagramm

Team Koordinator: Jeremiasz Źrółka

Team Koordinatoren müssen gute Projektmanagement Kenntnisse haben und sind für die Aktualität der Artefakte des laufenden Projektmanagement (z.B. Projektplan) verantwortlich.

Organisation und Planung (laufende Dokumentation)
- Projektplan, WBS, siehe Grober Projektplan
- Risikoanalyse, Iceberglist, Burn-Down Charts
Controlling & Tracking
- Stundenlisten, Organisatorische-Tickets vom Tracker
- Statuserhebung für den Statusbericht (Reviews), siehe Lieferkomponenten
Kontrolle der Aufgabenverteilung (Arbeit/Developer), siehe Grober Projektplan und Iceberglist
Primärer Ansprechpartner für die Auftraggeber
Organisation interner und externer Meetings
- Gruppentreffen (Jour-Fixe), Tutortreffen, IR's, MR's
- siehe Informationswesen

Dokumentationsbeauftragte: Benjamin Goisser

Verfügbarkeit der Dokumentation, z.B. über Mercurial und Maven site.
Java API Dokumentation integrieren mit dem Maven Javadoc Plugin
- Jede Java-Package muss dokumentiert werden. Eine package-info.java Datei muss für jedes Java-Package erstellt werden.
Sicherstellen, dass alle Klassen, Variablen und Methoden in English dokumentiert werden
Erstellung von Dokumentationsrichtlinien (Format- und Formatierungsrichtlinien, Spezifikation der Code Conventions, Erstellung von Vorlagen, ...)
Überprüfung der Einhaltung von Dokumentationsrichtlinien
Überprüfung der Vollständigkeit von Dokumenten
Organisation und Archivierung der Dokumente im SCM

Testbeauftragte: Alex Wilfinger

Test Infrastruktur
- Test Bibliotheken, Testdaten (zweite DB).
- Test Suites: Integration mit Spring Framework um Testdaten zu managen.
- Sicherstellen, dass Testcode von Produktionscode getrennt wird.
Erstellung des Testplans
- Testvorgehensweise (Codegerüst), Planung von Test-Runs
- Auswirkungen bei Fehlern, WeitergabeVerhalten bei Fehlern (Exceptionhandling)
- siehe Meilenstein 2 in den Lieferkomponenten
  - Überprüfung der Einhaltung von Testrichtlinien
Verwaltung aller Trouble-Tickets im Tracker
Überwachung von Integrations- und Systemtests (starke Zusammenarbeit mit dem Technischen Architekten)
Regelmäßige Überprüfung aller Unit-Tests

CI/CD Manager: Nick Fischer

Development Environment Infrastruktur
- Scripts zum initialisieren, testen oder verteilen (deploy)
- Tagging im SCM für jeden Meilenstein, siehe Iceberglist und Lieferkomponenten
- Build, Deploy Targets von Maven; "Projekt kann jederzeit ausgecheckt und kompiliert werden"
Expertenwissen über die Build und SCM Werkzeuge (Maven & Git)

Grober Projektplan

Work Breakdown Structure (WBS)

Nr.	Arbeitspakete	Anfang	Ende	Personenstage	Verantwortliche(r)
IR-0	Kickoff	08.04.2025	08.04.2025	1
1.0	Projektideenfindung	08.04.2025	10.04.2025	3
1.1	Erstellung des Projektfindungsdokumentes	08.04.2025	10.04.2025	3
1.2	Erstellung der PowerPoint	10.04.2025	10.04.2025	0.5	Jeremiasz Zrolka (@12216451)
MR-0	Projektvorschlag	11.04.2025	11.04.2025	1
2.0	Technische Machbarkeitsanalyse	11.04.2025	24.04.2025	13
2.1	Recherche zu Real-Time Collaboration	11.04.2025	24.04.2025	13	Benjamin Goisser (@12123662), Florentin Schäfer (@12314167), Alex Wilfinger (@12314645), Nick Fischer (@12225128)
2.2	Recherche zu Versionierung von Dokumenten	11.04.2025	24.04.2025	13	Alex Wilfinger (@12314645)
2.3	Recherche zur Generierung von PDFs	11.04.2028	24.04.2028	13	Florentin Schäfer (@12314167)
2.4	Recherche zu dem Frontend Tech-Stack	11.04.2029	24.04.2029	13	Jakob Lechitiel Matijasevic (@12226596)
2.5	Recherche zu eingebetteten Editoren	11.04.2030	24.04.2030	13	Jeremiasz Zrolka (@12216451), Jakob Lechitiel Matijasevic (@12226596), Florentin Schäfer (@12314167), Benjamin Goisser (@12123662), Nick Fischer (@12225128)
2.6	Bau von Proof-of-Concept-Editoren	11.04.2031	24.04.2031	13	Benjamin Goisser (@12123662), Florentin Schäfer (@12314167)
3.0	Anforderungsanalyse	24.04.2025	27.04.2025	3
3.1	Erstellung des Projektauftrages	24.04.2025	27.04.2025	3
3.2	Erstellung der PowerPoint	24.04.2025	27.04.2025	3
MR-1 & MS-1	Projektauftrag	28.04.2025	28.04.2025	1
4.0	Implementierung Sprint 1 bis MS-2, für technische AP siehe Eisbergliste	28.04.2025	12.05.2025	14
4.1	Definition der REST-Schnittstellen mittels OpenAPI	28.04.2025	28.04.2025	1	Jakob Lechitiel Matijasevic (@12226596)
4.2	Erstellung von UML-Klassendiagrammen für das Backend	28.04.2025	28.04.2025	1	Florentin Schäfer (@12314167)
4.3	Planung von Datenbankschemas	28.04.2025	12.05.2025	1	Alex Wilfinger (@12314645)
4.4	Einrichtung von Git-Hooks zur Qualitätssicherung	28.04.2025	28.04.2025	1	Nick Fischer (@12225128)
4.5	Einrichtung der individuellen Entwicklungsumgebungen	28.04.2025	28.04.2025	1
4.6	Dokumentation der Stylekonventionen
4.6.1	Stylekonventionen im Backend	29.04.2025	29.04.2025	1	Florentin Schäfer (@12314167)
4.6.2	Stylekonventionen im Frontend	29.04.2025	29.04.2025	1	Jakob Lechitiel Matijasevic (@12226596)
4.7	Dokumentation der Gitkonventionen	29.04.2025	29.04.2025	1	Nick Fischer (@12225128)
4.8	Dokumentation der Dokumentationskonventionen	29.04.2025	29.04.2025	1	Alex Wilfinger (@12314645)
4.9	Aufsetzen von Tools zur Codequalitätssicherung (z.b. Sonarqube)	30.04.2025	02.05.2025	2	Nick Fischer (@12225128)
IR-1 & MS-2	Internes Review 1, Meilenstein 2 erreicht	12.05 - 16.05	12.05 - 16.05	1
5.0	Implementierung Sprint 2 bis MS-3, siehe Eisbergliste	12.05.2025	26.05.2025	14
MR-2 & MS-3	Management Review 2, Meilenstein 3 erreicht	26.05 - 30.05	26.05 - 30.05	1
6.0	Implementierung Sprint 3 bis MS-4, siehe Eisbergliste	26.05.2025	09.06.2025	14
IR-2 & MS-4	Internes Review 2, Meilenstein 4 erreicht	09.06 - 13.06	09.06 - 13.06	1
7.0	Implementierung Sprint 4 bis MS-5, siehe Eisbergliste	09.06.2025	23.06.2025	14
MR-3 & MS-5	Projektabnahme, alle Meilensteine erreicht	23.06 - 27.06	23.06 - 27.06	1

Meilensteine

Meilenstein 1: Projektauftrag (MR-1)

Meilenstein 2: Aufsetzen, Grundlagen und Persistenz (IR-1)

Technische Planung (UML-Diagramme, DB-Schema, ...)
Aufsetzen des Projekts und der Tests
Accountlose Authentifikation
Speichern von Dokumentzustand
Edit-View / Preview

Beschreibung

Ist Meilenstein 2 erreicht, soll es bereits einen eindeutigen Plan vom Aufbau des Projektes geben. Für alle Schichten soll ein Skelett vorhanden sein, ebenso soll die Testinfrastruktur inklusive CI/CD eingerichtet sein.

Weiters sollen die grundlegendsten Features, nämlich der Editor, das Preview und das Speichern und Wiederherstellen des Dokumentzustands aus der Datenbank für BenutzerInnen anhand des User-Tokens, implementiert sein.

Meilenstein 3: Kollaboration und Versionierung (MR-2)

Dateiverwaltung (Crud)
Realtime Collab
Sharing und Permissions
Versionsverlauf

Beschreibung

Nach diesem Meilenstein soll es möglich sein, Dokumente zu erstellen, löschen, verschieben und umzubenennen. Jedes Dokument soll versioniert werden, um alte Zustände wiederherstellen zu können.

Vor allem soll das Highlight-Feature von TandeMD, die Echtzeit-Kollaboration, implementiert sein. Das beinhaltet das gemeinsame Bearbeiten von Dokumenten, die Anzeige der Cursor/Selection anderer BenutzerInnen und eine Anzeige der aktuell am Dokument beteiligten NutzerInnen.

Um gemeinsam Dokumente bearbeiten zu können, benötigt es ein Sharing-Feature, womit man durch einen generierten Link andere NutzerInnen einladen kann, um ein Dokument zu lesen oder zu bearbeiten. Dabei soll dem/der BesitzerIn eines Dokuments eine Übersicht geboten werden, um nachzuvollziehen, welche NutzerInnen welche Berechtigungen für ein Dokument besitzen. Es soll auch möglich sein, Berechtigungen zu entziehen.

Meilenstein 4: Editor-Tools (IR-2)

Dokument-Export
Bilder unterstützen
Cheatsheet
Custom Keybinds
Toolbar

Beschreibung

Nach Meileinstein 4 sollen zwei essentielle Features implementiert sein: der Export von Dokumenten in verschiedene Dateiformate (zumindest PDF und HTML) und das Hochladen, in der Datenbank Speichern und Abrufen und Anzeigen von Bildern. Dabei sollen die generierten Dateien ein vorhersehbares Layout und ein modernes Styling aufweisen.

Der Rest der Features dienen der Quality of Life zur Benutzung von TandeMD. Es soll ein Cheatsheet angezeigt werden, welches die BenutzerInnen über die Syntax und unterstützten Markdown-Funktionen aufklärt. Auch soll es möglich sein, über eine Toolbar Bilder, Tabellen, Links etc. einzufügen und die Formatierung von Text anzupassen (fettgedruckt, kursiv etc.). Diese Funktionen sollen ebenso von NutzerInnen mit über eine eigene Oberfläche einstellbaren Tastaturkürzeln bedient werden können.

Meilenstein 5: Advanced Features (MR-3)

Latex/Math integration
Hochladen von Dateien (Markdown Files)
Youtube embeds
Side-By-Side Scrolling
Statistik-Leiste

Beschreibung

Nach dem letzten Meilenstein sollen Latex-Formeln integriert werden, um TandeMD mehr auf eine der Zielgruppen, Studierende, anzupassen. Dabei sollen die Formeln sowohl im Preview als auch in exportierten Dateien annehmbar aussehen. Außerdem sollen Links auf Youtube-Videos im Preview oder HTML-Export als eingebetteter Player angezeigt werden.

Weiters soll die Benutzbarkeit verbessert werden, indem der Editor und das Preview synchronisiert scrollbar gemacht werden, der Upload von bestehenden Markdown-Dokumenten ermöglicht wird, und eine Statistik-Leiste, welche nützliche Informationen wie die Wortanzahl des Dokuments anzeigt, hinzugefügt wird.

Projektabgrenzungen

Nicht-Ziele:

Erstellen, Pflegen oder Aktualisieren von jeglicher Dokumentation nach Projektabnahme.
Entwickeln oder Weiterentwickeln jeglicher Software nach der Projektabnahme.
Fixen von Fehlern und sonstiger Bugs in jeglicher Software nach Projektabnahme.
Betreiben jeglicher Software nach Projektabnahme.
Installationsdienste jeglicher Software auf jeglichen Systemen. Ausnahme dazu bildet die automatisierte Installation auf der von der Lehrveranstalltung zur verfügung gestellten Kubernetes-Umgebung.
Migrationsdienste jeglicher Software (inklusive Datenbanken) nach Projektende.
Durchführen von Schulungen jeglicher Art.
Einrichtung under der Betrieb eines Helpdesk- oder Support-Services.
Ausführen von Sicherheitstests (z.b. Penetrationtests).
Das Projekt kann nach Projektabnahme gebaut werden.
Das Frontend der ausgelieferten Software ist auf Endgeräten mit einer Bildschirmdiagonale kleiner als 11 Zoll ohne Einschränkungen nutzbar.
Das Frontend der ausgelieferten Software kann mit Browsern außer Mozilla Firefox in der Version 137 und Google Chrome 136 korrekt dargestellt werden und ist ohne Einschränklungen nutzbar.
Das Frontend der ausgelieferten Software ist für menschen mit einer Sehbehinderung ohne Einschränkungen nutzbar.
Die Backend der ausgelieferten Software ist lauffähig auf Systemen mit weniger als 500MB Speicherplatz und 2GB RAM.
Das Backend ist lauffähig auf Systemen die nicht eine x64-Architektur aufweisen.
Das Backend soll auf einem beliebigen Computer korrekt funktionieren, wenn mehr als 10 Benutzer gleichzeitig Aktionen auf dem Frontend ausführen.
Die Software soll auf anderen Sprachen als US-amerikanischem Englisch (en_US) Text anzeigen können.
Die Software soll Daten und Uhrzeiten in anderen Formaten als dem US-amerikanischem (en_US) anzeigen können.
Die Software soll eine gesonderte API/SDK für Drittwentwickler bereit stellen.
Die Software soll mit Dokumenten außer Markdown-Dateien arbeiten können.
Die Software soll mit Dokumenten die nicht UTF-8 kodiert sind arbeiten können.
Die Software soll Bilder und Videos die größer sind als 50 Megabyte verarbeiten können.

Lieferkomponenten

Folgende Komponenten werden bei der Abnahme des Projektes überprüft:

Die auf der zur Verfügung gestellten Kubernetes-Umgebung laufende Applikation.
Der gesamte Source-Code der Applikation, inklusive automatisierter Tests, auf dem zur Verfügung gestellten GitLab-Repository.
Die gesamte Dokumentation der Applikation auf der zur Verfügung gestellten GitLab-Instanz.

Risikoabschätzung

Risiko	Wahrscheinlichkeit	Auswirkung	Gegenmaßnahmen	Verantwortliche(r)
Performance-Probleme bei Echtzeit-Kollaboration	Mittel	Hoch	Bewährte Frameworks (Y.js, WebSockets) nutzen; Lasttests durchführen	Benjamin Goisser (@12123662), Florentin Schäfer (@12314167)
Datenverlust ohne Account (z. B. bei Gerätemigration oder Browser-Clearing)	Mittel	Hoch	Nutzer:innen über Risiken aufklären; "Export local copy" als fallback anbieten.	Jeremiasz Źrółka (@12216451)
Abhängigkeit von Bibliotheken (Monaco Editor, Y.js)	Mittel	Mittel	Alternativen evaluieren; Etablierte Bibliotheken verwenden; Proof of Concepts; Überprüfung der Wartungshäufigkeit (Commits usw.)	Florentin Schäfer (@12314167)
Unbefugte Bearbeitung durch öffentlich geteilte Links	Mittel	Hoch	Optionales Rollen- und Rechtemanagement (z. B. Nur-Lesen / Editieren); Warnhinweise bei öffentlichem Teilen; Tokens mit Ablaufdatum	Nick Fischer (@12225128)
Server überlastet bei vielen Sessions	Mittel	Hoch	Informieren der LVA-Leitung über Serverprobleme	Florentin Schäfer (@12314167)
Ausfall von Personen	Niedrig	Hoch	Aufgaben dokumentieren; Wissensaustausch fördern; regelmäßige Team-Reviews etablieren.	Jeremiasz Źrółka (@12216451)
Unklare Rollenverteilung	Niedrig	Mittel	Projektrollen und Zuständigkeiten klar definieren; regelmäßige Meetings	Jeremiasz Źrółka (@12216451)
Unrealistische Zeitplanung	Mittel	Hoch	Agile Vorgehensweise mit Iterationen und Review-Meetings; klare MVP-Definition; regelmäßige Re-Priorisierung von Aufgaben.	Jeremiasz Źrółka (@12216451)
Fehlendes Testing	Niedrig	Mittel	Automatisierte Tests; Testverantwortung klar verteilen	Jeremiasz Źrółka (@12216451)
Abhängigkeiten von Einzelpersonen für bestimmte Module	Mittel	Mittel	Querschnittskenntnisse fördern; Gute Dokumentation der Module	Jeremiasz Źrółka (@12216451)

Informationswesen

Die Informationsstruktur für das Projekt wird folgendermaßen aussehen:

Wöchentliche Treffen intern (Jour-Fixe)
Wöchentliche Treffen mit dem Tutor (Tutortreffen)
Insgesamt 5 Reviews (2 IRs, 3 MRs) zu den 5 Meilensteinen mit 5 Statusberichten
Elektronische Kommunikation synchron mit Zoom und Google Docs, asynchron via dem Tracker. Die Mailingliste ist mit niedrigerer Priorität zu verwenden.
Kommunikation mit den Auftraggebern und Tutor per Mailingliste

Die zur Verfügung gestellte Infrastruktur umfasst:

Git Repository
Kubernetes Umgebung