pantrag_fiae Projektantrag: Codegenerator

[Saheeda]

Hi,

ich muss in zwei Wochen meinen Antrag einreichen und habe mal eine erste Version erstellt. Leider kann ich mich (noch) nicht bei meiner IHK einloggen (das kläre ich morgen), deswegen habe ich versucht, mich ein bisschen an den Anträgen hier im Forum zu orientieren.

 

Zitat

1. Projektumfeld

$Brötchengeber ist ein in $Irgendwo ansässiger Dienstleister für Individual-Softwarelösungen und IT-Consulting. Das Kerngeschäft besteht in der detaillierten Problemanalyse zur Entwicklung maßgeschneiderter Lösungen, die nachhaltig umgesetzt und in eine bestehende IT-Infrastruktur passgenau integriert werden. $Brötchengeber ist tätig in allen Branchen und Bereichen, in denen standardisierte Prozesse ablaufen und zeitnah umgesetzt werden müssen. $Brötchengeber entwickelt zeitnah umsetzbare Lösungen, die abteilungsspezifische Prozesse optimieren, Zeit sparen und Ressourcen effektiv einsetzen.

2. Projektbezeichnung

Erstellung eines Codegenerators zur Unterstützung bei der Frontendentwicklung

2.1 Ist-Zustand

Einige der von $Brötchengeber mittels Java EE entwickelten Projekte nutzen JSP als Technologie zur Gestaltung des Frontends. Die Infrastruktur zum Gestalten einfacher CRUD-Operationen wird dabei zu einem sehr großen Teil händisch erstellt. Dieser Prozess gestaltet sich als äußerst repetitiv und je nach Größe / Umfang des Domainobjekts zunehmend zeitraubend.

 

2.2 Soll-Zustand

Es soll eine Möglichkeit entwickelt werden, um diesen bisher händischen Prozess so weit wie möglich zu vereinfachen und zu automatisieren.

Zu beachten ist dabei, dass die Lösung sich via Maven integrieren lässt, mit Spring ab Version xxx und Java Version 1.7 kompatibel ist.

Zusätzlich muss der Generator so gestaltet werden, dass an den bisherigen Domainobjekten so wenige Änderungen wie möglich notwendig sind, um sie für den Generator verfügbar zu machen. Außerdem müssen die erstellten Dateien durch den Programmierer bearbeitbar sein, d.h. die Generierung erfolgt entweder nur initial oder so, dass Änderungen nicht überschrieben werden.

Je Domainobjekt soll der Generator folgende Dateien erstellen:

• 1 Controller mit Operationen für Create, Read (Liste + Einzelnes Objekt), Update, Delete

• je 1 Command für Create, Read, Update, welches die jeweiligen Dialogfelder bindet/repräsentiert

• je 1 .jsp für Create, Read (Liste + Einzeln) und Update

Der Quellcode soll entsprechend der firmeninternen Richtlinien aufgebaut und voll mit JavaDoc dokumentiert werden.

 

3. Projektphasen und Zeitplan

Planung			12,0 h
	Ermitteln eines geeigneten Generatorframeworks		3,0 h
	Ermitteln einer geeigneten Templating-Engine		2,0 h
	Erarbeitung Konzept für Auslesen anhand des gewählten Frameworks		5,0 h
	Erstellung UML-Klassendiagramm		2,0 h
Implementierung & Testen			44,0 h
	Programmierung
		Erstellung von Templates für Controller und Commands	3,5 h
		Erstellung von Templates für JSPs	3,5 h
		Parsen/Auslesen der Domainobjekte	10,0 h
		Befüllen der Templates mit Daten	2,0 h
		Integration in Buildprozess	12,0 h
	Testing
		Testen der korrekten, kompilierbaren Generierung	2,0 h
		Testen der Benutzbarkeit der erzeugten Oberflächen	5,0 h
		Testweise lokale Integration in ein bestehendes Projekt	3,0 h
	Review und Überarbeitung		3,0 h
Nachbetrachtung			6,0 h
	Wirtschaftlichkeitsbetrachtung		2,5 h
	Vergleich Ist- & Soll-Zustand		3,5 h
Dokumentation			8,0 h
	Codedokumentation		5,0 h
	Entwicklerdokumentation		3,0 h
70,0 h

 

 

Meines Erachtens ist mein größtes Manko die Zeitplanung.

