stefan.macke

Absolute Empfehlung auch von mir! Ein tolles Buch mit vielen guten Tipps - und zwar programmiersprachenunabhängig. In Deutschland gibt es passend dazu auch die Initiative "Clean Code Developer": http://clean-code-developer.de/

Du musst für die Beziehung zwischen den beiden Entitäten in beide Richtungen separat (!) überlegen, wie viele Ausprägungen der anderen Entität zu einer Ausprägung der aktuellen Entität gehören. Also immer zwei (!) Sätze bilden, die mit "1" beginnen. Dann nimmst du die beiden Ergebnisse der jeweiligen Gegenseite und bist fertig. Beispiele:
Ein Login ist genau einem (1) Benutzer zugeordnet. Ein Benutzer hat genau einen (1) Login. -> 1:1 Ein Artikel gehört zu einer (1) Warengruppe. Eine Warengruppe hat mehrere (n) Artikel. -> 1:n Ein Hund hat mehrere (m) Herrchen. Ein Herrchen hat mehrere (n) Hunde. -> m:n

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.

Wobei die Rechenaufgaben in den IHK-Prüfungen eigentlich meist so einfach sind, dass man sie auch auf dem Papier lösen könnte...

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

Wir haben uns mit einer riesigen Mindmap auf die Fragen vorbereitet. 
Nach Abschluss von Doku und Präsentation ist jeder seine Werke noch einmal durchgegangen und hat sich alle technischen Schlagworte rausgeschrieben.
Im Beispiel von arlegermi wäre das dann z.B. "REST" gewesen.
Diese Schlagworte wurden dann erstmal in Gruppen eingeordnet, z.B. ist die Grundidee hinter REST ja meist irgendein Client-Server Austausch. Damit hätten wir dann den Kasten "Client/Server" mit dem Bubble "REST". 

Jetzt kannst du dir noch überlegen, welche verbreiteten Alternativen es dazu gibt. Mir würden spontan RCP, SOAP und WSDL einfallen. Diese dann als weitere Bubbles an den "Client/Server"-Kasten schreiben. 

Je nach dem wie intensiv du dich mit dem Thema auseinandergesetzt hast (--> je mehr, desto höher die Wahrscheinlichkeit für tiefergehende Fragen), kannst du dann noch weitere Unterpunkte zu den Bubbles finden. In diesem Fall wäre wahrscheinlich noch das bzw. die möglichen Austauschformate interessant. Da würde dann z.B. XML als weitere Bubble stehen.
Da hast du dann direkt "Querverweise", z.B. basiert WSDL auf XML. Bei allgemeinen Dingen wie XML, solltest du dich dann gleichzeitig aber auch wieder fragen, welche Alternativen es gibt (und worin die sich unterscheiden, etc.). 

So spannst du nach und nach einen recht großen Baum auf und hast am Ende einen relativ breiten Überblick über mögliche Themen für die Fragerunde.
Uns hat das sehr geholfen, bei allen Prüflingen gab es - zumindest bei den technischen Fragen - keine Überraschungen, da wir mit unseren Mindmaps alles abgedeckt hatten. 
Das Ganze hilft dir natürlich nicht für die projektunabhängigen Fragen zu allgemeinen Dingen wie Arbeitsrecht, Versicherungen, Steuern, etc. pp.
Dafür solltest du eine gesonderte Vorbereitung machen

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).

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).

Ich versuche mal einen anderen Ansatz:
Struktogramme und PAPs lassen sich schwer nachträglich korrigieren, kosten durch das Zeichnen mehr Aufwand und Planung (wie groß wird die Zeichnung?) und erzwingen eine bestimmte Form, bei der man einiges falsch machen kann.
Meine Empfehlung ist deshalb, sich von Anfang an auf Pseudocode festzulegen. Ein großer Vorteil hierbei ist, dass es für den Korrigierenden schwer ist, formelle Fehler anzustreichen, einfach weil es keine festgelegte Form gibt. Solange die Logik stimmt, bekommt man seine Punkte.
Wer natürlich in Diagrammen denkt, kann meinen Post getrost ignorieren.

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) werden Die Vorkenntnisse reichen vielleicht nicht aus, um ein außergewöhnliches Thema sauber und fundiert umzusetzen

zu 1: Es gibt da erhebliche Unterschiede in den Seitenzahlen. Richte dich nach den Vorgaben deiner IHK.
zu 2: Du sollst in der Doku das Projekt und nicht das Programm dokumentieren. Du darfst davon ausgehen, dass der PA in der Lage ist, dir zu folgen.
zu 3: Warum werden in der Abschlussarbeit immer wieder Themen gewählt, die man noch nie vorher gemacht hat? Zu deiner Frage: Wenn Du so einen Antrag stellst, dann geht man davon aus, dass Du auch entsprechendes Wissen hast. Und ausreden wie Entschuldigung ich habe mich in das Thema erst vor sechs Wochen eingearbeitet zählen nicht.
zu 4: Du bist ein halber Kaufmann und kaufmännische Ansätze sollte man auch in der Doku zeigen und wenn es nur eine Kostenberechnung ist. Und es fallen immer Kosten an. Jede andere Aussage ist falsch.
 
Was hast Du denn im ersten Antrag machen wollen?
 
Du kannst jederzeit deinen Projektantrag hier zur Diskussion stellen.

Die wichtigste Lektüre ist da denke ich ganz klar: 
IT-Handbuch für Fachinformatiker

Genau! Wenn sich aber auch nach dieser Zeit nichts in Richtung Programmierung tut, würde ich deine/n Ausbilder/in darauf ansprechen. Programmieren ist deine Kernqualifikation als Anwendungsentwickler und der sollte ausreichend Zeit in der Ausbildung gewidmet werden.

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