Abschlussprojekt FISI vs FIAE

[Daniel2]

Warum wird für das Abschlussprojekt des FISIs 35h und für das -projekt des FIAEs 70h einkalkuliert? Unterscheiden sich beide Prüfungen so weit vom Schwierigkeitsgrad?

[mapr]

Vielleicht, weil beim FIAE auch (viel) programmiert wird.

[Daniel2]

Ist das FIAE Abschlussprojekt komplexer und schwieriger als das FISI oder ist es halt nur der Zeitaufwand?

[Sullidor]

Nur der Zeitaufwand. Schau dich mal in den Prüfungsforen um. Da wirst du sehen, das es hochkomplexe Projekte beider Fachrichtungen gibt und ebenso relativ einfache Projekte beider Fachrichtungen.

Bearbeitet 10. Juli 2017 von Sullidor

[Crash2001]

Ein FIAE-Projekt ist meist etwas größer, da man innerhalb 35 Stunden, wenn man noch 8 Stunden Dokumentation plus irgendwelche Berechnungen / Auswertungen / Entscheidungen /Datenbankendesign usw. von der Zeit abzieht,  in rund 20 Stunden kein sinnvolles Programm schreiben kann, in dem man zeigen kann, was man drauf hat.

Von daher ist es durchaus mehr Arbeit, jedoch nicht zwingend komplexer.

Wie schwierig es ist, hängt immer von der Aufgabe ab und wie fit man in der Programmiersprache ist. Dem einen fällt es leichter, dem anderen schwerer.

[Gast ThoBi]

Jedoch denke ich schon, dass 35 Stunden für ein Abschlussprojekt zu wenig sind. Da braucht nur mal ein Bug auftreten, der selten ist und schon kann es sein, dass man 5 Stunden recherchiert oder der Chef sagt, dieses und jenes soll die Software auch noch können. Schnell ist man da bestimmt bei 100 Stunden.

[Crash2001]

Genau aus dem Grund gibt es ja vorher einen Antrag, in dem definiert werden soll, was genau gemacht werden soll. Da stehen dann die Anforderungen drin.
Chef kann ja gerne NACH DEM PROJEKT noch Anpassungen machen - diese gehören dann aber nicht mehr zum Projekt.
Dass Bugs oder sonstige Probleme auftreten können, ist ganz normal und sieht man in diversen Dokus auch recht gut. Damit muss man rechnen und entsprechende Puffer einplanen. Es ist eher selten der Fall, dass Projekte dann komplett scheitern. Ansonsten muss man die Zeit für Workaround suchen / Debugging halt außerhalb der Projektzeit machen.

[Fauch]

Man sollte auch nicht vergessen, dass m.E. nach in mindestens 80% aller Projekte der Zeitplan keinesfalls eingehalten wird und dann halt bei der Prüfung und in der Doku die Sache so hingedreht wird, das es passt.

 

[PhilipFISI]

Programmieren ist meistens etwas zeitaufwendiger als die Konfiguration von Systemen und wenn Probleme auftauchen, kann die Fehlersuche manchmal ziemlich lange dauern. Die Komplexität der Projekte ist meiner Meinung nach aber bei beiden Fachrichtungen gleich. Ich behaupte sogar, dass es FIAEs etwas leichter haben ein Projekt zu finden, weil es im Betrieb oft viele Vorgänge gibt, die man mit Programmen automatisieren könnte und woraus sich dann tolle Projekte bilden lassen. Das ist aber nur mein persönlicher Eindruck als FISI, ich kann mich auch irren.

[Crash2001]

Die Komplexität der Projekte ist nicht von FISI oder FIAE abhängig, sondern vom Projekt selber. Es gibt ziemlich einfache Projekte und es gibt hochkomplexe Projekte in beiden Fachrichtungen.

[Goulasz]

Moin moin!

An dieser Stelle grätsche ich kurz rein, um auf die notwendige Unterscheidung zwischen "Komplexität" und "Kompliziertheit" hinzuweisen.

Kompliziert

Eine Uhr ist ein kompliziertes System. Wenn sie kaputt geht, kann man mit entsprechendem Wissen kausale Verkettungen befolgen, um sie zu reparieren. Für einen Uhrmacher ist der Grad der Kompliziertheit des Systems "Uhr" geringer als für einen Laien.

