stefan.macke

In der Doku fallen meiner Erfahrung nach tatsächlich nur wenige Prüflinge durch, aber gerade so "ausreichend" hatte ich schon öfter.
Im Fachgespräch kann es durchaus häufiger zum Nichtbestehen kommen. Wenn man als Entwickler nicht einmal den Unterschied zwischen Objekt und Klasse erklären kann, ist das einfach nicht mehr "ausreichend".

Das ist falsch. Du kannst sehr wohl durchfallen. Wenn dein Projekt nicht umfangreich genug ist, du im Fachgespräch das erwähnte Blackout hast, du nur 5 Minuten präsentierst usw.
Teil A ist ein separater Prüfungsteil mit eigenen Anforderungen. Du kannst sowohl in der Dokumentation durchfallen (z.B. Thema verfehlt, zu kurz, inhaltliche Fehler usw.), als auch in Präsentation/Fachgespräch (z.B. schlechte Präsentation ohne Inhalt, falsche Antworten im Gespräch).

Das ist falsch. Du kannst sehr wohl durchfallen. Wenn dein Projekt nicht umfangreich genug ist, du im Fachgespräch das erwähnte Blackout hast, du nur 5 Minuten präsentierst usw.
Teil A ist ein separater Prüfungsteil mit eigenen Anforderungen. Du kannst sowohl in der Dokumentation durchfallen (z.B. Thema verfehlt, zu kurz, inhaltliche Fehler usw.), als auch in Präsentation/Fachgespräch (z.B. schlechte Präsentation ohne Inhalt, falsche Antworten im Gespräch).

Naja, "gar kein Problem" würde ich nicht sagen. Das bedeutet ja schon, dass eine Fehlplanung vorliegt, die man sauber begründen muss. Die Prüflinge sollen mit dem Projekt unter zeitlichen Restriktionen ja auch ihre planerischen Fähigkeiten unter Beweis stellen. Also nicht einfach schreiben: "Huch, da habe ich mich wohl verschätzt."

Die Verweise sollten kein Problem sein. Wie du selbst schon schreibst, ist es besser auf die anderen Kapitel zu verweisen, anstatt dich ständig zu wiederholen. Du solltest die wenigen verfügbaren Seiten besser mit mehr Inhalt füllen, als immer das Gleiche zu erzählen.
Aus dem Sollzustand würde ich die Bewertungen raushalten. Hier würde ich erstmal nur die Anforderungen beschreiben. Welche Lösung diese Anforderungen am besten umsetzt, entscheidest du dann bei der Produktauswahl zum Beispiel mit einer Nutzwertanalyse. Ich glaube zwar nicht, dass dir dafür Punkte abgezogen werden, aber eine Trennung wäre meiner Meinung nach etwas schöner.

Um Unternehmen, die Wert darauf legen, dass du bereits programmieren kannst, würde ich einen großen Bogen machen. Eine Ausbildung kostet den Betrieb immer Zeit und Geld. Prüfe genau, ob du ausgebildet oder ausgebeutet werden sollst.
Ansonsten hast du recht. Mit einigen GitHub-Projekten zeigst du dein Interesse an der Entwicklung. Das kommt sicher gut an. Dass es jetzt gleich 10 verschiedene Sprachen sein müssen, glaube ich aber nicht.

Nö.
Das heisst für mich als Ausbilder: viel mehr Arbeit als eine Ausbildung von der Pieke an. Denn ich darf erstmal langwierig kontrollieren, ob du das, was du dir selber angeeignet hast auch richtig verstanden hast. Spaghetticode mag niemand, auch wenn am Ende das Programm funktioniert.

Um Unternehmen, die Wert darauf legen, dass du bereits programmieren kannst, würde ich einen großen Bogen machen. Eine Ausbildung kostet den Betrieb immer Zeit und Geld. Prüfe genau, ob du ausgebildet oder ausgebeutet werden sollst.
Ansonsten hast du recht. Mit einigen GitHub-Projekten zeigst du dein Interesse an der Entwicklung. Das kommt sicher gut an. Dass es jetzt gleich 10 verschiedene Sprachen sein müssen, glaube ich aber nicht.

