stefan.macke

Bitte mal die Forensuche benutzen. Es gibt hier unzählige Beispiele für Dokus...

Und das heißt für dich "Ich frage mal im erstbesten Forum"? ;-) Bei einer "Recherche" zum Thema Literatur für Fachinformatiker wäre dir sicher das Handbuch für Fachinformatiker von Sascha Kersken aufgefallen: https://www.rheinwerk-verlag.de/it-handbuch-fur-fachinformatiker_3756/ Das passt auch deutlich besser zu den Inhalten der Ausbildung als "angewandte Mathematik und Physik". Zusätzlich ist noch das IT-Handbuch zu empfehlen: https://verlage.westermanngruppe.de/westermann/artikel/978-3-14-235042-4/IT-Handbuch-IT-Systemelektronikerin-Fachinformatikerin-Schuelerband-9-Auflage-2015

Ich würde noch weiter gehen: Nicht einmal die einzelnen Aufgaben innerhalb der beiden Teile haben einen Bezug zueinander. Sie beziehen sich zwar meist auf einen gemeinsamen Kontext (z.B. ein Softwareunternehmen oder die Domäne "Zeiterfassung"), aber sie bauen niemals aufeinander auf, in dem Sinne, dass Ergebnisse der einen Aufgabe relevant für die andere sind. Das kann auch nicht so sein, da man ja jede einzelne Aufgabe streichen können muss. In manchen Prüfungen - z.B. wenn in Handlungsschritt 1 ein ERM gezeichnet werden muss und in HS2 dann SQL-Abfragen konstruiert werden müssen, für die ein Tabellenmodell angegeben ist - wird sogar explizit in der Prüfung geschrieben, dass es keinen Bezug zur vorherigen Aufgabe gibt. Und GH2 ist sogar für alle IT-Berufe (also auch Informatikkaufmann usw.) identisch, nicht nur für die beiden Fachinformatiker.

Nein, das ist nicht schlimm. Im Gegenteil: Ich würde die von dir genannten Artefakte in deiner Dokumentation erwarten. Ob du sie in den Anhang packst, würde ich davon abhängig machen, wie umfangreich sie sind. Deine wertvollen Dokumentationsseiten (also den Fließtext) solltest du nicht mit großen Artefakten verringern. Meine Faustformel: Alles, was länger als eine halbe Seite ist, kommt grundsätzlich in den Anhang. Bitte aber uninteressante Sachen wie Deckblätter oder Inhaltsverzeichnisse weglassen! Und achte auf die Vorgaben deiner IHK bzgl. der maximalen Seitenzahl. Bitte nicht! Kurz und knapp das Unternehmen vorstellen. Du solltest dich auf deine Eigenleistung konzentrieren. Das bewerten die Prüfer. Ob deine Firma toll ist, hat keine Auswirkungen auf deine Note! Nein. Siehe oben: Das hat nichts mit dem Projekt zu tun und lenkt von deiner - zu bewertenden - Leistung im Projekt ab. Es hat sich bewährt, dafür ein eigenes Kapitel Änderungen zum Projektantrag zu nutzen. Grundsätzlich ja. Selbst wenn es ein gemeinnütziges Projekt ist, wird dein Chef sicher wissen wollen, was es gekostet hat. Es ist schon ein Unterschied, ob man 1.000 EUR oder 10.000 EUR "spendet". Und außerdem wollen die Prüfer - so ist es zumindest bei uns - immer eine Wirtschaftlichkeitsbetrachtung sehen. Der Ausbildungsberuf hat immerhin einen großen kaufmännischen Anteil.

Für die IHK-Prüfung würde ich auf die Chen-Notation setzen: https://de.wikipedia.org/wiki/Entity-Relationship-Modell

Dazu fällt mir nur dieses Zitat ein:

Ich würde dir - wie deine IHK - raten, dich nach einem neuen Ausbildungsplatz umzuschauen. Die gesame Situation lässt nicht gerade auf eine geordnete und planvolle Ausbildung schließen. Ich glaube nicht (und das basiert nur auf deiner Schilderung, ohne dein Unternehmen genau zu kennen), dass mit einem neuen Ausbilder auf einmal alles besser wird. Ausbildung ist Chefsache. Und wenn der sich nicht dafür interessiert...

