stefan.macke

Dem kann ich nur zustimmen. Man kann eigentlich nie zu viele Zeugnisse beilegen. Wir möchten bei Bewerbern immer gerne mehrere Zeugnisse sehen, um die Entwicklung nachvollziehen zu können. Es kann ja sein, dass mal ein schlechteres Zeugnis dazwischen ist, aber wenn der langfristige Trend positiv ist, ist das dann ja nicht so schlimm.

Wenn du Spaß an der Entwicklung hast und das Thema völlig frei wählbar ist, warum solltest du dann zu einem anderen Thema präsentieren? Was ist der Sinn dahinter? Du kannst dir ein beliebiges Thema aussuchen und wählst absichtlich etwas, worauf du eigentlich gar nicht so viel Lust hast!? Da würde ich sagen: Thema verfehlt. Zu den von dir genannten Punkten kannst du sicherlich locker 8 Minuten füllen. Das ist ja nichts! Bastel mal ein paar Folien und übe deine Präsentation. Du wirst sehen, wie schnell die Zeit vergeht.

Es handelt sich um eine Ausbildung, richtig? Wenn das Unternehmen ernsthaft von dir erwartet, einen Fachvortrag zu einem Informatikthema zu halten, such dir schnell ein anderes Unternehmen! Du sollst etwas lernen und nicht schon alles können. Falls es sich um eine Präsentation handelt, die nur dein Auftreten und deine Folien usw. zeigen soll, ist das natürlich etwas anderes.

Bitte alle Nicht-Programmiersprachen streichen! Welche das sind überlasse ich dir als Übung... Oder du formulierst den Satz anders (z.B. Programmier- und Auszeichnungssprachen).

Genau richtig so. Ich selbst habe Kollegen, die den umgekehrten Weg - vom FIAE zum FISI - gegangen sind, und das ist eigentlich kein Problem, sofern du irgendwie zeigen kannst, dass du das entsprechende Handwerk beherrschst. Wenn du in der Bewerbung und im Vorstellungsgespräch glaubhaft vermitteln kannst, dass du entwickeln kannst (oder das sogar durch eigenen Code auf GitHub "beweisen" kannst), steht einer Karriere als Entwickler nichts mehr im Weg Nicht falsch verstehen: Ich bin nicht der Meinung, dass jeder FISI automatisch programmieren und jeder FIAE ein Active Directory aufsetzen kann. Im Gegenteil: Es gehört immer noch sehr viel Berufspraxis und Lernen dazu, um die entsprechende Technologie zu beherrschen. Aber ich würde mal sagen, dass man auch nach drei Jahren Ausbildung zum FIAE noch (lange) kein Senior Developer ist

Na klar ist das sinnvoll, wenn es dein Wunsch ist. Entwickler werden immer gebraucht Ganz wichtig: Für eine Ausbildung musst du NOCH NICHT programmieren können. Wer das von dir verlangt, wird dich höchstwahrscheinlich nicht ausbilden, sondern ausbeuten

Für mich eindeutig: Die Projektdoku (nicht die Kunden-/Entwicklerdoku!) darf außerhalb der 70h erstellt werden. Wenn du dir unsicher bist, ruf bitte einfach deine IHK an. Nur die können es dir verbindlich sagen!

Die Dokumentationsphase wäre mir viel (!) zu lang. 22 Stunden sind fast ein Drittel der Zeit. Bist du sicher, dass du die Projektdokumentation in die 70h einrechnen musst? Das würde ich mir genau bei deiner IHK nachfragen. Aber auch die 10h für die eigentliche Doku wären mir zu lang. Achja: Das Pflichtenheft ist eigentlich das Ergebnis der Entwurfsphase. Nach der Analyse kannst du üblicherweise nur die Anforderungen beschreiben (=Lastenheft). Ein Pflichtenheft enthält (da es Vertragsbestandteil wird) Details zur Implementierung, die du nur in der Entwurfsphase definieren kannst (z.B. Oberflächen, konkrete Technologien usw.)