Um Unternehmen, die Wert darauf legen, dass du bereits programmieren kannst, würde ich einen großen Bogen machen. Eine Ausbildung kostet den Betrieb immer Zeit und Geld. Prüfe genau, ob du ausgebildet oder ausgebeutet werden sollst.
Ansonsten hast du recht. Mit einigen GitHub-Projekten zeigst du dein Interesse an der Entwicklung. Das kommt sicher gut an. Dass es jetzt gleich 10 verschiedene Sprachen sein müssen, glaube ich aber nicht.

Vergessene Zeilen sind meiner Erfahrung nach leider Standard. Macht das Korrigieren nicht gerade leichter. :-/ Von daher ist der Tipp mit dem Schmierzettel sehr gut!
Ansonsten würde ich niemals Zeilennummern nutzen. Das macht es nur noch unübersichtlicher und vor allem deutlich aufwendiger in der knappen Prüfungszeit. Einfach ein Sternchen an die betreffende Stelle und den fehlenden Code unten drunter schreiben.
In einigen Prüfungen musste ich mir dann allerdings den Code mit *1 bis *9 selbst zusammenbasteln ;-) Von daher hier nochmal der Hinweis auf den Schmierzettel!

Es geht um die Logik deiner Domäne. MVC ist gut und schön, aber das wird in jedem Webprojekt verwendet. Welche Logik ist für dein Projekt individuell? Diese Logik beschreibt deine Domäne.
Beispiele:
Versicherung: Berechnung der Beiträge, Bewertung des Risikos Autovermietung: Berechnung des Mietpreises, Empfehlung von passenden Autos Shopsystem: Empfehlung von Produkten, Rabattberechnung

Alles was du beschrieben hast ist deine Geschäftslogik Deine Domäne ist das Erstellen von Berichtsheften!

Na klar! Gerne auch mit interessanten (!) Quellcodebeispielen

Das darf in den Fließtext.
Aber ist das auch sinnvoll? Das wird ja bestimmt viel Platz wegnehmen, der dir dann für den Text fehlt. Füll den wertvollen Platz besser mit wichtigen Inhalten und pack das Diagramm in den Anhang.
Ich persönlich ziehe z.B. bei der Bewertung der Dokumentationen alle Grafiken, Tabellen usw. größer 1/2 Seite von der Seitenzahl ab.

Das kann ich nur bestätigen! Unbedingt zu Beginn der Dokumentation alles zum Verständnis Notwendige erklären. Zur Not (wenn du im Fließtext zu wenig Platz hast) packst du es mit einer deutlichen Referenz in der Einleitung in den Anhang.
Und lass mal jemanden drüberlesen, der den Kontext nicht hat (also vielleicht einen unbeteiligten Kollegen oder noch besser einen betriebsfremden Mitschüler) und frag, ob die Inhalte verständlich sind.
Einer meiner Hauptkritikpunkte an Dokumentationen ist, dass das Thema unverständlich erklärt wird. Da frage ich mich teilweise noch nach dem Lesen der gesamten Doku, was überhaupt der Sinn des Projekts war.

...und das kann man auch gar nicht! Wenn wir uns kurz an die Definition erinnern:
Erfahrene Entwickler skizzieren ein Tabellenmodell sicherlich gleich in der dritten Normalform runter. Aber gerade als Anfänger würde ich die drei Normalformen der Reihe nach durchgehen, damit nichts vergessen/übersehen wird. Dein Problem mit der Modellierung lässt sich wohl eher lösen, indem du dem Prozess der Normalisierung strikt folgst, anstatt Schritte zu überspringen. Später bekommst du dann einen Blick dafür, wie du dir die expliziten Einzelschritte sparen kannst.
 

Die erste und zweite Normalform soll man nicht überspringen.

