www.mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Ingenieure und Softwareentwicklung


Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

langsam bekomme ich den Eindruck, dass 95% der Ingenieure von 
Softwareentwicklung keine Ahnung haben.

Eine Unsitte die mich besonders nervt ist das Verteilen von losen, 
unversionierten Dateien per USB-Stick. Da lässt man einen Diplomanden 
z.B. mit irgendwelchen vorverarbeiteten Messdaten arbeiten. Wochen 
später merkt man dass etwas mit den Daten nicht stimmt, und dann wird 
gerätselt mit welcher Softwareversion und welchen Parametern die Daten 
wohl erstellt wurden und was dabei schief gegangen sein könnte (die 
Originale gammeln auf irgendwelchen USB-Platten vor sich hin und werden 
gelöscht wenn gerade kein Platz mehr da ist). Oder es werden 
Skriptsammlungen herumgereicht, jeder bastelt seine Erweiterungen dazu, 
und am Ende (falls die Zweige denn überhaupt wieder zusammenfinden) ist 
vieles doppelt und passt nichts mehr zusammen. Vom eigentlichen 
Programmierstil will ich gar nicht reden.

Die IT-Abteilung betreibt einen SVN-Server, aber ich kenne hier 
(forschungslastige Abteilung) keinen der ihn benutzt, und kaum einen der 
weiß was SVN überhaupt ist. Ich denke mir jedes Mal, wie wunderbar 
einfach viele Dinge würden, wenn man einfach sagen könnte "schau in 
blafoo/branches/user123, da hab ich ein paar Bugs gefixed" oder 
"aktualisier dir die Daten aus mess/xyz, die Verarbeitung wurde 
geändert"...

Wie sind eure Erfahrungen? Geht es bei euch auch manchmal so planlos zu?

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja.

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein.

Aus Deinem Post, war der Satz

> Vom eigentlichen
> Programmierstil will ich gar nicht reden.

das einzige was mit Softwareentwicklung zu tun hat. Alles andere ist 
Organisation, Versionierung etc. hat aber mir der eigentlichen 
Entwicklung nichts am Hut.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier (große Firma aus dem Bereich Schienenverkehrstechnik, lauter 
Elektroingenieure) wird eine zehn Jahre alte Version von Microsoft 
Visual Source Safe benutzt. Ach nein, sie wird gar nicht wirklich 
konsequent genutzt, vielmehr werden die Dateien meistens auf dem 
Netzlaufwerk abgelegt in einem Ordner mit der Versionsnummer.
Warum man nicht was Vernünftiges macht wie Subversion mit z.B. 
TortoiseSVN als Client, versteh ich auch nicht. Aber es ist wohl so wie 
Du sagst, die Ingenieure die keine Vorlesungen über Softwaretechnik etc. 
hatten gehen da wohl eher planlos vor, es sei denn sie haben zuvor schon 
mal in einer Firma gearbeitet, in der es richtig anstatt falsch gemacht 
wird ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn so gearbeitet wird, ist aber nicht nur der Ing schuld,
sondern auch die Ebene drüber, die das offenbar toleriert.

Selbst eine halbwegs ordentliche Bude achtet auf Versionierung,
Backup etc. und treibt ihre Leute notfalls dahin.

Auch wenn der einzelne Entwickler schon eine Nase dafür haben
sollte und es notfalls auf eigene Faust sinnvoll handhabt,
gehören diese elementaren Dinge firmenweit einheitlich
eingeführt. Ein SVN-Server, der mehrheitlich ignoriert wird,
deutet doch m.E. auf eine planlose Führung hin.

Autor: Nephazz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich studiere E-Technik in Gießen höre gerade eine Vorlesung namens 
"Softwaretools und -management". Der Dozent ist als Gast an der FH und 
arbeitet bei Conti. Die haben diese Probleme nicht, wegen DOORS und 
anderen Programmen. Versionsverwaltungen sind wohl recht schwierig 
einzuführen, der Dozent wird nach eigenen Angaben aber bei keiner Firma 
mehr anfangen, die keine verwendet.

Hier sind die Folien:
http://freenet-homepage.de/SWT_2009/

