stefan.macke

Darf ich mal fragen, was du eigentlich vorhast? Bist du ITler (z.B. FISI) und möchtest gerne in die Anwendungsentwicklung? Oder worauf willst du dich bewerben? Deine Beiträge lassen eher darauf schließen, dass du von der gesamten Materie keine Ahnung hast (das ist nicht böse gemeint). Auf welche Stelle möchtest du dich mit den selbst erlernten Grundlagen bewerben und welche Hoffnungen machst du dir?

Wie kommst du von Datenbanken auf XML? Das hat erstmal nichts miteinander zu tun. Höchstens, dass beides Daten enthält. Für den Zugriff auf (relationale) Datenbanken brauchst du XML nicht. Es gibt allerdings dokumentenorientierte Datenbanken wie MongoDB, die Daten nicht in Tabellen, sondern in strukturiertem Text ablegen. Dann aber nicht in XML, sondern in JSON.

Das sehe ich anders. ACID würde ich kaum als Grundlage bezeichnen. Um ein paar SELECT-Abfragen in mein Programm einzubauen, muss ich kein Transaktionskonzept erläutern können und noch weniger die Eigenschaften eines solchen kennen. Auch den Vorgang der Normalisierung muss ich nicht beherreschen, um die Daten abfragen zu können. Sicherlich ist es sinnvoll, zu verstehen, warum Daten überhaupt normalisiert abgelegt werden, aber einen JOIN kann ich auch ohne das Hintergrundwissen bauen. Ich vergleiche das jetzt mal mit der Polymorphie der Objektorientierung. Sicherlich muss ich das - irgendwann einmal - lernen. Aber wenn ich anfange zu programmieren, werde ich vielleicht doch zunächst mal eine if-Abfrage schreiben. Ich würde eher versuchen, zunächst einmal etwas Praktisches zu machen und dann (natürlich zeitnah) in die Theorie dahinter einzusteigen.

Als Empfehlung für Doku/Präsi: Verwende nicht zuviel Platz/Zeit auf die Erklärung des Gesamtprojekts. Erwähne soviel wie nötig und so wenig wie möglich zum Verständnis deines Projekts. Viele Prüflinge lassen sich ewig über das Gesamtprojekt aus und vernachlässigen dabei ihren eigenen Anteil. Aber um genau den geht es letztlich bei der Bewertung.

Ich würde empfehlen mit SQL anzufangen. Und zwar noch konkreter: mit SELECT. Das ist der Bereich, den ein Entwickler zu 90% (subjektiver Wert) bei seiner Arbeit braucht: Wie bekomme ich vorhandene Daten aus der Datenbank? Danach würde ich mir die Gegenrichtung anschauen: Daten in die Datenbank schreiben: INSERT, UPDATE, DELETE. Damit solltest du eine gute Grundlage für das Tagesgeschäft haben. Wenn du darüber hinaus noch selbst Datenbanken modellieren möchtest, setze dich zuerst mit den Entity-Relationship-Modellen auseinander, die Daten recht abstrakt modellieren. Im Anschluss daran kommt dann der Schritt in die relationale Welt mit dem Tabellenmodell. Und zu guter letzt kannst du dir dann die entsprechenden SQL-Befehle anschauen: CREATE, ALTER usw. So mache ich es mit meinen Azubis und Studenten und lasse sie währenddessen auch schon immer gleich die passenden IHK-Aufgaben bearbeiten, damit sie gleich ein Gefühl für die Fragen bekommen und den Sinn hinter dem Lernen sehen.

Ich bin zufällig selbst Softwarearchitekt und bin für die Auswahl von Frameworks und Programmiersprachen zuständig, erarbeite Coding-Conventions und koordiniere die systemübergreifende Kommunikation. Also einfach alles, was über einzelne Projekte hinausgeht und das System als Ganzes betrifft. Oder anders gesagt: Alle Dinge, die später nur schwierig änderbar sind. Ich habe Software-Engineering studiert und programmiere auch noch täglich. Ich denke, das ist ein wichtiger Bestandteil meiner Aufgabe, da ich nur so die Vorgaben, die ich selbst mache, auch anwenden und damit für die Praxis erproben kann. Alles andere wäre Arbeit im "Elfenbeinturm". Ich würde einen Softwarearchitekten auch nicht "über" den Entwicklern sehen. Genau wie Projektleiter, die halt die organisatorischen Dinge in Projekten klären, aber meist auch keine Weisungsbefugnis haben, muss es eben auch technisch Informierte geben, die das Gesamtsystem im Blick haben und für eine geordnete Softwareentwicklung sorgen. Eine spezielle Weiterbildung habe ich nicht absolviert, aber es gibt einige Zertifizierungen für Softwarearchitekten, z.B. hier: http://www.isaqb.org/