Das ist einfach!
SELECT "Berufserfahrung", "Arbeitsort", "Grösse der Firma", (AVG("Gesamtjahresbrutto") / (52 - AVG("Anzahl der Urlaubstage") / 5)) / AVG("Arbeitsstunden pro Woche real") AS "Stundensatz"
FROM "Wie viel verdient ihr?"
WHERE "letzter Ausbildungsabschluss" LIKE '%FISI%'
GROUP BY "Berufserfahrung", "Arbeitsort", "Grösse der Firma"
ORDER BY "Stundensatz" DESC
 

Anders und aus der Ausbildersicht formuliert: es ist für einen Ausbilder viel schwerer, erst einmal auszuloten, was sich ein Azubi aus falschem Ehrgeiz vorher schon falsch angeeignet hat und dann ihm das wieder abzugewöhnen als einfach bei Null sauber anfangen zu können.
 

Da stimme ich zu: Frag deinen zukünftigen Arbeitgeber. Allerdings wundert mich, dass du das noch nicht weißt. Was hat man dir denn beim Bewerbungsgespräch über deine nächsten drei Jahre erzählt? Nichtmal, womit du täglich arbeiten wirst?
Ansonsten kann ich nur wiederholen: Du musst für eine Ausbildung nicht programmieren können. Es wird niemand böse sein, wenn du es kannst, aber es sollte keine Voraussetzung für die Ausbildung sein. Hierzu kann ich nun endlich auch auf den Podcast verweisen!
Häufige Fragen im Forum - Fachinformatiker-Podcast #1

Grundsätzlich finde ich die Beschreibung gut. Ich würde das allerdings nicht als einen "Namen" bezeichnen, sondern als Bezeichnung oder Titel. Ich würde mir auf jeden Fall noch einen Kurznamen dazu ausdenken. Das ist deutlich einfacher bei der Kommunikation und auch für die Projektdoku/-präsi. Ein knackiger Name wäre gut, zur Not ein Akronym.
Beispiele:
ERP2SQL ERP-Online ERP-Shop ERP-Export

Evtl. kannst Du die Kollegen über ihre Funktion benennen. Zum Beispiel: "Teamleiter", "Server-Admin", "Azubi", "XYZ-Programmierer", usw.

Das sehe ich etwas anders. Eine Programmiersprache kannst du in kurzer Zeit lernen, zu programmieren nicht. Genau das ist die Aufgabe der dreijährigen Ausbildung. Die richtige Denk- und Herangehensweise für die Problemlösung ist die zentrale Fähigkeit eines Anwendungsentwicklers. Die Sprache ist nur ein Mittel zu Zweck.
Das hilft dir allerdings jetzt auch nicht weiter. Daher schlage ich vor, du versuchst so viele Probleme wie möglich für die Prüfung zu lösen. Und zwar nicht auf dem Papier, sondern in einer echten Sprache. Meiner Meinung nach kann man sich nicht durch stumpfes Lernen auf die Algorithmus-Aufgaben vorbereiten. Denn es geht hier nicht um Auswendiglernen, sondern um die Anwendung des Wissens.
Allerdings halte ich es für unmöglich, das in einem Monat hinzubekommen. Daher ist eine alternative Empfehlung: Streich die Programmieraufgaben (die ohnehin sehr viel Zeit kosten) gedanklich und fokussiere dich auf die Dinge, die du tatsächlich auswendig lernen kannst. Es gibt noch so viele andere Themen, die du können musst (z.B. UML, Datenbanken, SQL, Projektmanagement). Die solltest du nicht zugunsten der Programmierung vernachlässigen!

Ich arbeite in einer privaten Krankenversicherung, die viele domänenspezifische Begriffe verwendet, die sich nicht (gut) ins Englische übersetzen lassen. Daher entwickeln wir alles auf Deutsch. Das führt allerdings zu teils komischen Methodennamen wie "getAlter()" usw.

Ich arbeite in einer privaten Krankenversicherung, die viele domänenspezifische Begriffe verwendet, die sich nicht (gut) ins Englische übersetzen lassen. Daher entwickeln wir alles auf Deutsch. Das führt allerdings zu teils komischen Methodennamen wie "getAlter()" usw.