Software ist immer kompliziert. Nie komplex. Jedes Problem in Software lässt sich auf einen kausal herleitbaren Grund zurückführen, so absurd es auch sein mag und so aufwändig die Fehlersuche auch ist. 

Komplex

Ein Unternehmen ist ein komplexes System. Es ist geprägt aus der Kommunikation der Teilnehmer am System. Es kann aufgrund der Psyche der Menschen im System zu Überraschungen kommen, die sich nicht vorhersagen und planen lassen. 

 

Wichtig ist daher eigentlich vor jedem Projekt die sogenannte "Problemtransformation", also die Zerlegung des Problems in komplizierte und komplexe Anteile. Komplizierte Anteile kann man in der Regel mit bestehendem oder noch zu erwerbendem Wissen bearbeiten. Für komplexe Anteile benötigt es Ideen, die idealerweise in (kurzen) iterativen Zyklen erprobt werden müssen.

Viele "Projekte", die durchgeführt werden, sind eigentlich gar keine Projekte, sondern Prozesse, die sich mit bestehenden Lösungen (teils mit Anpassung) eigentlich lösen lassen. 

Fußball beispielsweise ist komplex, da man als Spieler nie weiß, wie die Gegenspieler reagieren. Daher kann man nicht mit einem "Plan" an ein Fußballspiel herangehen. Wie absurd wäre es, wenn ein Thomas Müller wie in einer Mitarbeiter-Zielvereinbarung sagt: "Ich möchte in der 34ten Minute aus 14 Metern Entfernung mit dem rechten Fuß ins linke obere Eck treffen."

Stattdessen wird sich eine Strategie für das Spiel zurechtgelegt, die auf der Analyse des Gegners und der eigenen Stärken und Schwächen basiert. Diese bietet genug Raum zur Anpassung. 

Dazu im Anhang die "Denkzettel" zur Unterscheidung "Chaos und Dynamik" und zur "Problemtransformation" aus "Denkwerkzeuge der Höchstleister" (das Buch habe ich hier im Blog auch vorgestellt) von Gerhard Wohland und Matthias Wiemeyer.

Gruß, Goulasz  

 

Denkzettel1-Chaos-und-Dynamik.pdf

Denkzettel13-Problemtransformation.pdf

[Whiz-zarD]

vor 9 Stunden schrieb Fauch:

Man sollte auch nicht vergessen, dass m.E. nach in mindestens 80% aller Projekte der Zeitplan keinesfalls eingehalten wird und dann halt bei der Prüfung und in der Doku die Sache so hingedreht wird, das es passt.

Ich denke, dass dies sogar noch sehr optimistisch ist. Ich gehe davon aus, dass nahezu 100% aller Projekte den Zeitplan nicht einhalten. Ich halte sowieso nichts von exakter Stundenangabe, wie lange man für eine Tätigkeit benötigt. Der Zeitplan sollte lediglich nur ein Indiz sein, dass man das Projekt auch in der Zeit schaffen kann und eine gewisse Komplexität aufweist. In der Ausbildungsverordnung steht ja auch folgender Satz drinnen:

Zitat

in der Fachrichtung Anwendungsentwicklung in insgesamt höchstens 70 Stunden für die Projektarbeit einschließlich Dokumentation

(Analog für die FISIs)

Laut Ausbildungsverordnung dürfen es sogar auch weniger sein. Es dürfen nur die 35/70 Stunden nicht überschritten werden. Die IHK sieht es aber anders, denn da müssen es exakt 35/70 Stunden sein, was aber eigentlich nicht stimmt. Da sieht man auch recht deutlich, dass man es hier überwiegend mit Bürokraten zu tun hat.

vor 42 Minuten schrieb Goulasz:

Fußball beispielsweise ist komplex, da man als Spieler nie weiß, wie die Gegenspieler reagieren. Daher kann man nicht mit einem "Plan" an ein Fußballspiel herangehen. Wie absurd wäre es, wenn ein Thomas Müller wie in einer Mitarbeiter-Zielvereinbarung sagt: "Ich möchte in der 34ten Minute aus 14 Metern Entfernung mit dem rechten Fuß ins linke obere Eck treffen."

