ein alter IT Praktiker über den FIAE

[Icemanemp]

Also viele stellen sich vielleicht die Ausbildung als schwierig vor! Ich bin der Meinung das sie ziemlich einfach ist und auch nur oberflächlich viel zeigt, aber nirgends in die Tiefe geht, das ist das die Aufgabe des Betriebs (da man dort eigentlich alle Abteilungen, Technik, Programmierung, Verwaltung usw. durchlaufen sollte!)! Es gibt natürlich unterschiede von Schule zu Schule, aber generell ist das so festgelegt!

Wie einer schrieb, das keine Mathe in der BS unterrichtet wird. Das ist auch so in Ordnung, da die wenigsten Firmen Software mit viel mathematischen Berechnungen machen, wie CAD oder irgendwelche Medizin/Spiele-Visualisierung! Die meisten Firmen sind interessiert an Leuten mit wirtschaftlichen Kenntnisse, da die Industrie und Wirtschaft eben die grössten Arbeitgeber und Märkte sind! Daher auch kein Mathe in dem Sinn, ausser bissel Rechnen in Rechnungswesen und bissel Boolsche Algebra für Programmierung...

Das was wir in der Schule gemacht haben, hab ich grad in der FH innerhalb eines Kurses gemacht. Das heisst bei uns Grundlagen WI! Obwohl unser Studiengang auch sehr oberflächlich ist, d.h. breit gefächertes Wissen als Wirtschaftsinformatiker, anstatt sehr spezielles Wissen in bestimmten Bereichen als Informatiker, sind wir auf jeden Fall schon viel weiter als das was ich in der Schule in 2,5 Jahren gemacht hab.

[Alrik Fassbauer]

Mit UML kannst du Probleme weit weit weit besser, einfacher und schneller beschreiben, als mit Worten und die Gefahr, falsch verstanden zu werden, ist (wenn beide UML kennen) sehr viel geringer...

Einwurf : Mach das mal Günter Gras klar. Vielleicht schreibt er seine Romane dann in UML ...

Fazit : Es kommt ganz darauf an, WAS ich in UML ausdrücken und umgesetzt haben will. Projektdokumentationen kannst du jdenfalls nicht ausschließlich in UML schreiben. Das geht nicht. Schon vom rein sprachlichen Standpunkt her.

Du mußt immerhin so offen sein, mehrere Methoden zur Ausdrucksweise zu beherrschen. UML ist zwar eine extrem effektive, aber auch nur eine davon.

[MarkusLe]

UML ist eine einheitliche Sprache die Softwaredesigner und Softwareentwickler miteinander sprechen, und die jeder von den beiden verstehen sollte. Das man sowas natürlich keinem Kunden in diesem Umfang antut ist klar. Aber in der Entwicklung sollte zumindest der komplette Programmablauf und Aufbau in UML ausgedrückt werden und nicht in 12 verschiedenen Beschreibungssprachen. Meine pers. Meinung zu UML^^ Desshalb sollen sie uns in der Schule auch lieber UML in seiner kompletten Komplexität (schönes Wort) beibringen und solche Antiquariate wie Struktogramme glücklich und zufrieden zu den alten Akten legen.

[Der Kleine]

UML ist eine einheitliche Sprache die Softwaredesigner und Softwareentwickler miteinander sprechen, und die jeder von den beiden verstehen sollte.

Irgendwie kommt ihr vom Thema ab.

Das UML toll ist, hat gar keiner bezweifelt. Mein Statement war, ob UML unbedingt gekonnt sein muss oder ob es nicht auch anders möglich wäre, Probleme eindeutig zu identifizieren.

Meine Meinung: es geht auch ohne UML. Andere haben auch Probleme aber nicht unbedingt UML.

[XGuardian]

@MarkusLe

Ich stimme dir voll und ganz zu.

Ehrlich gesagt finde ich das, was wir in der Berufsschule lernen, als absolut unbrauchbar für die tägliche Arbeit im Betrieb.

