stefan.macke

Kann ich nachvollziehen. Mit Discourse nähert man sich ja eher einer Plattform wie Stack Overflow an (ist ja auch der gleiche Entwickler ). Da würde es bestimmt schwierig, die alten Beiträge sinnvoll zu migrieren. Alls klar. Das ist verständlich. Ich habe auch nichts gegen bezahlte Software. Damit verdienen wir schließlich auch unser Geld. Hat mich nur gewundert, da ich dachte, dass es auch gute Lösungen im Bereich Open Source gibt.

Grundsätzlich stimme ich da zu. Allerdings habe ich schon zu viele "Programmierer" gesehen, die sich genau so Programmieren beigebracht haben, und mit Verlaub völligen Schrott produzieren. Der Code läuft. Aber das war's dann auch. Doppelter Code, unnötige Instruktionen, Seiteneffekte ohne Ende, ellenlange Klassen und Methoden. Leider gibt es auch immer wieder Prüflinge, die genau so arbeiten: "Der Code läuft; ich bin fertig." Sobald man dann die oberflächlichste Frage zum Warum und Wie stellt, bleiben sie häufig jegliche Antwort schuldig. Will sagen: Man muss auch die Theorie hinter dem Programmieren beherrschen und einen guten Stil lernen. Und den lernt man am schnellsten - so zumindest meine Meinung - indem man direktes Feedback zum Code bekommen. Am besten von jemandem, der weiß, was er tut. Also z.B. dem/r Ausbilder/in. Meine Empfehlung ist daher: Ja, programmiert so viel wie möglich. Aber kopiert nicht einfach ohne nachzudenken Code aus dem Internet und lasst am Ende mal jemanden über euren Code schauen und euch ein Feedback zu möglichen Optimierungen geben. Und Berufsschullehrer sind sicherlich genau so gut - wenn nicht aufgrund ihrer Ausbildung noch besser - für diese Aufgabe geeignet wie Ausbilder/innen.