Bei vielen Anträgen hier ist die Planungsphase nur ~ 6-8 h lang, andererseits soll auch deutlich werden, dass ich mir vorher genau überlege, was ich wie tun möchte und nicht "einfach drauf los" arbeite.
Bei der Programmierung gefällt mir die zwei großen Blöcke fürs Parsen und Integrieren nicht. Andererseits weiß ich aber auch nicht, wie ich die noch runterbrechen soll. 
Das Auslesen (z.B. via APT) kann n bisschen fummelig sein, aber genau kann ichs nicht festlegen, da es ja auch vom Framework abhängt (momentan Spring Roo vs. APT).
Ebenso die Integration in den Buildprozess.

Beim Testing:
Ich möchte den Generator mit verschiedenen (unterschiedlich komplexen) Domainobjekten füttern und schauen, ob das Generierte kompilierbar (bei den .java) und benutzbar (bei den.jsp) ist (kann ich alle Links klicken, funktionieren Weiterleitungen, etc).

Nachbetrachtung/Auswertung:
Sind 6 h dafür angemessen? Oder zu viel? Oder zu wenig?

Dokumentation:
Ich habe maximal 8 h, ist das von der Aufteilung her OK?

Kurz: Mir gefällt meine Zeitplanung noch nicht so richtig, aber ich hab auch grad keine Idee, was ich da anders/besser machen könnte.
 

Vielen Dank für Eure Hilfe!

 

[stefan.macke]

Meine erste Frage bei diesem Antrag wäre: Gibt es da noch nichts am Markt? Das hört sich nach einer generischen Anforderung an, die sicher schon gelöst wurde (gerade im Java-Umfeld). Oder gibt es spezielle (unternehmensspezifische) Anforderungen an den generierten Code? In beiden Fällen würde ich mir aber eine Make-or-Buy-Betrachtung wünschen.

Und dann kurz zur Praxis: Falls du es nicht schon kennst, schau dir mal Xtext an. Das kann alles, was du brauchst, und deine Anforderung kannst du wahrscheinlich mit dem Datenmodell des "5-Minuten-Tutorials" umsetzen

Xtext - 5 Minutes Tutorial

Eine eigene Programmiersprache mit Xtext modellieren

[Saheeda]

Hallo,

ich habe mir von mehreren Kollegen sagen lassen, dass unsere "DTO-Struktur" etwas spezieller und nicht unbedingt üblich ist, es müsste also noch Arbeit reingesteckt werden, um es auf unsere Struktur zurecht zu biegen. 

Wie würde so eine Make-Or-Buy-Betrachtung im Antrag aussehen? Kann ich dazu im Antrag einen Zweizeiler schrieben (ähnlich dem hier im Forum) und dazu in der Dokumentation selbst etwas mehr erklären?

 

Xtext werde ich mir mal anschauen.

Frage dazu: Beim Stellen des Antrags habe ich eine Technologie im Hinterkopf, die potentiell dafür geeignet wäre. Die eigentliche Entscheidung / der Produktvergleich sollte aber erst während der Arbeit selbst stattfinden.

Wenn ich jetzt merke, dass es. z.B. mit Xtest nur die Hälfte der Zeit dauert, ist das für die Praxis richtig toll, aber ich komme damit in der Projektarbeit nicht mehr auf meine 70 Stunden...

 

 

[Saheeda]

Hallo,

da es hier weniger Beispielanträge für FIAE als für FISI gibt wollte ich mich nochmal melden.

Ich habe den Antrag nochmal überarbeitet, er wurde so von meiner IHK ohne Auflagen genehmigt.

 

Zitat

Entwicklung eines Codegenerators zur Unterstützung bei der Frontendentwicklung

 

==Ist-Zustand ==

Alle der von $Brötchengeber mittels Java EE entwickelten Projekte beruhen auf dem Springrumpf. Dieser Rumpf enthält bereits die wichtigsten Standardfunktionen, die in sämtlichen Projekten benötigt werden.

Als Technologie zur Gestaltung des Frontends wird dabei standardmäßig JSP benutzt.

Die Templates und serverseitigen Endpunkte (Controller) werden bisher händisch erstellt. Insbesondere für einfache CRUD-Operationen gestaltet sich dieser Prozess als äußerst repetitiv und je nach Größe / Umfang der zu erfassenden Daten als zunehmend zeitraubend.

 

== Soll-Zustand ==