Gerade die Ausbildung in unsrem Fachbereich ist nahezu "lächerlich". Dass was die Berufsschule innerhalb von 3 Jahren an Programmierkenntnissen vermittelt, kann sich jeder innerhalb von 4 Wochen mit einem guten Buch selbst beibringen und das Fehlen von Mathematik und Englisch als Pflichtfächer in der Berufsschule macht es auch nicht gerade besser. (Aber dafür gibts ja Reli, das gleicht dass ganze aus)......

Wenn man dann noch in einen Betrieb ist, die in keiner weiße den auszubilden fördern, oder die Eigeninitiative unterbindet was zu erlernen. Die dann darauf hinweisen das die Berufsschule zuständig wäre. Oder die IHK die sich nicht wirklich mit den jeweiligen Beruf auseinandersetzt oder dem auszubilden bei einer Problemstellung, mit den Ausbildungsbetrieb informativ versorgt.

Es ist heutzutage einfach nicht mehr so leicht, mangels der beruflichen Förderung der Berufsschule oder durch den Betrieb, wer dann nicht übernommen wird, findet den Weg dann in die Arbeitslosigkeit. Und dann wieder Anschluss zu bekommen in den gelernten Berufszweig ist fast schon aussichtslos.

[michaelhhh]

Hallo Kleiner,

Folglich muss es dir als Praktiker so vorkommen, dass die Dip's nichts können.

da hast du mich aber VÖLLIG falsch verstanden. Ich habe lediglich gesagt, dass viele (nicht alle, nichtmal die meisten) Dipl-Infs weniger Prasix-geeignet sind als ein FI, der das, was im Handbuch für FI steht, wirklich kann. Damit wollte ich auch herausfinden, was wirklich ist. Solche Antworten sind ja auch gekommen.

Davon abgesehen arbeiten die meisten Dipl-Infs schon als Programmierer und nicht als Lastenheft-Schreiber.

Zudem ist ein Informatiker, der die UML nicht kann, wie ein Elektroniker, der keine Schaltpläne lesen kann.

Nichts für ungut

Michael

[Cleo]

[offtopic]

Zudem ist ein Informatiker, der die UML nicht kann, wie ein Elektroniker, der keine Schaltpläne lesen kann.

blödsinn.. ich kanns zwar einigermassen.. aber habs NIE im Berufsleben gebraucht.. also wozu sollte man es dann können, wenns nicht gebraucht wird? Ein Elektroniker wird sich jedoch wahrscheinlich wesentlich öfters mit schaltplänen auseinandersetzen als manche FIler..

[/offtopic]

BOT

Mich würde mal interessieren, wie hier die Azubis den Beruf eines FIAwler definieren würden (Aufgabengebiete, Einsatz etc.)

[michaelhhh]

UML

blödsinn.. ich kanns zwar einigermassen.. aber habs NIE im Berufsleben gebraucht.. also wozu sollte man es dann können, wenns nicht gebraucht wird? Ein Elektroniker wird sich jedoch wahrscheinlich wesentlich öfters mit schaltplänen auseinandersetzen als manche FIler..

Kein Blödsinn.

Laufend braucht man als Anwendungsentwickler solch eine Sprache wie die UML sie darstellt (sagen mir über 20 Jahre in Erfahrung in der Branche). Dass konkret die UML so selten benutzt wird, liegt einfach daran, dass sie kaum einer richtig erlernt (und vor allem eben an vielen Hochschulen nicht gelehrt wird). Die Informatik ist also da, wo die Elektronik vor der Entwicklung einer einheitlichen Schaltplansprache war.

Es muss natürlich nicht die UML sein, aber dass es GAR KEINE gemeinsame formalisierte Sprache auf der Ebene gibt, sehe ich als problematisch an.

Und dann wundern sich Auftraggeber und Entwickler, dass sie Kommunikation völlig in die Hose geht:

http://www.enabled.com.au/www_enabled/imagelibrary/3511.jpg

Wobei die UML weder alle in dem Cartoon genannten Bereiche abdeckt noch die einzige Möglichkeit ist, aber wohl das Modell, welches am weitesten entwickelt ist.

[Cleo]

aber dass es GAR KEINE gemeinsame formalisierte Sprache auf der Ebene gibt, sehe ich als problematisch an.

das ist wohl wahr, aber heisst nicht, dass unbedingt uml eingesetzt werden muss und es jeder FIler aus dem FF können muss..