Du sollst auch gar nichts umstellen, weil "das Internet" dir das rät. Du sollst einen geeigneten Prozess für dein Projekt aussuchen. Das heißt, du musst dir der Vor- und Nachteile bewusst sein und eine eigene Entscheidung treffen. Das ist Teil deiner Prüfungsleistung! Das ist auch völliger Unfug. Du sollst für das Projekt nichts extra lernen, sondern etablierte Methoden und Werkzeuge einsetzen, die du beherrschst. Ich weiß gerade nicht, welche Vorlage du genau meinst (ich habe mehrere ), aber es wird immer das Thema Testing behandelt. In den letzten Projekten gab es jedoch keine explizite Testphase, da mit TDD entwickelt wurde und die (Entwickler-)Tests parallel zur Implementierung stattfanden. Dennoch wird in der Doku auf dieses Verfahren eingegangen und dir Vorteile werden erläutert bzw. begründet, warum keine ausgedehnte (manuelle) Testphase stattfand. Unit-Tests und Integrationstests müssen nicht zwangsläufig durch TDD entstehen. Aber Unit-Tests sind wohl immer automatisiert. Integrationstests hoffentlich auch, können aber auch teilautomatisiert oder manuell durchgeführt werden. TDD ist ein Prozess, der beschreibt, WANN die Tests geschrieben werden. Er gibt nicht vor, auf welcher EBENE (z.B. Unit, Integration, System) die Tests durchgeführt werden. Wenn dir das alles nichts sagt, empfehle ich dringend in die Prüfungsvorbereitung zum Thema Softwaretest einzusteigen! Ich empfehle immer als maximale Länge für Aufgaben ein paar Stunden, Obergrenze 8h. Also alle Arbeitspakete in Aufgaben runterbrechen, die max. 1 Arbeitstag dauern. Ich betone MAXIMAL. Die meisten Punkte sollten deutlich kleiner sein (z.B. Pflichtenheft erstellen 3h, Automatischen Build einrichten 1h, Entwicklung Oberfläche 4h).

Das ist mir bekannt. Es war auch nur eine Auflistung von Beispielen: agil, TDD, Kanban, Scrum, usw. "Agil" setzte ich in Anführungszeichen, da viele Prüflinge schreiben, sie arbeiten agil, ohne zu definieren, was das eigentlich heißt. Genau wie du schreibst, gibt es ja durchaus mehrere formale Prozesse, die sich agil nennen. Was erwartet "die IHK" denn? Mir sind keine Vorgaben bzgl. der Projektumsetzung oder des zu verwendenden Entwicklungsprozesses bekannt. Das fände ich auch sehr seltsam, da die Technologien und Methoden ja ständigem Wandel unterliegen und diese Vorgaben damit häufig überarbeitet werden müssten. Auch das ist mir bekannt. War nur ein Beispiel! In der letzten Sommerprüfung haben in meinem Ausschuss gefühlte 50% der Prüflinge "Kanban" angewendet (wieder in Anführungszeichen, da die meisten nicht erklären konnten, was außer Karteikarten an der Wand eigentlich dahinter steckt, also z.B. WIP-Limit, Pull anstatt Push usw.)

Jedem Prüfling steht die Wahl seines Vorgehensmodelles völlig frei. Es werden heutzutage bereits viele Projekte "agil" (was immer das dann konkret heißen mag), mit TDD oder nach Kanban umgesetzt. Niemand ist gezwungen, veraltete Prozessmodelle zu verwenden. Und es gibt auch keine Pluspunkte für Anwendung des Wasserfallmodells

Du musst direkt vor der Prüfung vom Ausschuss gefragt werden, ob du befangen gegenüber Ausschussmitgliedern bist (Beispiel: Dein Vater/Ausbilder/Kollege prüft dich.) Wann das so ist, muss dieser Prüfer den Raum verlassen und ein anderer Prüfer muss für ihn einspringen. Die Mindestzahl von drei Prüfern (Arbeitgeber, Arbeitnehmer, Lehrer) muss aber immer eingehalten werden. Den Ausschuss schon im Vorfeld der Prüfung zu wechseln ist meines Wissens nach nicht möglich. Das frag bitte direkt bei deiner IHK nach. Normalerweise sollte die IHK aber erkennen, dass sehr wahrscheinlich Befangenheit vorliegt, und dich gleich einem anderen Ausschuss zuweisen. Oder der Ausschuss erkennt es und lässt dich umplanen. Die Prüfer sehen ja schon bei den Projektanträgen, wen sie zu prüfen haben. Wichtig: Befangenheit liegt nicht vor, wenn du z.B. von deinem "bösen" Lehrer geprüft wirst. Das musst du hinnehmen! Im Prinzip lässt sich die Gruppe der Befangenen auf deine Verwandten oder Arbeitskollegen einschränken. Sonst kämen ja alle Prüflinge auf wilde Ideen und ließen sich immer den "besten" Ausschüssen zuweisen.