Das gilt auch für die Softwareentwicklung. Niemand kann im Vorwege sagen, dass eine Implementierung einer Lösung exakt 20 Stunden dauert. Auch in der Softwareentwicklung entwickelt man Strategien, um ein Problem zu lösen. Ob die Strategien aufgehen oder ob man noch Gegensteuern muss, weiß man im Vorwege nicht. Darum gibt es ja seit über 15 Jahren den Ansatz der agilen Softwareentwicklung, wo man eben in Iterationen arbeitet und schnell Feedback bekommt. Dieses Verfahren ist aber durch die IHK in der Abschlussprüfung gar nicht möglich, da die exakten Stunden einzuhalten sind, die man vorher beim Einreichen des Projektes festgelegt hat. Abweichungen sind zwar Möglich aber müssen später begründet werden und können ggf. nachteilig in die Benotung einfließen.

Bearbeitet 28. Juli 2017 von Whiz-zarD

[Goulasz]

Hallo @Whiz-zarD!

Ich sage nicht, Softwareentwicklung ist nicht komplex. Ich habe gesagt "Software" ist nie komplex.

Zu den anderen Punkten gebe ich dir natürlich recht. Der Prozess der Entwicklung einer Lösung, die zu den (sich im Projekt oft mal ändernden) Kundenbedürfnissen passt, ist in den seltensten Fällen nur kompliziert.

Die einzigen Fälle, die mir einfallen, in denen Softwareentwicklung wirklich überwiegend kompliziert ist, sind vermutlich die Entwicklung von Systemen in kritischer Infrastruktur, die gewissen Vorgaben nach Gesetz genügen muss und wenig Spielraum hat, was das tatsächliche Ergebnis angeht. Aber da kann @a3quit4s ggfs. etwas aus dem Nähkästchen plaudern.

Ich kritisiere diesen Umstand für Abschlussprojekte auch massiv. Zum einen bin ich der Meinung, sowohl 35 als auch 70 Stunden reichen bei weitem nicht aus. Zum anderen sind die Vorgaben viel zu eng, um das, was der Azubi im Projekt eigentlich zeigen soll, nämlich das vorbereitet sein auf das Berufsleben, zu ermöglichen.

Eine Überarbeitung des Projektes halte ich für dringend notwendig. Die Wahl der Projektmanagement-Methode sollte dem Azubi in Hinblick auf sein zu lösendes Problem überlassen bleiben. Das setzt natürlich voraus, dass man sich zumindest rudimentär mit diesen Methoden(Wasserfall, PRINCE2, SCRUM, KANBAN, etc.) im Vorfeld auseinandersetzt. Sowohl in der Theorie als auch in der Praxis.

Gruß, Goulasz  

[Fauch]

vor 19 Minuten schrieb Whiz-zarD:

Ich denke, dass dies sogar noch sehr optimistisch ist. Ich gehe davon aus, dass nahezu 100% aller Projekte den Zeitplan nicht einhalten. Ich halte sowieso nichts von exakter Stundenangabe, wie lange man für eine Tätigkeit benötigt. Der Zeitplan sollte lediglich nur ein Indiz sein, dass man das Projekt auch in der Zeit schaffen kann und eine gewisse Komplexität aufweist. In der Ausbildungsverordnung steht ja auch folgender Satz drinnen:

Ganz deiner Meinung. Ich wollte nur vermeiden, dass sich dann gleich 4-5 Leute melden die sich auf den Schlips getreten fühlen.

Aber ja, die Komplexität, die die IHK gern sehen würde, ist m.E. in 70 Stunden (mit Planung, Doku, Testen, usw.) fast nicht leistbar, es sei denn, das Projekt läuft in einem thematischen Umfeld ab, in dem der Azubi tatsächlich auch mehrjährige Erfahrung hat. 

Und selbst hier wird's dann noch sehr eng.

[a3quit4s]

vor 11 Minuten schrieb Goulasz:

Die einzigen Fälle, die mir einfallen, in denen Softwareentwicklung wirklich überwiegend kompliziert ist, sind vermutlich die Entwicklung von Systemen in kritischer Infrastruktur, die gewissen Vorgaben nach Gesetz genügen muss und wenig Spielraum hat, was das tatsächliche Ergebnis angeht. Aber da kann @a3quit4s ggfs. etwas aus dem Nähkästchen plaudern.

Die Regularien zur Speicherung und Verarbeitung personenbezogener Daten in der Arzneimittelforschung nach amerikanischem Recht sind milde ausgedrückt Schmerzen infernalen Ausmaßes im Hintern. 

[neinal]

vor 7 Minuten schrieb a3quit4s:

Die Regularien zur Speicherung und Verarbeitung personenbezogener Daten in der Arzneimittelforschung nach amerikanischem Recht sind milde ausgedrückt Schmerzen infernalen Ausmaßes im Hintern. 

Du sollst die Daten ja auch nicht in deinem Hintern speichern

 

Aber zum Thema:

Die Projekte sind unterschiedlich komplex. Egal ob AE oder SI. Das kommt auch immer darauf an, was der Azubi daraus macht bzw. was im Betrieb gerade so ansteht.

Dass die Angabe der IHK in den meisten Fällen nicht zu erfüllen sind, weiß fast jeder. Schade ist nur, dass durch die Angabe der Stunden auch Projekte beantragt werden, die nicht komplex genug sind um die IHK zu befriedigen.

Aber irgendeine Angabe braucht man halt. Dass in der Praxis einiges anders läuft, ist ja nicht nur bei der IHK Prüfung der Fall.

[Crash2001]

Am ‎28‎.‎07‎.‎2017 um 10:08 schrieb Goulasz:

[...]Ich sage nicht, Softwareentwicklung ist nicht komplex. Ich habe gesagt "Software" ist nie komplex.[...]

Wieso ist Software nie komplex? Das kann auch ein Zusammenspiel von diversen Programmen oder Schnittstellen sein. Gut - es gibt normalerweise immer einen vorgegebenen Weg, wie die Software mit dem Input umgeht, aber das kann durchaus ja auch von Usereingaben abhängen. Die Usereingaben kann die Software ja nicht wirklich vorhersehen, sondern sie kann nur verschiedene Optionen anbieten und dann die vordefinierten Programmteile aufrufen.
Vergleicht man das mit Fußball, kann der Spieler z.B. nach links oder rechts laufen, den anderen Spieler foulen, oder sich zurückziehen, wenn der andere Spieler vor einem steht ( rennt). Das sehe ich genauso als Optionen an, wie bei einer Usereingabe, nur dass Auswirkungen der Entscheidung halt dann nicht durch einen Rechner durchgeführt werden, sondern durch einen Menschen. Dass sich aus jeder Aktion eine Reaktion ergibt, ist beim Programm ja auch so - vielleicht nicht so komplex, da oftmals nicht so viele "Teilnehmer" an dem Prozess teilnehmen, aber irgendwie komplex ist Software in meinen Augen dann doch schon. Sie reagiert auf Input mittels vordefinierter Reaktionen). Monitoring wäre z.B. ein gutes Beispiel dafür. Für komplexe Sachen muss man etwas können. Das Können wird der Software doch programmiert, dass sie bestimmte Probleme lösen kann.

Die Problemlösung komplexer oder komplizierter Probleme ist ja nicht abhängig von Intelligenz, sondern von Wissen und Können und beides kann man einem Programm doch "beibringen".

Wissen => Datenbank mit Informationen und evtl. "Handlungsanweisungen".
Können => entsprechende Prozeduren im Programm).

[Goulasz]

Hallo @Crash2001!

vor einer Stunde schrieb Crash2001:

[...]Gut - es gibt normalerweise immer einen vorgegebenen Weg, wie die Software mit dem Input umgeht, aber das kann durchaus ja auch von Usereingaben abhängen.[...]

Mit diesem einen Satz bringst du es eigentlich auf den Punkt und hättest dir den Rest deiner Ausführung sparen können.  

Ich führ es dennoch mal aus, weil der Nuget-Server grade lahmt und ich Lust&Zeit habe.

---

Lassen wir künstliche Intelligenz mal außen vor, das würde den Sachverhalt unnötig verkomplizieren.

In den anderen Fällen kann ein System nur mit dem Satz an Regeln umgehen, den du ihm vorgibst.

Natürlich kann die Software nicht vorhersehen, welcher Nutzerinput kommt. Muss sie aber auch nicht. Auf bestimmte Eingaben ist Software durch den zugrunde liegenden Code eingestellt, auf andere nicht. Die können entweder aufgrund der der Programmiersprache/-architektur implizit innewohnenden Technik trotzdem korrekt verarbeitet werden, oder eben nicht. Aber selbst der Ausgang "kann nicht verarbeitet werden (und wirft Exception)" ist für eine bestimmte Menge nicht definierter Eingaben ein Vorgegebener.