uml wird teilweise bei manchen BS beigebracht.. in manchen firmen oder auch nicht.. es kommt nicht von irgendwoher, dass Azubis UML teilweise nicht können als FIAwler.. vermutlich deshalb, weil es halt nicht im Betrieb genutzt wird und in der BS nich unterrichtet wird..speziell die betriebliche nicht-nutzung lässt ein wenig auf den Gebrauch und die Notwendigkeit schliessen... m.E.

ABER das is eigentlich ein anderes thema

[michaelhhh]

das ist wohl wahr, aber heisst nicht, dass unbedingt uml eingesetzt werden muss und es jeder FIler aus dem FF können muss..

Doch, genau so sollte es sein, wenn die Informatik irgendwann mal erwachsen werden will. (Muss nicht konkret die UML sein, aber eine gemeinsame Analyse- und Entwurfssprache sollte es schon geben, wie in JEDER anderen Ingenieursdisziplin auch).

uml wird teilweise bei manchen BS beigebracht.. in manchen firmen oder auch nicht.. es kommt nicht von irgendwoher, dass Azubis UML teilweise nicht können als FIAwler.. vermutlich deshalb, weil es halt nicht im Betrieb genutzt wird und in der BS nich unterrichtet wird..speziell die betriebliche nicht-nutzung lässt ein wenig auf den Gebrauch und die Notwendigkeit schliessen... m.E.

ABER das is eigentlich ein anderes thema

Keiner lernt es, keiner kann es und daher braucht man es nicht. Tolle Logik! Was übersehen wird, dass es die Kommunikation und Dokumentation VIEL einfacher machen würde, wenn es alle kennen würden. Eben wie auch jeder Dipl.-Ing. E-Technik Schaltpläne lesen und schreiben kann, wie auch jeder gelernte Elektroniker.

[MarkusLe]

@Cleo

Bei kleinen Projekten kommst Du vielleicht noch rehct gut ohne UML oder andere Darstellungsmöglichkeiten für den Klassenaufbau und deren Zusammenhang, Workflow, Sequenzen usw. aus. Aber spätestens bei größeren Projekten (spätestens wenn mehrere Personen an dem Projekt entwickeln) wirst Du ohne das ganze ein paar Verständnisprobleme bekommen.

[Cleo]

naaaaaaaaaaaaaaaaaaaaaaaaaaaaaa momentchen...

ich hab nie behauptet, dass man ganz ohne alles auskommt..

Muss nicht konkret die UML sein

da sind wir uns ja einig..

Keiner lernt es, keiner kann es und daher braucht man es nicht.

Falsch.. es wird, zumindest meiner erfahrung nach, wenig benutzt, deswegen is die notwendigkeit immo nicht gegeben.. und da es wenig genutzt wird, können es die leute nicht..

Was übersehen wird, dass es die Kommunikation und Dokumentation VIEL einfacher machen würde, wenn es alle kennen würden.

Falsch.. kennen reicht nicht.. müsste auch eingesetzt werden...

[Akku]

1. Ich habe persönlich vor über 20 Jahren Textverarbeitungssysteme in 8080 und 8086 Assembler nach der VHIT Methode entwickelt. Hat super funktioniert, ich lebe noch.

2. UML ist erst langsam auf dem Wege eine einheitliche Darstellung komplexer Sachverhalte darzustellen. Schon allein die absurde Diskussionen bezüglich Aggregation und Komposition lässt darauf schliessen, dass UML aus verschiedenen Blickrichtungen zu sehen sind.

3. Selbst die Erfinder und die Community der UML sind sich in weiten Teilen noch nicht 100% einig, wie Was, Wann, und Wo dargestellt wird.

Jedoch wird die Softwareentwicklung durch die Benutzung verschiedener Techniken deutlich vereinfacht und die Fehlerquote reduziert. Daher ist die Vermittlung und Nutzung dieser Kenntnisse unabdingbar.

Schlimm wird die Entwicklung nur dann, wenn zahlreiche Hypes aufeinandertreffen. Gerade die Java Welt zeigt mit täglich neuen Schlagwörtern wie schwer es den angehenden Softwareentwicklern gemacht werden kann. Womit die provokante Frage gestellt werden kann: War früher alles besser?