Nur kurz in die Gegenrichtung: Bitte die (tasächlich recht knappen) 20 Seiten dann auch bis auf den letzten Absatz ausreizen! Die meisten Dokus, die ich lese, haben nämlich eher das Problem, dass (viel) zu wenig geschrieben wird!

Ich habe nochmal in meiner eigenen Masterarbeit nachgeschaut und diese Zahlen gefunden (leider schon etwas älter): Nagappan, Nachiappan ; Maximilien, E. M. ; Bhat, Thirumalesh ; Williams, Laurie: Realizing quality improvement through test driven development: results and experiences of four industrial teams. In: Empirical Software Engineering 13 (2008), Februar, Nr. 3, 289–302. Lammi, Grant: Test-Driven Development: Does writing software backwards really improve quality? Version: November 2008.

Wer sagt denn, dass du strikt nach Wasserfall oder "agil" (übrigens ein sehr schwammiger Begriff für eine Doku!) entwickeln musst? Du kannst durchaus eine sinnvolle Anpassung an deinem Prozess vornehmen (in deinem Fall Tests ergänzen), wenn es dir sinnvoll erscheint und du das gut begründest.

Der zeitliche Mehraufwand durch Tests wird langfristig (!) durch weniger Aufwand bei der Weiterentwicklung und Fehlersuche meiner Erfahrung nach mehr als aufgehoben. Durch ein besseres Design steigt außerdem die Qualität der Software. Konkrete Zahlen habe ich nicht. Es gibt aber viele wissenschaftliche Studien dazu. Ich stelle einfach mal 50% mehr Initialaufwand in den Raum.

Ich würde nicht einfach ein Gantt-Diagramm zeichnen, "weil man das so macht". Die Artefakte in der Projektdoku sollen doch einen Sinn haben und Mehrwert bieten. Den gleichen Projektablauf auf drei verschiedene Arten darzustellen ist doch Quatsch. Ich würde den kostbaren Platz besser für noch nicht vorhandene Inhalte nutzen. Oft lesen wir Dokus, die einfach ohne erkennbaren roten Faden Artefakte aneinanderklatschen, weil "man" ja UML, ERM usw. macht. Aber das führt nur zu einer zerstückelten Doku ohne Zusammenhang und vor allem ohne Begründung. Artefakte, deren Sinn nicht klar wird, würde ich weglassen.

Schau doch einfach in den Rahmenlehrplan. Dort wirst du die kaufmännischen Anteile finden. Je nachdem, wie man zählt könnte man bis zu 6 von 11 Lernfelder in der Berufsschule dem kaufmännischen Bereich zuordnen und den Rest dem technischen. http://www.kmk.org/fileadmin/Dateien/pdf/Bildung/BeruflicheBildung/rlp/Fachinformatiker97-04-25.pdf

Hast du vielleicht einfach einen GitHub-Account, den du angeben kannst? Die wollen einfach ein wenig "echten" Code von dir sehen. Ich persönlich würde darauf achten, wie die Module strukturiert sind, ob vernünftige Namen verwendet werden, ob es automatische Tests gibt usw. Ob und wenn ja welche Frameworks eingesetzt werden, wäre mir völlig egal. Das hängt ganz stark von der zu lösenden Aufgabe ab. Es ginge mir dabei eher um eine grundsätzliche Einschätzung deines Programmierstils. Und blamieren kannst du dich eigentlich nicht, sofern man erkennen kann, dass du dich weiterentwickelst. Mein eigener Code von vor drei Monaten ist auch gruselig!