Es soll eine Möglichkeit entwickelt werden, um diesen bisher händischen Prozess so weit wie möglich zu vereinfachen und zu automatisieren.

 

Es wird bereits ein auf Java Annotation Processing basierender Codegenerierungsansatz für DTOs (Data Transfer Objects) eingesetzt, der in der Arbeit erstellte Codegenerator soll dazu kompatibel sein. Er soll aber im Gegensatz zum Bestehenden darauf ausgelegt sein, dass die erzeugten Artefakte vom Programmierer hinterher bearbeitet und angepasst werden können, d.h. die Generierung erfolgt entweder nur initial oder so, dass Änderungen nicht überschrieben werden.

 

Zu beachten ist dabei, dass die Lösung sich via Maven integrieren lässt, mit Spring ab Version 4.1.6 und Java Version 1.8 kompatibel ist.

 

Zusätzlich muss der Generator so gestaltet werden, dass eine Migration auf die neue Lösung so wenige Anpassungen wie möglich im Bestandscode erfordert.

 

Je Domainobjekt sollen folgende Dateien generiert werden:

ein Controller mit Operationen für Create, Show (Liste + Einzelnes Objekt), Update, Delete

je ein Model für Create, Read, Update, welches die jeweiligen Dialogfelder bindet/repräsentiert

je eine JSP-Datei für die Aktionen Create, Show (Liste + Einzeln) und Update

Der Quellcode soll entsprechend der firmeninternen Richtlinien aufgebaut und vollständig mit JavaDoc dokumentiert werden.

Am Ende des Projekts soll ein lauffähiges und funktionierendes Modul zur Codegenerierung stehen, welches in den Springrumpf integriert werden kann und damit in allen anderen Projekten verfügbar ist.

 

(Zeitplanung in Stunden)

 

1 Startphase

1.1 Erstellung Lastenheft (2,5)

 

2 Planung

2.1 Analyse der Domain-Objekte + Erarbeitung Struktur/Aufbau der Templates (3,0)

2.2 UML-Klassendiagram Zusammenhang DTOs – Domainobjekte (2,0)

2.3 Ermittlung eines geeigneten Generatorframeworks (2,5)

2.4 Ermittlung einer geeigneten Templating-Engine (2,5)

2.5 Erarbeitung Konzept für Auslesen/Parsen anhand des gewählten Frameworks (6,0)

 

3 Durchführung

3.1 Programmierung

3.1.1 Erstellung von Templates für Controller und Commands (3,5)

3.1.2 Erstellung von Templates für .jsp (3,5)

3.1.3 Auslesen/Parsen der Domainobjekte (8,0)

3.1.4 Befüllen der Templates mit Daten (2,0)

3.1.5 Integration in Buildprozess (10,0)

3.2 Testen

3.2.1 Korrekte, kompilierbare Generierung (2,0)

3.2.2 Benutzbarkeit der erzeugten Oberflächen (6,0)

3.2.3 Review und Überarbeitung (3,0)

 

4 Projektabschluss

4.1 Armortisationsrechnung (1,0)

4.2 Wirtschaftlichkeitsbetrachtung (2,0)

4.3 Vergleich Ist- & Soll-Zustand (3,5)

4.4 Erstellung der Projektdokumentation (5,5)

4.5 Erstellung der Kundendokumentation (1,5)

 

 

Projektdokumentation

Lastenheft

UML-Klassendiagramm

Programmablaufplan

 

 

Bearbeitet 23. August 2016 von Saheeda

[Rienne]

Hallo,

nur mal so eine kleine Verständnisfrage als auch angehende FIAElerin:

vor 13 Stunden schrieb Saheeda:

UML-Klassendiagramm

Programmablaufplan

Du scheinst ja objektorientiert zu programmieren, wenn du Klassendiagramme anfertigst.

Warum "switchst" du dann zu einem Programmablaufplan statt bei den entsprechenden UML Diagrammen (z.B. Aktivitätsdiagramm) zu bleiben?

Finde es übrigens mutig für die Projektdokumentation nur 5 1/2 Stunden einzurechnen - unsere IHK verlangt mindestens 10-12 Stunden und wenn man hier so von ehemaligen FIAE-Prüflingen liest, waren die zum Teil noch wesentlich länger damit beschäftigt. ^^