Hallo Stefan, nach einer kurzen Umgewöhnungszeit finde ich das neue Forum inzwischen auch gut! Gerade die Darstellung auf Mobilgeräten ist vorbildlich. Was ich mich aber die ganze Zeit frage: Gibt es keine gute Forensoftware, die kostenfrei ist? Es hört sich so an (und sieht so aus), als wäre die neue Software ein kommerzielles Produkt. Der Forenmarkt müsste doch auch irgendein brauchbares Open-Source-Produkt abwerfen, oder nicht? Und hast du vor der Umstellung mal an so etwas wie Discourse (https://www.discourse.org/) gedacht? Oder sollte der "Charme" eines echten Forums erhalten bleiben? Viele Grüße! Stefan

Danke sehr. Es freut mich, wenn ich mit der Liste helfen konnte!

Wenn dein Prüfungsausschuss die Einhaltung der 70 Stunden und die fehlende Wirtschaftlichkeit tatsächlich nicht bemängelt und tatsächlich nur die genauere Gliederung deines Projektablaufs fordert, dann mach das einfach so wie von arlegermi beschrieben. Ich meinte 7-8 Stunden pro Unterpunkt, wobei die meisten Phasen deutlich kürzer sein werden. Die längste Phase ist erfahrungsgemäß die Projektdokumentation selbst, die von vielen Prüflingen mit 7-8 Stunden angesetzt wird (falls sie überhaupt Teil der Projektlaufzeit sein müssen). Also als Beispiel deine Phase "Dokumentation": Dokumentation (14h)Erstellen der Kundendokumentation (5h)Erstellen der Entwicklerdokumentation aus JavaDoc-Kommentaren (1h)Erstellen der Projektdokumentation (8h)Dein Beschreibungstext liest sich eigentlich gut und ist verständlich. Wenn dein Ausschuss also wirklich nur die genauere Gliederung von dir verlangt, sollte der Genehmigung nichts weiter im Wege stehen. Ich kann nur sagen, wie es bei uns im Ausschuss laufen würde. Und da würde das Projekt aufgrund der "falschen" Projektlaufzeit und der fehlenden Wirtschaftlichkeitsbetrachtung abgelehnt. Für letzteren Punkt gibt es sogar extra einen vordefinierten "Ablehnungstext" im IHK-System. Insgesamt würde ich dir nach der Schilderung deines Ausbildungsumfelds noch dringend dazu raten, auch private Zeit in dein Projekt zu investieren (oder zumindest in die Projektdokumentation, die ja letztlich nur bewertet wird).

Dem würde ich zustimmen. Um vernünftig programmieren zu lernen, muss man meiner Meinung nach praktisch arbeiten. Auch als Azubi sollte man daher schon "echte" Projekte umsetzen (natürlich mit konstruktivem Feedback des/r Ausbilders/in). Um Fachbegriffe wie "Polymorphie" im Fachgespräch vernünftig erklären zu können, reicht es nicht, die Definition aufsagen zu können. Man sollte selbst erfahren haben, wie das funktioniert und was die Vor- und Nachteile sein. Und das geht fast nur mit Beispielen aus der eigenen Praxis.

Dem würde ich zustimmen. Um vernünftig programmieren zu lernen, muss man meiner Meinung nach praktisch arbeiten. Auch als Azubi sollte man daher schon "echte" Projekte umsetzen (natürlich mit konstruktivem Feedback des/r Ausbilders/in). Um Fachbegriffe wie "Polymorphie" im Fachgespräch vernünftig erklären zu können, reicht es nicht, die Definition aufsagen zu können. Man sollte selbst erfahren haben, wie das funktioniert und was die Vor- und Nachteile sein. Und das geht fast nur mit Beispielen aus der eigenen Praxis.

Was mir sofort auffällt: Dein Projekt dauert keine 70 Stunden. Das würde bei uns sofort abgelehnt. Du musst exakt 70 Stunden planen. Deine Zeitplanung ist außerdem zu grob. Ich empfehle maximal (!) 7-8 Stunden pro Phase, besser weniger (weil genauer). Du hast keinerlei Wirtschaftlichkeitsbetrachtung eingeplant. Außerdem ist keine methodisches Vorgehen erkennbar: keine Modellierung (Architektur, Klassendiagramm usw.), keine Use-Cases, keine MockUps usw. Sind die paar Zeilen dein gesamter Projektantrag? Oder hast du noch Fließtext unterschlagen? Wenn ja, stell bitte deinen gesamten Antrag zur Bewertung ein (bitte anonymisiert). Ansonsten musst du definitiv noch einmal ran. Die paar Stichpunkte reichen nicht als Antrag. Du hast ja nichtmal genau beschrieben, was deine Anwendung eigentlich macht, geschweige denn einen Projektnamen genannt. Ein paar allgemeine Hinweise findest du noch hier: Inhalte des Projektantrags.

Das habe ich ehrlich gesagt noch nie gehört. Das Berichtsheft trägt meines Wissens nach nicht zur Bewertung des Prüflings bei. In keinem mir bekannten Bewertungsschema einer IHK wird das Berichtsheft erwähnt. Es ist zwar Zulassungsvoraussetzung für die Prüfung, aber einen Einfluss auf die Note darf es meines Wissens nach nicht haben. Vielleicht kommen die Prüfer aber durch die Aufgaben im Berichtsheft auf spannende Fragen für das Fachgespräch. Wir schauen ins Berichtsheft, um zu kontrollieren, ob der Ausbildungsbetrieb seinen Job gemacht hat und der Prüfling nicht nur Kaffee kochen durfte.

Jo, das passt. Aus dem Rheinwerk-Verlag. Ende September 2015 erscheint schon die neue Auflage. Zur Sicherheit noch das "Tabellenbuch" dazu. Das ist eine gute Grundlage.

Wie detailliert du dein Berichtsheft führen musst, kann dir nur deine IHK sagen. In Oldenburg reicht z.B. ein Wochenprotokoll (vgl. Vorlage für das Berichtsheft). Ich persönlich finde Tagesprotokolle völlig unsinig. Den Grund hast du schon genannt: Lange Projekte und komplexe Aufgaben.

Ok. Wieder was gelernt Zwei Fragen dazu: 1) Steht auf dem Zeugnis nur eine gemeinsame Note oder werden beide Teile gezeigt? 2) Ist die Gewichtung Präsi/FG 50/50 oder 40/60 (wie oben genannt)?

Ok, dann werde ich das mal glauben Eine allgemeine Vorgabe ist das wohl allerdings nicht. Mir ist nur diese Matrix für die Bewertung der beiden Teile bekannt: Umsetzungshilfen für die neue Prüfungsstruktur der IT-Berufe (ab S. 71).