Das kenne ich tatsächlich auch völlig anders. Die Berufsschule nimmt meines Wissens nach eher Rücksicht auf die IHK-Prüfungen und bietet Wiederholungen usw. an. Aber ok, wenn das in deiner Schule so ist, will ich nichts sagen. Dennoch hättest du natürlich jetzt nicht so einen Stress, wenn du die zwei Jahre (oder das Jahr) vorher vielleicht doch mal ein Buch aufgeschlagen und vorbereitend für die Prüfung gelernt hättest Ich glaube kaum, dass beim kurzfristigen Lernen vor der IHK-Prüfung viel Stoff lange hängen bleibt. Vielmehr wird wohl das Meiste direkt nach der Prüfung wieder vergessen. Und ich vertrete die Meinung, dass man in diesem Fall wirklich fürs Leben und nicht nur für die Klausur lernt. "Panikmache" würde ich das also nicht nennen. Wenn man sich den umfangreichen Themenkatalog für die Prüfung anschaut, ist man gut beraten, möglichst früh anzufangen, wenn man die Inhalte auch langfristig in seinem Arbeitsalltag anwenden möchte.

Mal ne ganz doofe Frage zum Einstieg: Hast du es schon mit Google versucht? Der erste Treffer zu deiner Fehlermeldung ist der hier: Java: no security manager: RMI class loader disabled

Das ist eine coole Idee! Werde ich übernehmen! Ich habe bislang einfach ein paar Fachgespräche auf Basis der Präsentation mit den Azubis geübt und dabei alles Mögliche gefragt, das mir eingefallen ist. Wenn ich dann durch war, gab es noch eine Präsi vor der gesamten Abteilung, die auch meist noch einige weitere Fragen nach sich zog. Aber mit der Mindmap kann man das Ganze noch in eine etwas geordnetere Bahn lenken und vielleicht sogar recht sicher sein, nichts zu übersehen.

Ich würde den Fokus auf UML-Diagramme (Klassen, Sequenz, Aktivität, Zustand, Use-Case) legen. Pseudocode war in der letzten Prüfung gleich zweimal drin, damit man sich nicht davor drücken kann. Außerdem kommt mit ziemlicher Sicherheit SQL und/oder ERM/Tabellenmodell dran. Das ist das absolute Minimum, das du draufhaben solltest. Ansonsten noch der Tipp für alle, die diesen Beitrag später lesen: Fang nicht erst kurz vor der Prüfung an zu lernen! Ein halber Jahr vorher ist das absolute Minimum. Ich würde z.B. ab dem zweiten Lehrjahr alle zwei Wochen eine alte Prüfung durchgehen.

Der Beitrag ist zwar schon älter, aber welches Addon war es denn bei dir? Habe leider das gleiche Problem...

Ich kann den Enterprise Architect empfehlen. Kostet zwar ca. 150 Euro, aber kann auch alles! Nicht nur alle UML-Diagrammtypen, sondern auch ERM, BPMN usw. Code-Engineering geht auch. Für den Preis ein unschlagbar gutes Tool. Damit modelliere ich alles.

Das Schöne an Pseudocode ist, dass er nicht standardisiert ist. Das heißt, du kannst alles schreiben, was du willst, solange man die Intention erkennen kann. Daher würde ich dir raten, es dir einfach zu machen und dich an einer Programmiersprache zu orientieren, die du beherrschst, dann aber alles Unnötige wegzulassen. In deinem Beispiel wären das die doppelten Typdefinitionen und das Semikolon. Ich würde einfach schreiben: variable = "der String"

Genau, die Bewerber können noch nicht programmieren. Also ist es meine Aufgabe herauszufinden, ob sie eine realistische Chance haben, es zu lernen. Ich mache z.B. FizzBuzz mit den Bewerbern und sie sollen die Aufgabe erstmal auf dem Papier lösen bzw. mir erklären, wie sie die Aufgabe lösen würden. Auch gerne nehme ich die Prüfung, ob eine Zahl prim ist. Dazu muss man nicht programmieren können, sondern einen mathematischen Algorithmus beschreiben können, den die Bewerber vielleicht sogar noch aus der Schule kennen. Und den setzen wir dann gemeinsam (mit meiner Hilfe bzgl. Syntax usw.) in Java um. Am Ende des Tages haben wir also ein lauffähiges Programm erstellt. Dabei achte ich dann z.B. darauf, ob der Bewerber sich die Shortcuts merkt, die ich ihm beibringe, oder die Syntax schnell lernt. Ich versuche also ungefähr einzuschätzen, ob sich später der Lernerfolg zügig einstellen wird. Außerdem zeige ich den Bewerbern unsere Systeme, die verwendeten Programmiersprachen, unseren Serverraum, das Gebäude und ihr potentielles Büro. Zwischendurch können sie auch unter vier Augen mit unseren Azubis sprechen, um die oben genannten "harten" Fragen zu stellen Das Vorgehen hat sich bislang absolut bewährt, da beide Seiten immer einen sehr guten Eindruck voneinander bekommen haben. Ich glaube, ich kann inzwischen recht gut einschätzen, ob ein Bewerber Potential hat oder nicht. Und wir hatten auch schon den Fall, dass ein Bewerber im Anschluss gesagt hat: "Das will ich nicht den ganzen Tag lang machen." Das war dann letztlich auch eine hilfreiche Erkenntnis.