Warum das denn? Webprojekte machen heutzutage gefühlt die Mehrzahl der Abschlussprojekte aus. Und man kann alles zeigen, was für den Beruf interessant ist: Datenbank, Oberfläche, Logik.

Aber warum solltest du das tun? Damit verschenkst du doch nur wertvolle Projektzeit. Falls es am Ende kein "sehr gut" wird, wirst du dich immer fragen, ob es vielleicht mit 70h geklappt hätte. Zwei Stunden bekommst du immer verteilt!

Ein paar Sachen fallen mir direkt auf: Lange Phasen (>8h) runterbrechen. Welche Artefakte werden erstellt (Pflichtenheft, Klassendiagramm usw.)? 6h für Fehlerbehebung? Hört sich nach (nicht richtig verplanter) "Pufferzeit" (von fast 10% der Projektzeit) an. 11h für Projektdoku? Das sind 15% der Zeit. Meiner Meinung nach deutlich zu viel. Gibt es keine Doku für die Entwickler? Die Wirtschaftlichkeitsbetrachtung fehlt komplett. 68h Gesamtzeit kann ich auf keinen Fall empfehlen.

Wie sieht es denn eigentlich mit angewendeten Methodiken aus? Modellierst du was mit UML? Erstellst du ein ERM oder Tabellenmodell? Entwirfst du MockUps für deine Oberflächen? Welchen Entwicklungsprozess setzt du ein? Wie dokumentierst du die Tests? Gibt es keine Kundendokumentation?

Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik §15, Abs. 2: Ob die Projektdokumentation innerhalb der 70 Stunden geschrieben werden muss, ist von IHK zu IHK unterschiedlich. Bitte bei deiner IHK nachfragen.

Es ist ein weit verbreiteter Irrtum, dass bei einigen Projekte eine Kosten-/Nutzenrechnung nicht durchführbar ist. Es gibt immer eine monetäre Begründung für Projekte. Wenn dem nicht so wäre, würde das Projekt nicht durchgeführt. Welches Unternehmen kann sich langfristig halten, wenn es nicht wirtschaftliche Projekt umsetzt? Irgendjemand wird von deinem Projekt profitieren. Sollte dein Projekt die (unwahrscheinliche) Ausnahme darstellen, kannst du sicherlich mit weichen Faktoren begründen, warum es dennoch umgesetzt werden sollte. Denn irgendeinen Grund für die Durchführung wird es ja geben! Aber ich kann aus deiner Projektbeschreibung schon direkt einige Faktoren rauslesen, die du definitiv monetär darstellen kannst: Automatisierung eines ansonsten manuellen Prozesses Vermeidung von noch größerem Aufwand Vermeidung von Sicherheitsrisiken höhere Kaufrate durch bessere Endkundeninformation

Oh oh, da kommen aber mal wieder die altbekannten Vorurteile aus der Versenkung. Denken wir nur kurz einmal daran, dass die Prüfer alle ehrenamtlich arbeiten. Daher kann man wohl ein über das normale Maß hinausgehendes Interesse am Beruf voraussetzen. Und das geht meiner Meinung nach auch gerade mit einem starken Interesse an Technologie einher. Ich kenne nicht wenige Prüfer, die den Job gerade deswegen machen, weil sie am Ball bleiben und neue Technologien kennenlernen wollen. Eine Programmiersprache für das Abschlussprojekt auf Basis solcher Vorurteile auszuwählen, halte ich für völlig falsch. Es geht darum, einen Mehrwert für das Unternehmen zu schaffen. Und die Programmiersprache muss dafür vom Betrieb vorgegeben werden. Potentielle Vorlieben der Prüfer dürfen dabei keine Rolle spielen.