Dafür müsstest du uns schon sagen, welche Fragen richtig und welche falsch waren. Beispiel: Ist die for-Schleife kopf- oder fußgesteuert? Richtig. Allerdings trivial und wenig Punkte wert. Was ist Objektorientierung? Keine Antwort. Deutlicher Punktabzug. Woher hast du die Information? Von deiner IHK? Dann würde ich gerne wissen, welche IHK das ist. So eine Aufteilung habe ich noch nie gehört oder gelesen. Für Präsentation und Fachgespräch gibt es eine gemeinsame Note, die nicht weiter unterteilt wird. Weder auf dem Zeugnis, noch in den Unterlagen der Prüfer.

Es wird also mal wieder Zeit für die Glaskugel Wie immer die Standardempfehlung: Schau dir die alten Prüfungen an und lies die Standardbücher.

Das ist ja super Deutlich weniger zu tun! Als ich damals (2006) meine Prüfung hatte, war der Umfang überhaupt nicht reguliert. Da durfte ich komplette Anforderungsdokumente usw. mit abgeben und bin damit über 100 Seiten gekommen. Für die Prüfer sicher nicht optimal. Von daher ist die Einschränkung schon völlig in Ordnung. Es ist ja auch ein wichtiger Lernerfolg, wenn ein Prüfling sich bei einem langen Projekt auf die wichtigsten (!) Inhalte konzentrieren und sie vernünftig rüberbringen kann. Daher mein Tipp: nicht uninteressanten Kram (wie z.B. seitenweise Code mit Gettern/Settern) in die Doku packen, sondern nur aussagekräftige Inhalte (z.B. den Kernalgorithmus). Viele Grüße! Stefan

Hallo zet, jede IHK hat da wohl leider wirklich ihre eigenen Richtlinien. Bei der IHK Oldenburg sind z.B. 40 Seiten vorgegeben, also 15 Seiten Text und max. 25 Seiten Anhang. Die Vorgaben würde ich auch immer einhalten, da du sonst im Vergleich zu anderen Prüflingen, die sich daran gehalten haben, schlecht aussiehst. 15 Seiten Text sind also meiner Meinung nach Pflicht (und zwar nicht unterbrochen durch riesige Grafiken oder Tabellen, die gehören in den Anhang!). Ich habe vor einiger Zeit eine Vorlage für die Abschlussdokumentation mit vielen Beispielinhalten erstellt. Das hier ist das Inhaltsverzeichnis als Anregung: Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis 1. Einleitung 1.1. Projektumfeld 1.2. Projektziel 1.3. Projektbegründung 1.4. Projektschnittstellen 1.5. Projektabgrenzung 2. Projektplanung 2.1. Projektphasen 2.2. Abweichungen vom Projektantrag 2.3. Ressourcenplanung 2.4. Entwicklungsprozess 3. Analysephase 3.1. Ist-Analyse 3.2. Wirtschaftlichkeitsanalyse 3.2.1. "Make or Buy"-Entscheidung 3.2.2. Projektkosten 3.2.3. Amortisationsdauer 3.3. Nutzwertanalyse 3.4. Anwendungsfälle 3.5. Qualitätsanforderungen 3.6. Lastenheft/Fachkonzept 4. Entwurfsphase 4.1. Zielplattform 4.2. Architekturdesign 4.3. Entwurf der Benutzeroberfläche 4.4. Datenmodell 4.5. Geschäftslogik 4.6. Maßnahmen zur Qualitätssicherung 4.7. Pflichtenheft/Datenverarbeitungskonzept 5. Implementierungsphase 5.1. Implementierung der Datenstrukturen 5.2. Implementierung der Benutzeroberfläche 5.3. Implementierung der Geschäftslogik 6. Abnahmephase 7. Einführungsphase 8. Dokumentation 9. Fazit 9.1. Soll-/Ist-Vergleich 9.2. Lessons Learned 9.3. Ausblick Literaturverzeichnis Eidesstattliche Erklärung A. Anhang A.1. Detaillierte Zeitplanung A.2. Lastenheft (Auszug) A.3. Use Case-Diagramm A.4. Pflichtenheft (Auszug) A.5. Datenbankmodell A.6. Oberflächenentwürfe A.7. Screenshots der Anwendung A.8. Entwicklerdokumentation A.9. Testfall und sein Aufruf auf der Konsole A.10.Klasse: ComparedNaturalModuleInformation A.11.Klassendiagramm A.12.Benutzerdokumentation Viele Grüße! Stefan