[DennyB]

Das hat nun meiner Meinung nach aber nichts mehr mit dem urspruenglichen Thema das Threads zu tun. Man kann ein Studium oder eine Ausbildung doch nicht danach bewerten ob und wie tiefgehend UML gelehrt wird.

UML ist eine Sprache die im Umfang eines Studiums/Ausbildung fast gar nichts ausmacht. Wenn man sie lernen will, kann man das auch durch Selbststudium (wahrscheinlich sogar schneller und besser als in der BS). UML mag sicherlich vorteilhaft und nuetzlich sein und sollte meiner Meinung nach auch gelehrt werden, aber es ist nicht das Mass aller Dinge.

[Cleo]

genau also zurück zum Thema:

Die frage ging eventuell ein wenig unter.. deswegen nochmals:

Wie definiert ihr als Azubis euren Beruf (Aufgabengebiet etc.)

[dieterhaas]

Hallo michaelhhh !

Ich denke, es kommt ganz darauf an, wo und wann man ausgebidet wird.

Für meine Umschulung bei SBS (Siemens Business Services) hat man eine ordentliche Schulbildung gebraucht (möglichst:Abi).

Dann fällt der Schnickschnack der Berufsschulen weg, und man kann sich aufs Wesentliche konzentrieren.

Dazu noch ein ordentliches Praktikum.

--> Ist man gut ausgebildet.

Natürlich lernt man Vieles auch erst im Berufleben, aber das Handwerkszeug habe ich während der Umschulung gelernt,trotz dass meine beiden Kinder während der Umschulung zur Welt kamen, und trotz das ich damals schon Ende 30 war.

Grüsse

Dieter

[Bubble]

Zudem ist ein Informatiker, der die UML nicht kann, wie ein Elektroniker, der keine Schaltpläne lesen kann.

UML mit Schaltplänen zu vergleichen, ist wie Äpfel mit Birnen zu vergleichen. UML sagt allenfalls aus, wie etwas "irgendwie" abläuft und aufgebaut sein soll, ein Schaltplan kommt bereits einer konkreten Implementierung gleich.

Laufend braucht man als Anwendungsentwickler

Du hast noch immer nicht gesagt, was für Programme der von Dir erwähnte Entwickler entwickeln können soll...

[michaelhhh]

UML mit Schaltplänen zu vergleichen, ist wie Äpfel mit Birnen zu vergleichen. UML sagt allenfalls aus, wie etwas "irgendwie" abläuft und aufgebaut sein soll, ein Schaltplan kommt bereits einer konkreten Implementierung gleich.

Hast du schonmal elektronische Schaltungen entwickelt? Kaum, denn dann wüsstest du, dass das obige nicht stimmt. Der Schaltplan gibt zwar die theoretische Lösung vor, aber wie die Schaltelemente auf die Leiterbahn kommen, steht da nicht drin! Und das macht gerade bei HF-Technik einen riesigen Unterschied, nämlich von funktiniert bis funktioniert nicht. Genau wie beim Software-Entwurf mit UML und dann der komkreten Programmierung.

Du hast noch immer nicht gesagt, was für Programme der von Dir erwähnte Entwickler entwickeln können soll...

Ich war tätig in den Bereichen Systemprogrammierung (Treiber), Standard-Software, datenbank-basierte Branchensoftware (vertikal), betriebswirtschaftliche Software (horizontal). Und das in Einzelprojekten mit wenigen tausend LOC (Treiber in Assembler), bis hin zu Projekten mit hunderten von Beteiligten und mehrstelligen Millionen LOC.

In jedem Bereich für Projekte ab einem bestimmten Umfang würde die UML die Kommunikation und Dokumentation enorm verbessern, wenn sie denn jeder beteiligte Informatiker verstünde, wie Elektroniker Schaltpläne verstehen. In nicht weniger Projekte hab ich die UML (und davor deren Vorgänger die Booch-Notation) eingebracht, was sich in jedem Fall für alle Beteiligten als große Hilfe herausgstellt hatte - auch wenn es teilweise vorher große Skepsis gab.