Ich sehe kein Problem darin, ein Projekt mit einem "fremden" Thema zu bearbeiten, solange es ein betriebliches Projekt bleibt. Teil jeder Projektarbeit ist die Ist-Analyse und die Begründung der Wirtschaftlichkeit des Projekts. Wenn sich das Thema sauber begründen lässt und es das Unternehmen voranbringt, ist das konkrete Thema doch völlig egal. Solange das Projekt den Anforderungen eines Abschlussprojekts zum Anwendungsentwickler genügt (Komplexität, berufsspezifisch usw.) und die Umsetzung im Ausbildungsunternehmen nachvollziehbar begründet ist, wird sich kein Prüfer darüber beschweren, dass das Thema nicht zur eigentlichen Branche des Unternehmens passt.

Wäre für mich auf jeden Fall dichter dran als Bayern

Die Projektbeschreibung wäre mir zu dünn. Es geht kaum daraus hervor, was du eigentlich machst und was schon da ist. Aber das liegt vielleicht am Formular. Wie willst du die Zeit für ein Redactoring planen, ohne den Code zu kennen? Bei Verschlüsselung und Datenbank werde ich auch immer hellhörig. Geht es hier nicht zufällig eher um Hashes? Und meine zentrale Frage wäre: Ist das überhaupt rechtens? Über das System wäre nachvollziehbar, wer wie gewählt hat, richtig? Ansonsten kannst du vielleicht noch ein paar Artefakte unterbringen. Ich lese z.B. JavaFX, aber weder Mockups noch Screenshots.

Das kann ich nur unterstreichen. Es ist doch immer wieder erschreckend, wie wenig manche Ausbilder über den Ablauf und die Anforderungen der IHK-Prüfung wissen. Wenn man selbst gerade durch ist, weiß man wenigstens noch ein bisschen... Ansonsten kann ich dir nur empfehlen, den "Ausbilderschein" selbst zu machen. Die Inhalte sind hauptsächlich rechtlicher Natur und unabhängig vom konkreten Beruf. Aber verschiedene Lernmodelle und Methoden zur Wissensvermittlung gehören auch dazu. Und wenn du selbst zweifelst, ob du schon ausbilden kannst, gibt dir der Schein vielleicht ein wenig Sicherheit. Ist auch eine "offizielle" Fortbildung, die du absetzen kannst usw.

Das kenne ich noch nicht. Wer ist denn der/die Autor/in?

Hallo zusammen, passend zum August, in dem wahrscheinlich die meisten neuen Azubis ihre Ausbildung starten, habe ich die dritte Episode des Podcasts von fachinformatiker.de aufgenommen und gebe ein paar allgemeine Tipps für den Einstieg in die Ausbildung in den IT-Berufen. FI-Podcast_003_Einstieg_in_die_Ausbildung.mp3 (Länge ca. 32 Minuten, für Play/Pause einfach den Link anklicken) Ein gelungener Start in die Ausbildung Stell viele Fragen. Verstehe alles, was du tust. Nimm deine/n Ausbilder/in in die Pflicht. Lerne so viele Kollegen wie möglich kennen. Nutze jede Gelegenheit, um neue Technologien kennenzulernen. Baue dir direkt eine Leseliste für Neuigkeiten auf (z.B. Blogs, c't). Fundiertes Wissen vermitteln hauptsächlich Bücher (zum Buchclub zum Handbuch für Fachinformatiker). Sieh das Berichtsheft nicht als lästige Pflicht, sondern mach das Beste draus. Das Gleiche gilt für die Berufsschule. Achte von Anfang an auf einen ergonomischen Arbeitsplatz. Du kannst gar nicht früh genug anfangen, dich auf die Prüfung vorzubereiten. Wenn dein Unternehmen dich nicht gut betreut, such dir ein anderes und leg Beschwerde bei deiner IHK ein. Wie immer hoffe ich, dass ein paar interessante Inhalte für den ein oder anderen (angehenden) Azubi dabei sind. Wenn ihr noch weitere Tipps für die "Neulinge" habt, dann schreibt gerne einen Kommentar. Viele Grüße! Stefan PS: Ich habe einen RSS-Feed für diesen Podcast eingerichtet, damit du dir die Episoden auch direkt im Podcatcher deiner Wahl anhören kannst: http://fiae.link/FIPodcastRSS