Es bleibt "kompliziert". Denn auch wenn das Element der Nutzereingabe nicht vorhersehbar ist, für die Verarbeitung vorgegebener Eingaben gibt es ausschließlich endliche Möglichkeiten. Dass der Begriff "komplex" in diesem Zusammenhang so gerne benutzt wird, liegt meiner Einschätzung daran, dass die wenigsten Menschen (mich eingeschlossen) den Grad der Kompliziertheit der Software(-Systeme), die sie benutzen, zu 100% erfassen können. 

vor einer Stunde schrieb Crash2001:

[...]Das sehe ich genauso als Optionen an, wie bei einer Usereingabe, nur dass Auswirkungen der Entscheidung halt dann nicht durch einen Rechner durchgeführt werden, sondern durch einen Menschen.[...]

Der entscheidende Unterschied zwischen deiner Fußball-Analogie und Software ist, dass so viele verschiedene Faktoren auf den Menschen Einfluss haben, dass nie 100%-ig vorhersehbar ist, welchen Reaktion eine Aktion hervorruft. 

Software wird unter absolut gleichen Umständen immer gleich reagieren. 

Ein Mensch befolgt im Gegensatz zu Software keinen vorgegebenen Plan, sondern trifft in diesem Fall eine Entscheidung. Das Wählen einer Option aus einer vorgegebenen Menge an Optionen unterscheidet sich drastisch von einer Entscheidung, bei der man im Gegensatz zur Wahl nicht in Gänze weiß, was die Konsequenzen sind.

vor einer Stunde schrieb Crash2001:

[...]Wissen => Datenbank mit Informationen und evtl. "Handlungsanweisungen".
Können => entsprechende Prozeduren im Programm).[...]

Das ist so nicht ganz korrekt. Im Programm geschriebene Prozeduren sind ebenso wie in einer Datenbank hinterlegte Daten Wissen. Nämlich Wissen, wie man auf bestimmten Input reagieren soll. Wenn dein Programm zur Laufzeit selbst ohne speziell dafür geschriebenen Code "entscheiden" könnte, wie es auf bestimmte Aktionen reagiert oder selbst laufen lernt, wäre das "Können". Aber da sind wir wieder bei KI, und da bin ich mir ähnlich wie beim Wetter selbst noch nicht ganz sicher, ob es sich da um eine überwiegend komplexe oder komplizierte Domäne handelt.

Gruß, Goulasz  

P.S.: In einer Datenbank liegen auch keine Informationen vor, sondern Daten. Informationen entstehen beim Aufnehmen und Verarbeiten durch Rezipienten. Gleiche Daten können bei unterschiedlichen Rezipienten und unterschiedlichem Kontext unterschiedliche Informationen erzeugen.

[Crash2001]

Man kann auch einer Maschine beibringen, Fußball zu spielen - und das noch nicht einmal so schlecht. Klar, dass eine Maschine anders spielt, aber Fußball spielen kann sie dennoch. Somit ist dann Fußball entweder nicht komplex, oder aber im Umkehrschluss könnte eine Maschine / Software auch komplex sein. Oder aber die Definition ist einfach falsch / ungenau.

Genauso kann auch durch z.B. Bugs oder Hardwaredefekte), oder Einspeisungen von Fehlerströmen ein komplexes (unvorhersehbares) Verhalten hervorgerufen werden - vor allem, falls mit mehreren anderen Systemen interagiert wird.

Von daher sehe ich es einfach anders, dass Software nicht komplex sein könnte.

Also ich denke einfach, dass der Übergang fließend ist und nicht genau definiert. Es wird bei Unterscheidungen immer beschrieben, dass man komplizierte Sachen mittels Wissen lösen kann und komplexe Sachen anhand Könnens. Können bedingt aber teilweise Wissen, wenn man mal vom Gefühl absieht (nach Bauchgefühl entscheiden). Wobei eine Maschine natürlich nicht eigenständig entscheidet, dass sie jetzt Fußball spielen will - aber das machen Profifußballspieler auch nicht immer unbedingt... wobei der Mensch immer noch entscheiden kann, es doch nicht zu tun...  

Das mit der Datenbank ist mir klar, dass das Wissen in den Daten vorhanden ist und entsprechend ausgewertet werden muss, wenn es in einer Datenbank hinterlegt ist.
 

vor 2 Stunden schrieb a3quit4s:

Lies doch die Definition der beiden Begriffe nochmal und wenn du den Unterschied dann noch nicht verstehst liest du sie noch ein drittes oder viertes Mal.