[BibaBär]

Erstmal wieder zurück zum Topic:

Ich definiere meinen Beruf / mein Aufgabengebiet als Mädchen für alles:

* Administration Linux / Windows (2000 / 2003) Server

* Umsetzung Netzwerkkonzepte

* Absicherung von Netzwerken (WLAN / DMZ / Root-Server / VPN / IPSec etc)

* Entwicklung von Embedded Systemen - wird ab nächstem Jahr kommen

* Dokumentationen / Präsentationen

* Umsetzung und Planung von Software-Projekten

* Programmierung (PHP, PHP5, Java / J2EE, Perl, Bash, Python, SOAP, SOA... so ziemlich jede Sache, die irgendwie mit Web-Anwendungen zu tun hat)

Am wichtigsten finde ich es, dass sich Leute in unserem Beruf nicht auf ihren Erfahrungen ausruhen sondern immer weiter am Ball bleiben und lernen.

---

Wegen der UML:

In jedem Bereich für Projekte ab einem bestimmten Umfang würde die UML die Kommunikation und Dokumentation enorm verbessern, wenn sie denn jeder beteiligte Informatiker verstünde, wie Elektroniker Schaltpläne verstehen. In nicht weniger Projekte hab ich die UML (und davor deren Vorgänger die Booch-Notation) eingebracht, was sich in jedem Fall für alle Beteiligten als große Hilfe herausgstellt hatte - auch wenn es teilweise vorher große Skepsis gab.

Dem kann ich voll und ganz zustimmen. Ich habe die selbe Erfahrung gemacht: Sobald mehr als zwei Leute an einem Projekt sitzen und verschiedene Positionen einnehmen (System-Architekt, Datenbank-Architekt, Software-Entwickler, Designer etc) ist es mit Hilfe von UML wesentlich einfacher sich zu verständigen.

Dadurch, dass man Konzepte, Abläufe und Objekte visualiert, lässt sich das Gesamtprojekt von jedem Beteiligten verstehen.

Voraussetzung ist natürlich, dass jeder in der Lage ist, UML-Diagramme zu interpretieren.

[Bubble]

Ich war tätig in den Bereichen

Leider viele Buzzwords ohne Angabe über die Ansprüche an die Software (und den "Schwierigkeitsgrad" des zugrundeliegenden Problems), die ein Fachinformatiker deiner Ansicht nach entwickeln können soll.

Ich glaube, Du bist UML-verliebt. UML ist nicht die Lösung aller Probleme. Es gibt Alternativen. UML kann, wie jedes andere beschreibende Mittel helfen, aber für ein Gelingen braucht es fähige Köpfe, die nicht durch eine starre Organisation behindert werden.

[michaelhhh]

Leider viele Buzzwords ohne Angabe über die Ansprüche an die Software (und den "Schwierigkeitsgrad" des zugrundeliegenden Problems), die ein Fachinformatiker deiner Ansicht nach entwickeln können soll.

Wir spielen hier weder Bewerbungsgespräch noch "zieh dich aus Mann".

Ich glaube, Du bist UML-verliebt. UML ist nicht die Lösung aller Probleme.

Du hast ganz offensichtlich überhaupt nicht gelesen, was ich geschrieben habe, sonst hättest du solch einen Blödsinn nicht geschrieben.

[Bubble]

Wir spielen hier weder Bewerbungsgespräch noch "zieh dich aus Mann".

Es geht nicht um Dich und was Du vielleicht (oder vielleicht auch nicht) kannst oder bisher gemacht hast. Es geht um die Festlegung, was für eine Kenntnisse der von Dir bemühte "Anwendungsentwicklers" besitzt bzw. besitzen sollte, und was für Anwendungen dieser zu entwickeln in der Lage sein sollte.

Du hast ganz offensichtlich überhaupt nicht gelesen, was ich geschrieben habe,

Aber sicher habe ich das. Wenn UML ein Produkt wäre, solltest Du es verkaufen...

[.vash]

Bei der Diskussion um den Berufsschulunterricht darf man auch nie vergessen, dass dieser auch darauf ausgerichtet ist, dass "Anfänger" in den Beruf einsteigen. Das führt dazu dass die Leute mit Vorwissen sich regelmäßig langweilen und die Anfänger überfordert sind.