Ho ho ho, Prolog würde ich jetzt aber nicht als "veraltet" bezeichnen. Erlang basiert auf Prolog. Und Elixir - der große Hype aktuell - basiert auf Erlang. Und gerade die "alten" Konzepte der funktionalen Programmierung sind doch aktuell wieder total hip. Siehe Clojure -> eine Lisp-Variante. Aber zurück zum Thema: Die Programmiersprache interessiert niemanden (Achtung: subjektive Meinung). Sie ist Mittel zum Zweck und kein Prüfer wird sich anmaßen, den Betrieben ihre Werkzeuge vorzuschreiben. Wenn es danach ginge, müsste ich alle SAP-Projekte in ABAP gleich abwerten. Problematisch wird es, wenn du als Prüfling "moderne" Konzepte nicht kennst und erklären kannst. Es interessiert nämlich leider auch niemanden, dass du im Job nur mit Turbo Pascal und Basic programmierst, wenn du im Fachgespräch nichts zur Objektorientierung sagen kannst (umgekehrt aber natürlich genauso, wenn du nur OO machst und nichts zur prozeduralen Programmierung sagen kannst). Eine "alte" Sprache im Unternehmen ist also keine Ausrede dafür, nur alte Konzepte zu beherrschen. Aus eigener Erfahrung sind die meisten Abschlussprojekte heute in "modernen" objektorientierten Sprachen wie Java, C#, Ruby oder PHP (ja ich weiß, dass PHP nicht rein objektorientiert ist) umgesetzt. Ich persönlich würde mich daher sogar über "alte" Sprachen freuen. Ist mal ne Abwechslung. Problematisch an "alten" Sprachen ist vielleicht noch, dass du für die Projektdokumentation und -präsentation übliche Dokumentations- und Entwurfsmethoden wie Klassendiagramme eventuell (!) nicht verwenden kannst. Aber selbst in diesem Fall kannst du auf klassische Darstellungen wie Programmablaufpläne oder Struktogramme ausweichen.

Also zeigt sich wieder mal: Ehrlichkeit währt am längsten! Herzlichen Glückwunsch zur bestandenen Prüfung!

Herzlichen Glückwunsch! Haben die Prüfer denn noch etwas zu deiner Präsentation gesagt, das du kommenden Prüflingen mit auf den Weg geben kannst?

Ich würde Wert auf Konsistenz legen, aber da Pseudocode wie gesagt nicht standardisiert ist, kann ich niemandem Punkte abziehen, wenn er/sie mal "echten" Pseudocode schreibt und mal eine Programmiersprache nutzt. Ich würde als Prüfling einfach darauf achten, dass der Pseudocode verständlich ist. Was der Prüfer nicht versteht, kann er nicht bewerten (und damit meine ich nicht, weil er nicht programmieren kann ). Und Konsistenz trägt sicherlich zum Verständnis bei.

Wenn du damit die Prüfer meinst, sind drei völlig ausreichend. Der Ausschuss setzt sich mindestens aus einem Arbeitgebervertreter, einem Arbeitnehmervertreter und einem Lehrer zusammen. Dann ist der Ausschuss vollzählig und beschlussfähig. Häufig nehmen aber noch andere Prüfer oder sogar Gäste an der Prüfung teil. Bei uns sitzen meist 6 Personen.

Ja.

Absolut lächerlich. Für eine Doku kannst du mindestens eine Stunde Korrekturzeit einplanen. Wenn nicht eher mehr. Wir regeln es in unserem Ausschuss so, dass mind. 2 Prüfer die Doku komplett lesen und bewerten. Aber es liest nicht jeder Prüfer alle Dokus. Das ist zeitlich einfach nicht machbar. Nichtsdestotrotz schauen wir auch gerne in "fremde" Dokus, um einen Eindruck zu bekommen. Vielleicht hast du das mit den 15 Minuten gemeint. Allerdings würde ich persönlich das nicht während der Präsentation machen. Das wäre unhöflich. Und ich würde mir nach dem Überfliegen auch nicht anmaßen, die Doku zu bewerten. Wer ernsthaft glaubt, die Prüfer handeln ein so wichtiges Thema wie die Abschlussprüfung eines Ausbildungsberufes mal eben nebenbei in 15 Minuten ab, der hat nicht alle Latten am Zaun :P

