stefan.macke

Früher gab es mal Beispiele auf dieser Seite, aber seit der Umstellung auf die neue Forensoftware, sind die nicht mehr da. Du kannst aber bitte einmal die Suchfunktion im Forum nutzen. Darüber findest du sicherlich Beispiele für Projektarbeiten. Zum Beispiel diese hier auf der ersten Ergebnisseite: Alternativ habe ich ein paar Dokus (FIAE und FISI) hier zum Download bereitgestellt: Beispiele für Projektarbeiten (Anträge, Dokumentationen, Präsentationen)

Ich habe absolut keine Ahnung was SIEM und LMS ist, aber die Rolle (Software-)Architekt heißt nicht, dass man nicht mehr programmieren muss/sollte. Why Should Software Architects Write Code?

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

Es werden definitiv Teilpunkte vergeben. Deswegen empfehle ich auch immer, bei jeder Aufgabe etwas hinzuschreiben. Bei den SQL-Aufgaben z.B. zumindest "SELECT t1.Spalte1, t2.Spalte2 FROM Tabelle1 t1, Tabelle2 t2". Allein dafür kann es je nach Aufgabe schon die halbe Punktzahl geben!

Hallo zusammen, unser Softwareentwickler-Stammtisch organisiert aktuell eine kleine Konferenz zum Thema "Softwareentwicklung im Mittelstand". Die "SEROM" (für Softwareentwicklung im Raum Oldenburger Münsterland) findet am 04.11.2016 um 13 Uhr im Fizz in Vechta statt. Der Eintrittspreis von 39 EUR enthält die komplette Verpflegung inkl. Abendessen und deckt lediglich die Kosten der Veranstaltung. Das heißt, wir verdienen nichts daran. Auch die Speaker bekommen lediglich kostenfreien Eintritt. Es geht uns hauptsächlich um eine Möglichkeit zum Erfahrungsaustausch zwischen Softwareentwicklern/-innen aus kleinen und mittelständischen Unternehmen (natürlich mit Fokus auf unsere norddeutsche "Metropolregion", den Güllegürtel ), die ja durchaus andere Anforderungen an die Softwareentwicklung haben können, als hippe Startups oder große Konzerne. Die Inhalte der neun spannenden Vorträge kann man sich hier anschauen: https://serom.de/konferenzprogramm/ Die Tickets sind ab sofort erhältlich: https://serom.de/tickets/ Die Anzahl der Teilnehmer ist auf 50 begrenzt, also nichts wie los und anmelden! Falls ihr Bekannte oder Kollegen habt, die vielleicht Interesse an einer Teilnahme haben, leitet diese Info auch gerne weiter. Wir freuen uns über jeden Besucher! Viele Grüße! Stefan