Diese Problematik lässt sich nicht beheben in dem man Klassen mit unterschiedlichen Gewichtungen einführt, am Ende soll die Ausbildung ja gleiche Kenntnisse für alle nachweisen.

Meiner Meinung ist das größte Problem der klassische Frontalunterricht wo Programmieren als Praxis nicht wirklich vermittelbar sind. Dass wichtige und auch nicht sofort einleuchtende Konzepte wie Objektorientierung oft viel zu spät und nur oberflächlich mangels Zeit drangenommen werden macht die Sache nicht besser. Die Anfänger sind dann knallhart auf den Betrieb angewiesen was auch nicht immer eine selbstverständlichkeit ist.

[.vash]

Laufend braucht man als Anwendungsentwickler solch eine Sprache wie die UML sie darstellt (sagen mir über 20 Jahre in Erfahrung in der Branche). Dass konkret die UML so selten benutzt wird, liegt einfach daran, dass sie kaum einer richtig erlernt (und vor allem eben an vielen Hochschulen nicht gelehrt wird).

Ich kann nicht auf 20 Jahre Erfahrung blicken - dennoch muss ich diese Aussage ganz dick unterstreichen. Zum Glück habe/hatte ich in meinem Ausbildungsbetrieb die Chance, große Projekte in der Industrie (Versicherung, Automobilhersteller) zu verfolgen, aber über Freunde auch den Unterricht einer FH mitzubekommen. Dabei habe ich folgendes festgestellt:

1. FH Unterricht in Software Engineering: Hier wurde und sollten auch Kenntnisse in UML oder entsprechenden Sprachen vermittelt werden. Ob die durchgenommenen Diagramme wirklich zeitgemäß waren, darüber lässt sich streiten. Schockiert hatte mich jedoch das UML Skript. Wenn selbst der Dozent kein fehlerfreiese Klassendiagramm zeichnen kann, bleibt mir nur ein Kopfschütteln.

2. Viele (vor allem größere) Projekte unterschätzen die Hilfe die einem Diagramme bieten können. Viele Entwickler lieben es alles im Kopf zu behalten und solange zu frickeln bis es funktioniert. Eine bildliche Vorstellung von den erwarteten und tatsächlichen Vorgängen innerhalb der Software führt bei komplizierten Sachverhalten klärt allerdings viele Probleme. Insbesondere wenn mehrere Entwickler (10+) beteiligt sind.

[Kelnor]

Nun zu den Dip's: Ich glaube einfah mal, dass die Ausrichtung eines Studiums eine ganz andere Zielrichtung verfolgt, als du hier annimmst. Man muss nach dem Studium nicht die Kenntnisse eines FI's besitzen, zumal diese zeitlich sehr stark variieren.

Als Studierter sollte man nicht unbedingt die Umsetzung einzelner Probleme erfolgreich lösen, sondern eher Probleme kreiiren (also IT-Probleme erstellen aus den Problemen anderer Leute)

Wozu also eine Programmiersprache können. besser ist doch die Formulierung der Anforderungen in einem Lastenheft.

Wozu ein UML aufstellen oder lesen können, besser ist doch die sprachlich genaus Formulierung der Anforderungen in einem Lastenheft.

Folglich muss es dir als Praktiker so vorkommen, dass die Dip's nichts können.

Moment, das sehe ich anders. In meiner Abteilung sind ca. 40 Mitarbeiter beschäftigt (großes Unternehmen) und 3 (!) davon haben nicht studiert. Nach der Logik wäre es ja nun so das die 37 Dipl.-Ings. die Probleme für die 3 FIs kreieren und diese dann werkeln lassen.

Bei den meisten Stellenausschreibungen wird explizit ein Bewerber mit Studium oder vergleichbaren Kenntnissen (z.B. durch eine Ausbildung) gesucht. Das ein Dipl.-Ing. eigentlich eine andere Ausrichtung hat und andere Tätigkeiten durchführt scheint hierbei nicht weiter zu interessieren. Es sollte wohl anders sein aber die Realität, zumindest in meinen Augen, sieht anders aus.