Aus Prüfersicht kann ich ausschließlich zu Pseudocode raten. Wenn du mal versuchst, ein "korrigiertes" Struktogramm zu verstehen (und zu bewerten), weißt du auch warum. Es ist fast unmöglich unter Zeitdruck auf Papier ein sauberes Diagramm zu zeichnen. Bei Pseudocode kann man wenigstens noch hier und da Text einfügen oder mit "Fußnoten" arbeiten, wenn etwas vergessen wurde. Außerdem dauert es einfach ewig, die Diagramme zu zeichnen. Spar dir den Aufwand und schreib Pseudocode! Das ist meine ganz klare Empfehlung. Mir fällt auch nicht ein einziger Vorteil der Diagramme ein. Und in der Praxis verwendet sie auch niemand (jedenfalls ist mir niemand bekannt).

Anhand dieser Anmerkungen kannst du dir eigentlich alles ableiten: Es geht nicht hervor, WAS genau du umsetzt. Was heißt "minimal"? Was ist die "Beispielimplementierung"? Was genau ist der Funktionsumfang? Welche Use-Cases werden implementiert?Deine 35h-Phase ist viel (!) zu grob. Du hast die Hälfte deiner Projektzeit eigentlich gar nicht geplant. Vergleich das mal mit einem "echten" Projekt, das ein Jahr dauert. Da kannst du auch nicht deinem Chef sagen: "Ein halbes Jahr lang programmiere ich den Server." Du musst schon sagen, was du wann fertig hast, z.B. die GUI, die Logik, die DB-Anbindung usw. Ich empfehle max. (!) 7-8h pro Phase. Besser ist noch detaillierter.Es fehlen wichtige Bestandteile in deinem Projekt: Qualitätssicherung (Tests, Abnahme usw.), Wirtschaftlichkeitsbetrachtung, erstellte Artefakte (Lasten-/Pflichtenheft, Diagramme usw.), Kundendoku usw.Aus deinem Antrag geht einfach die technische Tiefe nicht deutlich hervor. Das sieht man auch an der obigen Diskussion.

Ich würde nicht versuchen, die Prüfer mit einem Thema zu "beeindrucken". Die wissen nämlich in 99% der Fälle mehr als der Prüfling Es ist natürlich spannender für Prüfer, über ein weniger ausgelutschtes Thema zu lesen, aber die Bewertung sollte das nicht beeinflussen. Letztlich wird durch die Doku deine Projektarbeit bewertet und (leider) eher untergeordnet die technische Komplexität/Umsetzung. Ich habe mal ein paar Punkte für und gegen "außergewöhnliche" Themen zusammengestellt: Standardthemen lassen sich besser vergleichen (kann positiv oder negativ für den Prüfling sein)Außergewöhnliche Themen muss man besonders gut beherrschen (entweder wissen die Prüfer nicht bescheid oder man hat einen Experten im Ausschuss; beides zieht tiefergehende Fragen nach sich)Der Zeitrahmen wird bei zu aufwändigen Themen vielleicht nicht eingehalten (muss zum Nichtbestehen führen)Außergewöhnliche Themen können vielleicht nicht (mit Standardmitteln) dokumentiert (und damit bewertet) werdenDie Vorkenntnisse reichen vielleicht nicht aus, um ein außergewöhnliches Thema sauber und fundiert umzusetzen