Autor: Nephazz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso ... gerade DOORS wurde bei Conti vom Quali-Management eingeführt 
und nur durch Druck dann auch eingesetzt. Ist wohl das selbe Problem wie 
mit Doku, schätze ich. Niemand machts gern aber wenn es fertig ist 
extrem hilfreich.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Wenn so gearbeitet wird, ist aber nicht nur der Ing schuld,
> sondern auch die Ebene drüber, die das offenbar toleriert.

Richtig.

> Selbst eine halbwegs ordentliche Bude achtet auf Versionierung,
> Backup etc. und treibt ihre Leute notfalls dahin.

Kann durchaus unterschiedlich sein, in der einen Abteilung so und in der 
anderen so. Je höher die Informatikerdichte, desto größer ist die 
Wahrscheinlichkeit, dass die Versionsverwaltung vernünftig gehandhabt 
wird.

> Auch wenn der einzelne Entwickler schon eine Nase dafür haben
> sollte und es notfalls auf eigene Faust sinnvoll handhabt,
> gehören diese elementaren Dinge firmenweit einheitlich
> eingeführt. Ein SVN-Server, der mehrheitlich ignoriert wird,
> deutet doch m.E. auf eine planlose Führung hin.

Wenn die Gruppenleiter und der Abteilungsleiter halt allesamt keine 
"richtigen" Software-Menschen sind... und die IT an sich outgesourcet 
wurde... dann hängt es teilweise von der Initiative eines fähigen 
Mitarbeiters ab, der seinen Chef überzeugen kann, hab ich so den 
Eindruck.

Autor: Panzer H. (panzer1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier wurde vor kurzem entschieden, kein DOORS zu verwenden.
Kostet ja Geld...
Firma: weltweit tätiger Blechbieger mit Elektronikanteil. ;-)
Produkte stehen in jedem Haushalt.