Ahhhhh. Wirf das Unternehmen raus! Eine Folie Maximum. Das trägt rein gar nichts zu deiner Bewertung bei. Zeig lieber deine eigene Arbeit! Sag nur soviel zum Unternehmen wie zum Verständnis deines Themas nötig ist. Alles andere ist eine Werbeveranstaltung, die niemanden interessiert. Kein Prüfling bekommt eine bessere Note, weil alle 23 Auslandsstandorte des 10.000-Personen-Betriebs vorgestellt werden oder die weltmarktführende Software des Betriebs in allen Lizenzvarianten gezeigt wird. So gerne die Chefs sich auch in den IHK-Präsentationen sehen möchten: Es hat einfach keine Relevanz für deine Projektarbeit und vor allem nicht für die Note. Ich habe schon so viele Präsentationen mit teils bis zu 5(!) Minuten Unternehmensvorstellung gesehen, in denen dann wichtige Themen wie die Wirtschaftlichkeit vergessen wurden. Das ist einfach dämlich. Nutz die kostbare Zeit für die Darstellung deiner Leistung.

Das habe ich auch schon oft gehört! Aber meine Hand kann ich natürlich nicht dafür ins Feuer legen. Allerdings steht eigentlich auch nirgends, dass die Präsentation exakt 15 Minuten lang sein muss. In der Verordnung (§15, Abs. 2) stehen nur 30 Minuten für Präsentation und Fachgespräch. Noch einen kleinen Tipp: Wenn man Probleme mit den 15 Minuten hat, ist es tatsächlich sinnvoll (entgegen meiner tiefen inneren Überzeugung ), Seitenzahlen auf die Folien zu packen. Dann sieht der Ausschuss nämlich bei Minute 15, ob noch 20 oder nur noch 2 Folien kommen und lässt den Prüfling ggfs. eher überziehen, weil die Chance besteht, den Vortrag komplett abzuschließen.

Sorry, noch was vergessen: Die genannten Punkte sind zwar sicherlich eine Grundlage für eine gute Präsentation, aber was letztlich zählt ist immer noch der Inhalt! Schau dir mal die Bewertungsmatrizen der IHKen an. Da ist die "formelle Gestaltung" sicherlich ein Kriterium bei der Notenfindung, aber das liegt - wenn überhaupt - vielleicht bei 20% der Note. Das Wichtigste ist definitiv der fachliche Inhalt deines Vortrags. Falls du z.B. das Thema verfehlt hast, helfen dir schöne Seitenzahlen und toll animierte Folien auch nicht weiter.

Natürlich kann man eine 6 in der mündlichen Prüfung bzw. der Projektpräsentation erreichen. Aber meiner Erfahrung nach ist die schlechteste Note eher krassen Fällen vorbehalten, wie z.B. Thema verfehlt, Thema nicht anspruchsvoll genug, Zweifel an der Eigenleistung des Prüflings, Plagiat. Mir einer 6 bist du ja definitiv durchgefallen, weil sie nicht "ausgeglichen" werden kann. Diese Karte spielen die Prüfer normalerweise nicht leichtfertig aus. Deine Einschätzung bzgl. des Fachgesprächs ist natürlich subjektiv und wir werden dir nicht sagen können, wie du zu bewerten bist. 60% beantwortet heißt ja nicht 60% korrekt beantwortet. Und wenn du 40% gar nicht beantworten konntest, vermute ich, dass die restlichen 60% auch nicht in Ordnung waren. Informiere dich also bei deiner IHK bzw. dem Ausschuss, was zu dieser Note geführt hat, damit du den gleichen Fehler beim nächsten Mal nicht wieder machst.

Du solltest deine Präsentation nochmal üben und ggfs. Folien streichen. Ob du mit 16:30 Minuten durchkommst, kann dir niemand sagen. Es gibt Ausschüsse, die das tolerieren. Andere brechen hart bei 15 Minuten ab. Aber was wahrscheinlich immer passieren wird, ist ein Punktabzug, da du die vorgegebene Zeit nicht eingehalten hast und damit im Vergleich mit den anderen Prüflingen eine schlechtere Leistung erbracht hast. Achte aber genauso darauf, dass die Präsentation nicht zu kurz wird. Erfahrungsgemäß sprechen die Prüflinge vor dem Ausschuss aufgrund der Aufregung immer etwas schneller. Wenn du dann bei 13 Minuten landest, ist das auch suboptimal. Du solltest ziemlich genau auf 15 Minuten kommen! Also nimm dir eine Uhr mit in die Prüfung bzw. verwende den Präsentationsmodus deiner Präsentationssoftware, der zusätzlich noch eine "Stoppuhr" bietet.