Auch würde unserer IHK hier der Projektmanagement-Anteil viel zu gering sein. In der Planung kommt nichts in der Richtung vor (z.B. Arbeitspakete, Meilensteine etc).

 

Liebe Grüße

Rienne

[Nopp]

vor 17 Minuten schrieb Rienne:

Auch würde unserer IHK hier der Projektmanagement-Anteil viel zu gering sein. In der Planung kommt nichts in der Richtung vor (z.B. Arbeitspakete, Meilensteine etc).

Also sowas wie Arbeitspakete und einen Meilensteinplan erstellen ist m.M. nach ein wenig Overkill und sehr sehr selten überhaupt verlangt und der Prüfung von FI. Wenn dann reißt man es auch nur im Konzept an. Der PM Anteil hält sich in der Ausbildung wirklich in Grenzen...

[Saheeda]

@Rienne

Ich werde ein UML-Diagramm zu unserem Domain-/DTO-Konzept mit anhängen. Mir wurde schon von mehreren Kollegen gesagt, dass es bei uns etwas spezieller und nicht unbedingt in anderen Firmen so üblich ist. Von daher wird es denke ich beim Verständnis helfen.

Ich habe für die Dokumentation insgesamt maximal 8 h. Wenn ich Projekt- und Kundendoku zusammenrechne, komme ich zumindest auf 7. (Was zugegeben immernoch nicht die Welt ist).

btw wurde uns sogar von mehreren Lehrern gesagt, dass diese Zahl komplett utopisch ist und eigentlich fast jeder mehr Zeit reinsteckt.

 

Bearbeitet 24. August 2016 von Saheeda

[Rienne]

vor 18 Minuten schrieb Nopp:

Also sowas wie Arbeitspakete und einen Meilensteinplan erstellen ist m.M. nach ein wenig Overkill und sehr sehr selten überhaupt verlangt und der Prüfung von FI. Wenn dann reißt man es auch nur im Konzept an. Der PM Anteil hält sich in der Ausbildung wirklich in Grenzen...

Da scheinen die IHKs echt unterschiedlich zu ticken. Bei uns ist der PM Anteil wesentlich wichtiger als das Programmieren an sich - und auch Meilensteine sind ein MUSS. Zusätzlich müssen auch QM-Maßnahmen eindeutig ersichtlich sein - z.B. durch Testprotokolle.

Hier das, was so im Groben von unserer IHK verlangt wird (es soll sich ja um ein reales PROJEKT handeln und nicht nur um reines Codieren und Dokumentieren davon):

Zitat

Typische Dokumente des Projektmanagements sind:
• der Auftrag
• das Vorgehensmodell mit seinen Meilensteinen
• der Projektplan (Aufbau-, Ablaufplan) mit Zeiten
• Ressourcenplan
• Kosten-Nutzenanalyse
• Projektfortschrittsberichte
• Projektabschlussbericht
• Soll-Ist-Vergleiche.
Typische Dokumente des Qualitätsmanagements sind:
• QM-Plan
• QM-Regelungen (Arbeitsanweisungen, Standard Operating Procedures soweit sie hier relevant sind)
• Dokumente des Änderungsmanagements, Ablage von Dokumenten
• Testszenarien, Testfälle, Testprotokolle
• Abnahmeprotokolle
• QM-Bericht
Typische Dokumente des Software-Engineering, auch mit Technischer Dokumentation bezeichnet sind:
• Ist-Analyse, Anforderungs-Analyse, Machbarkeitsstudie, Marktanalyse,
• Lastenheft
• Abgenommenes Pflichtenheft mit Fachentwurf
• DV-Entwürfe: Softwarearchitektur, Algorithmen-Entwürfe, Datenmodelle, Bildschirm-Layouts, Report-Layouts
• Kommentierter Quellcode.

Gibt hier aber ja anscheinend auch IHKs/PAs bei denen Fachinformatiker nicht als kaufmännischer Beruf angesehen wird.

 

vor 9 Minuten schrieb Saheeda:

Ich habe für die Dokumentation insgesamt maximal 8 h. Wenn ich Projekt- und Kundendoku zusammenrechne, komme ich zumindest auf 7.

Mh, bei uns wird explizit zwischen Projektdokumentation und den andere Dokumentationen unterschieden was die Zeitvorgabe betrifft. Hier der Auszug aus unserer Handreiche:

Zitat