Ich würde das IT-Handbuch empfehlen (das frühere "Tabellenbuch"). Da stehen alle prüfungsrelevanten Inhalte drin. Es bietet erstmal einen guten Überblick und liefert auch genug Stichpunkte für eine weitere Recherche. Einen Großteil der allgemeinen Inhalte wird sicherlich die Berufsschule vermitteln (wozu haben die da schließlich Religion und Sport ), aber ich würde als Ausbilder auf Nummer sicher gehen und auch diese Themen selbst abfragen. Im Rahmen der Vorbereitung auf die Prüfung gehe ich z.B. alle mir bekannten Themen mit den Azubis noch einmal detailliert durch, um sicherzugehen, dass es keine Lücken gibt.

Wir handhaben es bei Bewerbungen zur Ausbildung so, dass alle in Frage kommenden Kandidaten mind. einen halben Tag mit mir gemeinsam eine "Probearbeit" machen. Dadurch können sich beide Seiten deutlich besser vorstellen, was auf sie zukommt, als nach einem halbstündigen Vorstellungsgespräch. Wenn die genannten Unternehmen das nicht anbieten, würde ich aktiv nachfragen, ob es eine Möglichkeit gibt, wie du dir ein besseres Bild von deiner Ausbildung machen kannst. Wenn die Unternehmen diesbzgl. nichts anbieten (z.B. Praktikum, Schnuppertag, Gespräch mit anderen Azubis usw.), würde ich von ihnen abraten. Immerhin bleibst du drei Jahre dort und solltest dir sicher sein, eine gute Ausbildung zu bekommen. Das hat übrigens auch viel mit Persönlichkeit zu tun. Wenn dein Ausbilder zwar immer für dich da ist, aber du mit ihm nicht klarkommst, hilft das auch nicht. Versuch also so lange wie möglich mit deinen zukünftigen Kollegen zu sprechen, um dir ein gutes Bild zu machen. Die Größe oder Branche des Unternehmens hat meiner Meinung nach keine direkte Auswirkung auf die Qualität der Ausbildung. Das hängt sehr stark von den beteiligten Personen ab. Auch in "kleinen Klitschen" oder "Riesenkonzernen" kann man von einer/m guten Ausbilder/in sehr gut ausgebildet werden.

Wir haben auch JaCoCo im Einsatz, aber eine Ausschlussmöglichkeit habe ich noch nicht entdeckt. Wenn es die gibt, würde ich mich über einen Link freuen :-)

Zu einem vernünftigen Projekt (eines Anwendungsentwicklers) gehören meiner Meinung nach heutzutage Tests. Und zwar automatische. Aber auch manuelle Abnahmetests sind durchaus angebracht, wenn das Projekt in die Produktion gebracht werden soll. In welchem Umfang die Tests stattfinden, kann man nicht allgemein sagen. Aber wenn z.B. per Tool eine gute Code Coverage nachgewiesen werden kann, würde ich das unbedingt in die Doku packen. Das zeigt, dass die Qualitätssicherung berücksichtigt wurde und mit den aktuellen technischen Möglichkeiten umgesetzt wurde.

Das Plus-Paket kann ich empfehlen. Ist eine gute Vorbereitung auf die Prüfung. Nicht nur eine echte Prüfung ist enthalten, sondern auch Erklärungen zu den Aufgaben. Ich würde zusätzlich aber noch die Prüfungen der letzten Jahre durchgehen, um ein besseres Gefühl für die Fragestellung zu bekommen. Außerdem ist gerade die neue Auflage des "Handbuchs für Fachinformatiker" (siehe http://buecher.lingoworld.de/) erschienen, das ich auch sehr empfehlen kann.

Und es kommt auf die Planung des Unternehmens an. Ich kenne z.B. Unternehmen, die bewusst einen Azubi in eine Teilzeitklasse stecken und einen anderen in eine Blockphasenklasse, damit immer ein Azubi im Haus ist.

Frag unbedingt deine IHK, wie du offiziell weiter vorgehen musst. Ich denke, du musst einen neuen Projektantrag stellen, der die normale Genehmigung durchläuft. Wenn wir ein Projekt auf den Tisch bekommen, bei dem der Prüfling eigenmächtig das Thema - auch nur leicht - verändert hat, ist die Prüfung nicht bestanden. Dafür gibt es ja extra den Genehmigungsprozess. Sonst könnte ja jeder Prüfling sein Thema im Nachhinein verändern, weil er doch keine Lust mehr hatte usw.