Gaaaanz toller und hilfreicher Beitrag. Solche Leute liebe ich ja, die solche Ansichten haben... danke dafür...
Den Beitrag hättest du dir auch sparen können. Nur weil ich vielleicht weiter denke als du, oder mir die Definition einfach nicht genau genug ist, da ich auch mal Sachen hinterfrage und nicht alles für gegeben hinnehme, bin ich nicht dämlich.

Bearbeitet 31. Juli 2017 von Crash2001

[Goulasz]

Hallo @Crash2001!

Du vermischst hier meiner Einschätzung nach Inhalte und Sachverhalte.

Es geht bei der Unterscheidung um kausale Durchgriffe in Systemen. Ein Fehler in einem hochkomplizierten Softwaresystem wird sich reproduzieren lassen, solange die Umgebung zum Zeitpunkt der Reproduktion die gleiche ist wie beim ursprünglichen Vorfall. Bei einem Fußballspieler geht das nicht mit Sicherheit. Die Wahrscheinlichkeit, bei gleichen Umständen gleiche Ergebnisse zu erhalten ist hoch, aber nicht 100%-ig. Der wird sich in einer Situation vielleicht genau so entscheiden wie beim letzten Spiel, vielleicht aber auch nicht. Ganz einfach, weil schon Zeit vergangen ist seit dem letzten mal und mindestens der Faktor der menschlichen Psyche (noch) nicht zu 100% einberechenbar ist.

vor 20 Minuten schrieb Crash2001:

[...]Genauso kann auch durch z.B. Bugs oder Hardwaredefekte), oder Einspeisungen von Fehlerströmen ein komplexes (unvorhersehbares) Verhalten hervorgerufen werden - vor allem, falls mit mehreren anderen Systemen interagiert wird.[...]

Das ist dann aber nicht komplex, sondern kompliziert. Das Verhalten ist bei vollständiger Kenntnis der Systeme vorhersehbar, bzw. kausal rückverfolgbar. Das meinte ich mit: 

vor 2 Stunden schrieb Goulasz:

[...]Dass der Begriff "komplex" in diesem Zusammenhang so gerne benutzt wird, liegt meiner Einschätzung daran, dass die wenigsten Menschen (mich eingeschlossen) den Grad der Kompliziertheit der Software(-Systeme), die sie benutzen, zu 100% erfassen können.[...]

Das Einbringen weiterer Faktoren in so ein System erhöht nur den Grad der Kompliziertheit, führt aber nicht zu "Komplexität". Denk nochmal zurück an mein Beispiel mit dem Uhrmacher. Oder an die Challenger-Katastrophe. Alles hochkomplizierte Systeme, die oft für Experten noch herausfordernd sind. Aber die "Überraschungen" sind keine wirklichen Überraschungen, sondern aufgrund fehlenden Wissens oder versehentlicher Nicht-Beachtung geschehene Fehler, die sich am Ende auf eine oder mehrere klar definierte Fehlerquellen zurückführen ließen.

Es geht mir auch nicht um das "Fußball Spielen" an sich. Klar kann ein Roboter Fußball spielen, wenn du ihm die notwendigen Bewegungsabläufe beibringst. Und wenn du ihn mit Sensoren vollpackst, wird er vielleicht auch einen ordentlichen Spielüberblick haben und "Fußball spielen" können. Das, was man allgemein als "Chemie" oder "Intuition" in einer Mannschaft bezeichnet, wird ihm aber fehlen.

Bei einem von Menschen bestrittenen Fußballspiel spielen aber so viele Faktoren ins Spiel mit ein, die eben nicht kausal herleitbar oder rückverfolgbar sind. Wenn dem so wäre, müsste ja jedes Spiel Mannschaft A gegen Mannschaft B bei gleicher Aufstellung und gleichem Zustand der Spieler gleich ausgehen. 

Gruß, Goulasz  

P.S.: @Mods: Ich habe das Gefühl, wir kapern das Thema hier ein wenig. Wenn es Sinn ergibt, lagert die entsprechenden Postings einfach aus.

Bearbeitet 31. Juli 2017 von Goulasz

[charmanta]

könnt Ihr bitte mal wieder zum Thema zurückfinden ? Der Stil lässt ein wenig zu wünschen übrig und persönliche Dinge gehören hier nicht rein. Ich gehe davon aus dass hier jeder grundsätzlich lesen kann und für "dämliche" Leute gibt es sicher interessantere Seiten...