Von der als maximal genannten Projektzeit („Soll-Zeit“) müssen ca. 10 bis 12 h für die Erstellung des prozessorientierten Projektberichts eingeplant werden.

 

Liebe Grüße

[Saheeda]

@Rienne

Unsere IHK gibt so gut wie gar keine Informationen, was sie im Antrag haben will... (max. 8 h Doku (ohne Spezifikation welche) + Termine, that's it).

Dafür gibts 1 Seite Beschreibung, wie die Doku formell auszusehen hat.

 

Rein interessehalber:

Darf ich dich fragen, wie dann bei dir die Aufteilung/das Verhältnis zwischen Implementierung und Planung/Doku aussieht?

Bearbeitet 24. August 2016 von Saheeda

[Whiz-zarD]

vor 30 Minuten schrieb Rienne:

Du scheinst ja objektorientiert zu programmieren, wenn du Klassendiagramme anfertigst.

Da frage ich mich eher, wieso man keine abstrakte Basisklasse verwendet, wenn die generierten Klassen schon so repetitiv, sodass man sie mit einem Codegenerator generieren kann? Wäre dann nicht vielleicht der Einsatz eines O/R-Mappers sinnvoller?

Dokumentation ist sowieso so ein Thema für sich. Ja, in der Abschlussprüfung sollte man Wert drauf legen aber in der Praxis werden aber kaum Dokumentationen geschrieben. UML-Diagramme habe ich bis jetzt noch in keiner Softwareentwicklungsfirma gesehen. Klassendiagramme werden häufig dafür verwendet, um Abhängigkeiten festzustellen, die aufgelöst werden müssen oder um die Komplexität einer Klasse festzustellen. Also Dinge die man erst beim Refactoring braucht. Auch Ablauf- oder Sequenzdiagramme sieht man recht selten, weil die Abläufe der Software teils so komplex werden, sodass Diagramme nicht zu einer besseren Dokumentation beitragen und vereinfachte Diagramme, wie z.B. "Kunde drückt Button -> Server erstellt Report -> Server schickt Kunde den Report" braucht kein Mensch.

Von Testprotokollen halte ich auch sehr wenig. Was soll den protokolliert werden? Üblicherweise schreibt man Unittests. Soll man die Ergebnisse der Unittests ausdrucken? Also das alles Grün ist? Ich gehe auch nicht davon aus, dass die IHK prüft, ob auch sinnvoll getestet wurde. Sprich, ob man die Testpyramide bestmöglich einhält.

Ich halte die Vorgehensweise der IHK für sehr altmodisch. Auch das, was Rienne von der IHK zitert hat, hört sich für mich eher nach einem Wasserfallmodell an, wo schon vor der Implementierung klar ist, was und wie es implementiert werden soll. Das passt aber nicht zur heutigen agilen Softwareentwicklung und die Vorgaben der IHK sind mehr hinderlich als fördernd, weil sie ein völlig veraltetes Bild der Softwareentwicklung zeigen. Per Wasserfall hat man noch in den 80ern und 90ern entwickelt. Wer das heute noch tut ist auf dem Markt nicht mehr konkurrenzfähig, da der Markt sich rapide ändert und man muss mit diesen Änderungen klarkommen und das ist bei einem Wasserfallmodell nicht möglich und gerade durch das Wasserfallmodell entstehen solche Szenarien.

vor 2 Minuten schrieb Saheeda:

Mir wurde schon von mehreren Kollegen gesagt, dass es bei uns etwas spezieller und nicht unbedingt in anderen Firmen so üblich ist. Von daher wird es denke ich beim Verständnis helfen.

Also im Klartext: unwartbarer Legacy Code, der historisch gewachsen ist, bei dem Refactoring eine komplette Neuentwicklung bedeuten würde.  Wenn ich jedes Mal ein Cent bekommen würde, wenn ich höre, dass der Code speziell wäre, wäre ich schon Millionär.

[Rienne]

vor 30 Minuten schrieb Saheeda:

Darf ich dich fragen, wie dann bei dir die Aufteilung/das Verhältnis zwischen Implementierung und Planung/Doku aussieht?

Bei mir sieht die grobe Zeitverteilung wie folgt aus:

• Analyse/Definiton 13h
• Entwurfsphase 11h
• Implementierung/Tests 28h
• Doku/Abschluss 15h
• und (weil unsere IHK es verlangt, auch wenn ich es bescheiden finde) Puffer 3h

Aber ich muss auch gestehen, dass die Punkte

vor 15 Stunden schrieb Saheeda:

4.1 Armortisationsrechnung (1,0)

4.2 Wirtschaftlichkeitsbetrachtung (2,0)

4.3 Vergleich Ist- & Soll-Zustand (3,5)

bei mir in der Projektdoku mit inbegriffen sind und nicht explizit erwähnt werden - Wirtschaftlichkeitsbetrachtung und Amortisationsrechnung ist m.E. auch jeweils mit max. ner halben Stunde abgetan. Die Wirtschaftlichkeit sollte für mein Verständnis sowieso auch schon einmal vor dem eigentlichen Projektstart, also in der Analysephase, geprüft werden.

[Rienne]

vor 16 Minuten schrieb Whiz-zarD:

Dokumentation ist sowieso so ein Thema für sich. Ja, in der Abschlussprüfung sollte man Wert drauf legen aber in der Praxis werden aber kaum Dokumentationen geschrieben.

Aber genau darum geht es hier; um die IHK-Abschlussprüfung und nichts anderes. Klar, dass in der Realität vieles anders gehandhabt wird.

vor 17 Minuten schrieb Whiz-zarD:

Das passt aber nicht zur heutigen agilen Softwareentwicklung und die Vorgaben der IHK sind mehr hinderlich als fördernd, weil sie ein völlig veraltetes Bild der Softwareentwicklung zeigen.

Alleine die Vorgaben der IHK zwingen einen aber ja quasi schon dazu bei dem Abschlussprojekt nach dem Wasserfallmodell vorzugehen - feste Zeitvorgabe, man MUSS alleine arbeiten etc.

Wie willst du ein IHK Projekt z.B. nach SCRUM abschließen? Bist du dann Product Owner, Entwicklungsteam und Scrum Master in einem? Das widerspricht aber den Prinzip von Scrum.

Oder extreme Programming: Wo machst du dann sinnvoll den Schnitt was du geleistet hast und was nicht? Für die IHK muss ja direkt ersichtlich sein, was die Arbeitsleistung des Prüflings ist - und 10 Stunden neben jemanden sitzen, während dieser programmiert ist da sicherlich nicht gerne gesehen.

vor 23 Minuten schrieb Whiz-zarD:

UML-Diagramme habe ich bis jetzt noch in keiner Softwareentwicklungsfirma gesehen.

Also ich weiß von einigen Firmen, die sehr viel damit arbeiten. Gerade das Use-Case-Diagramm wird gerne genommen um in einfacher Weise mit dem Kunden die Vorstellungen vom Produkt abzustimmen.

vor 26 Minuten schrieb Whiz-zarD:

Von Testprotokollen halte ich auch sehr wenig. Was soll den protokolliert werden? Üblicherweise schreibt man Unittests. Soll man die Ergebnisse der Unittests ausdrucken? Also das alles Grün ist? Ich gehe auch nicht davon aus, dass die IHK prüft, ob auch sinnvoll getestet wurde.

Auch da arbeiten Firmen unterschiedlich. Wir haben eine Zertifizierung nach DIN EN ISO 9001 und müssen jede Entwicklung nach dem Sechs-Augen-Prinzip absegnen. Dazu gibt es dann z.B. auch ein Dokument, in dem das Ergebnis des Tests von einem, an der Entwicklung unbeteiligten, Testers festgehalten wird.

[Saheeda]

@Whiz-zarD

Zur Basisklasse: Die Struktur ist ähnlich, aber nicht die Felder/Eigenschaften, welche die generierten Klassen besitzen sollen.

Ich durfte die letzten Monate an einem Projekt arbeiten, bei dem diese Struktur nicht umgesetzt wurde ("brauchen wir nicht"). Änderungen DARAN waren Gefrickel und zogen Anpassungen an x Stellen nach sich.

Ich weiß nicht, welchen Mist du schon ausbaden durftest, aber dieses Konzept ohne Hintergrundwisen als unwartbar zu bezeichnen, finde ich n bisschen unfair. Vielleicht ist speziell auch einfach das falsche Wort dafür.

Ich möchte das jetzt nicht genauer erläutern, das würde an dieser Stelle zu weit führen, kann aber gern meine fertige Doku mit Bewertung hier reinstellen, wenn es soweit ist.

Bearbeitet 24. August 2016 von Saheeda