Autor: Ingenör (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>langsam bekomme ich den Eindruck, dass 95% der Ingenieure von
>Softwareentwicklung keine Ahnung haben.

langsam bekomme ich den Eindruck, dass das Schubladendenken enorm 
zunimmt und immer mehr solche unqualifizierten Threads kommen.
Mal gehts um BWLer, mal um FH vs. Uni, dann wieder um Informatiker.
Solche Pauschalaussagen sind völlig unnötig und werden Dich in Deiner 
Laufbahn nur behindern, da Du schon gar nicht mehr unvoreingenommen auf 
jemanden zugehen kannst.


Zum Threadersteller:
Ingenieure können programmieren und Informatiker wollen programmieren. 
(scnr)
Informatiker wollen aber auch eine schöne bunte IDE mit Hilfe und 
Autovervollständiung um eine Mickey Mouse Oberfläche zu basteln.
Es kommt halt immer drauf an was man -die Firma- braucht.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aus Deinem Post, war der Satz
>
>> Vom eigentlichen
>> Programmierstil will ich gar nicht reden.
>
>das einzige was mit Softwareentwicklung zu tun hat. Alles andere ist
>Organisation, Versionierung etc. hat aber mir der eigentlichen
>Entwicklung nichts am Hut.

Das ist der weit verbreitete Irrtum, durch den dieses Problem überhaupt 
erst entsteht. Das Schreiben von Code ist nur ein kleiner Teil der 
Softwareentwicklung. Genauso wie das Zusammenschrauben von Trägern nur 
ein kleiner Teil der Brückenkonstruktion ist.

> Solche Pauschalaussagen sind völlig unnötig

Ich habe keine Pauschalaussagen gebraucht, sondern eine Prozentzahl die 
den gefühlten Anteil des o.g. Problems deutlich machen soll. Ich bin 
selbst Ingenieur, und würde mich als recht fähig im Bereich der 
Softwareentwicklung bezeichnen.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:

> Das ist der weit verbreitete Irrtum, durch den dieses Problem überhaupt
> erst entsteht. Das Schreiben von Code ist nur ein kleiner Teil der
> Softwareentwicklung.

Das ist der weit verbreitete Irrtum, wegen dem meist trotz toller 
Prozesse am Ende doch nur instabiler Mist rauskommt.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingenör schrieb:

> Zum Threadersteller:
> Ingenieure können programmieren und Informatiker wollen programmieren.
> (scnr)

Da stimmt nur der erste Teil bedingt. Als Informatiker hielt man sich 
schon damals Programmierer, oder - wenn es die nicht gab - E-Techniker.

Ein guter Info ist für's Coden viel zu schade.

Informatik hat mit Programmierung fast nichts zu tun.

Chris D.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter: warum scheitern so viele Softwareprojekte? Weil die Programmierer 
den Unterschied zwischen Bubblesort und Quicksort nicht kennen? Oder 
nicht doch eher, weil
- die Anforderungen unklar sind
- das Gesamtkonzept nichts taugt
- die Abstimmung nicht funktioniert
- zu wenig Zeit zum Testen eingeplant wird
- usw.?

Ein Projekt kann schon vermurkst sein, bevor auch nur eine einzige Zeile 
Code geschrieben ist. Und dann kann auch der beste Programmierer nichts 
mehr herausholen.

Autor: rme (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt es ein interessantes Video zum Thema Software-Engineering, bei 
dem auch auf die angesprochenen Punkte eingegangen wird:

http://www.ulm.ccc.de/ChaosSeminar/2007/07_Softwar...

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@gast

Das gilt nicht nur für die Softwareentwicklung.
Ich habe graue Haare bekommen, als ich versucht habe herauszufinden, was 
in einem Prototypenprojekt zurzeit verbaut ist 
(Hardware+Softwarestand)und dazu minimale technische Angaben, 
Typenschild hätte meist gereicht.

Selbst die Teileverantwortlichen konnten mir meist keine vernüftigen 
Angaben machen.
Ein einfaches, es ist A von B Typ C eingebaut zurzeit ändert sich die 
Software in der Erprobungfast täglich, Hardwareunterlagen liegen auf 
Laufwerk X: hätte erstmal gereicht.

Das ist für eine technische Abnahme sehr hilfreich.

In DOORS habe ich mal reingeschaut, soll genutzt werden, keiner kennt 
sich damit aus oder weiss wie es genutzt werden soll.

In den vielen Firmen geht es so chaotisch zu, weil es an 2 einfachen 
Dingen fehlt, der richtigen Kommunikation und Dokumentation.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eingendlich basiert alles auf einem ganz einfachen Schema :

Firmen, Vorgesetzte , Kollegen müssen begreifen, dass das heutige 
Programmieren nicht mehr mit dem aus den 70er/80er Jahren zu vergleichen 
ist. Es ist halt auch eine Wissenschaft, bei dem die Ergebnisse nicht 
vom Zufall abhängen sondern hart erarbeitet werden müssen. Weiterhin 
stellt Software "Firmenkapital" dar, welches durch 
Versionkontrollsystemen gesichert werden muss.

Doch solange der Software (bzw. den Programmierern) nicht die nötige 
Entwicklungszeit  Testzeit  Dokumentationszeit zugestanden wird. 
Werden immer irgendwelche "Schnellschüsse" herausgegeben. Oft liegt das 
Problem weniger am Softwerker als vielmehr an den Randbedingungen.

Wer kennt das nicht, eine "unfertige" Hardware wird einbehalten, bei 
einer fertigen Hardware mit unfertiger Software gibt´s ne Freigabe. Es 
kann ja "nachgeflashed" werden.

Autor: berndl (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...nur weil's so schoen hier her passt :o)

Alt, aber gut!

Autor: ingFH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, man muss halt gute Ideen durchsetzen im schlimmsten Fall erzwingen 
können. Kann mir die Arbeit ohne SVN nicht mehr vorstellen, vor allem, 
wenn mehrere Leute an einem Projekt arbeiten. Wer es nicht tut, verliert 
Zeit und Zeit ist Geld.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:

> Peter: warum scheitern so viele Softwareprojekte? Weil die Programmierer
> den Unterschied zwischen Bubblesort und Quicksort nicht kennen? Oder
> nicht doch eher, weil
> - die Anforderungen unklar sind
> - das Gesamtkonzept nichts taugt
> - die Abstimmung nicht funktioniert
> - zu wenig Zeit zum Testen eingeplant wird
> - usw.?

Na, wenn wir uns davon aufhalten liessen, wuerden wir ja gar kein 
Projekt fertig kriegen.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann dem voll zustimmen. Bin Elektrotechnik Ingenieur. Arbeite seit 
ca. 1Jahr als Softwareentwickler bei einem mittelständigen Unternehmen. 
Hier geht genauso so ab wie einige beschrieben haben. Arbeite mit 
Informatikern zusammen. Die können zwar richtig gut programmieren, aber 
aber keinerlei Ahnung von Softwareentwicklung. Nach 1 Jahr konnte ich 
durchsetzten, das SVN mit allem drum und dran eingeführt wird.

Was ich mir immer bei diesem Kampf anhören musste --> Wir sind kein 
Softwarehaus sondern ein Maschinenbau Unternehmen. Jemand hat es schon 
geschrieben, die Programmierung aus den 80er hat mit der heutigen nichts 
mehr viel gemeinsam, nur sieht das die entsprechende Ebene nicht.

Mein bestes bis jetzt:
Chef: Wir brauchen in der Tabelle eine neue Spalte, das haben sie doch 
in 2 min drinne.
Ich: Das ist doch kein Excel!

Jeder der schon mal in Java Tabellen programmiert hat, weiß von was ich 
spreche.

Das Problem ist einfach, das die entsprechenden Vorgesetzten einfach 
nicht so die Ahnung davon haben und sagen Dinge zu die in Ihrer Zeit 
nicht realisierbar sind...

Aber scheint bei vielen so zu sein

Autor: Softwareentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein.

Aus Deinem Post, war der Satz

> Vom eigentlichen
> Programmierstil will ich gar nicht reden.

> das einzige was mit Softwareentwicklung zu tun hat. Alles andere ist
> Organisation, Versionierung etc. hat aber mir der eigentlichen
> Entwicklung nichts am Hut.

> Das ist der weit verbreitete Irrtum, durch den dieses Problem überhaupt
> erst entsteht. Das Schreiben von Code ist nur ein kleiner Teil der
> Softwareentwicklung.

> Das ist der weit verbreitete Irrtum, wegen dem meist trotz toller
> Prozesse am Ende doch nur instabiler Mist rauskommt.

Mein Gott. Das ist doch ganz einfach:
Es gibt Programmierer. Das sind die, die einen Code zusammenkloppen 
können der dann auch meist läuft.

Und es gibt Softwareentwickler. Das sind die, die einen Code 
zusammenkloppen können der dann auch meist läuft und für andere lesbar 
ist. Die sich mit Versionierung, Dokumentation, Organisation auskennen 
und im Team an größeren Softwareprojekten einsetzbar sind.

Programmieren hab ich im Elektrotechnikstudium gelernt. 
Softwareentwicklung erst danach in einem großen internationalen 
börsennotierten Softwarekonzern.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Doch solange der Software (bzw. den Programmierern) nicht die nötige
>Entwicklungszeit  Testzeit  Dokumentationszeit zugestanden wird.
>Werden immer irgendwelche "Schnellschüsse" herausgegeben. Oft liegt das
>Problem weniger am Softwerker als vielmehr an den Randbedingungen.

Jaja, und wenn man dann mehr Zeit hat, wird die für Dokumetation genutzt 
?

Wovon träumst Du eigentlich nachts ?  Die Vorstellung, dass zusätzliche 
Zeit plötzlich für Dokumentation genutzt würde, ist doch abenteuerlich.

Hatte übrigends mal ein interressantes Jobangebot, nachdem ein Kunde 
mich gesehen hat, wie ich während der Kompilierung (dauerte etwa eine 
Stunde) eines Projektes an der Doku gearbeitet habe. Alle anderen waren 
Kaffee trinken. Der wollte mich sofort abwerben.

Gruss
Axel

Autor: Klaus2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...wer ernsthaft SW entwickeln will kommt ohne DOORS und SVN (o.ä.) 
einfach nicht aus. Und der Rest entwickelt nicht ernsthaft :) So beka**t 
das teilweise auch ist, ohne gehts halt nicht - merkt man aber selbst 
nach dem ersten Monat.

Klaus.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm,
ist das nicht Normal das Doku schreibt man ad hoc, nur dann wenn Zeit 
ist?
Kompilierung, Source einchecken, automatische Test usw. Das ist Zeit für 
Doku schreiben. Sonst keine, oder so kurz das kann man vergessen.

Autor: Sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Thema DOORS habe ich immer dein Eindruck, dass da ein paar 
Wirtschaftsinformatik Praktikanten aus dem 1. Semester 3 Wochen bestraft 
wurden. Hauptziel: Excel mit Versionierung und möglichst schlechtem 
Linkkonzept zu vergewaltigen.

Das Tool ist einfach grauenhaft.

Autor: peppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich kenn das Problem eher andersrum. Die Leute kennen sich mit 
allerhand Tools (darunter auch svn, UML-Tools,.......) sehr gut aus.
Das Codieren an sich ist dann eher das große Problem. Abstrakte 
Konstrukte,
Basisklassen, deren Verwendung und Design-Patterns werden heute von den
meisten Softwareentwicklern nicht mehr beherrscht.
Dafür gibts ja die Automatische Code-Synthese -> einfach auf den Knopf
drücken und die Software kommt hinten raus ;-)

Autor: fachfremder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das erste ,was ich in einer Exfirma vermittelt bekam war,
auf solche Tools zu verzichten.  Denn dieser Codec ist
zu lang , oftmals fehlerbehaftet bzw fehlerinduzierend
also nicht ernsthaft zu gebrauchen, weil er das Compilat
versaut.

Die konsequente Beherzigung dessen führte zu excellenten
Programmen so gut , daß die GL sukzessive die Macher
feuerte ...

Insofern kann im Umkehrschluß gesagt werden - Ihr wollt
eine gewisse Unkündbarkeit , dann verwendet ........

Autor: Arne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das erste ,was ich in einer Exfirma vermittelt bekam war,
>auf solche Tools zu verzichten.
Erinnert mich an meine Erfahrungen mit Lex und Yacc an der FH. Seitdem 
mache ich um synthetischen Code einen großen Bogen. Selbst wenn die 
Tools heute besser geworden sind... Aber auch Menschen können schlechten 
Code erzeugen.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
svn hat mir noch kein Programm versaut.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schoen fuer dich, es gibt auch Leute, denen ist Windows noch nie 
abgestuerzt...

Wenn 150 Entwickler an einem Repository haengen mit zig Branches und 
taeglichem Gemerge sieht's ein bisschen anders aus als bei Miniprojekten 
mit einer Hand voll Leuten.

Autor: Erfahrener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn 150 Entwickler an einem Repository haengen mit zig Branches und
>taeglichem Gemerge sieht's ein bisschen anders aus als bei Miniprojekten
>mit einer Hand voll Leuten.

Und was schlägst du als Alternative vor? Alle machen ihren Mist lokal 
und am Ende dürfen alle 6 Monate lang alles zusammenmergen?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll dabei schiefgehen? Das Repository ist transaktionsbasiert und 
sehr einfach aufgebaut. Ein Changeset, eine neue Datei. Da kann nichts 
kaputt gehen. Natürlich kann sich der Benutzer in Merge-Konflikten 
verheddern, aber das ist ein Problem der richtigen Anwendung.

Arne:
Du würdest aber nicht ernsthaft einen Analyzer und Parser in C 
schreiben, oder?

Bei Codegeneratoren muss man zwei Fälle unterscheiden:
- Code, der nach der Erzeugung nicht mehr von Hand bearbeitet wird. 
Solche Tools sind z.B. für den Compilerbau unverzichtbar (Lex, Yacc).
- Code, der nur einmal erzeugt und dann von Menschen weiterbearbeitet 
wird. Wenn der erzeugte Code nur aus ein paar einfachen leeren Gerüsten 
besteht, dann kann das durchaus sinnvoll sein. Ein Problem wird es, wenn 
der Generator umfangreichen Programmcode erzeugt, entweder aus einer 
Standardvorlage oder aus eingegebenen Ablaufdiagrammen o.ä., und man mit 
diesem Code weiterarbeiten soll. Das verstößt gegen das Prinzip der 
Modularisierung, weil man "fremden" mit selbstgeschriebenem Code 
vermischt, statt durch eine Schnittstelle zu trennen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.