stefan.macke

Es stimmt schon, dass man in der Praxis vielleicht am ehesten mit Datenbanken etwas anfangen kann. Allein, dass mit Access sogar eine Datenbank in der Office-Suite enthalten ist, sollte das schon deutlich machen
Das Schöne an SQL ist, dass man diesen Standard auf jede (relationale) Datenbank anwenden kann, sodass man nicht an eine spezielle Implementierung gebunden ist. Ich könnte mir durchaus vorstellen, dass du über die Datenbanken einen guten Einstieg in die IT hinbekommst. Und auch für dich persönlich bieten die Kenntnisse vielleicht Vorteile, weil du selbst deine eigenen Daten damit organisieren kannst.

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?

Das ist kein Problem. Zeigt doch eher deine Kompetenz. Allerdings musst du aufpassen, dass du nicht alle genannten Sprachen nur oberflächlich einsetzt. Du solltest natürlich alles verstehen und erklären können, was du nutzt.
 
Warum sollte das nicht erlaubt sein? Solange der tatsächliche Entwicklungsteil nicht zu kurz ist, geht das ohne Probleme. Ich empfehle bei FIAE einen Anteil der "reinen" Programmierung von 30-40 Stunden. Aber ich habe auch gute Projekte mit weniger/mehr Anteil gesehen. Es kommt immer drauf an, was du daraus machst.
 
Ist auch kein Problem, sondern sehr häufig der Fall bei Abschlussprojekten. Das heißt natürlich nicht, dass du dir eine Betrachtung der Wirtschaftlichkeit und der Amortisation sparen kannst. Auch interne Projekte werden nicht "zum Spaß" umgesetzt.

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.

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.

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 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 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/

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/

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/

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

Ich meinte das auch in keinster Weise despektierlich, aber es liegt halt auch irgendwo in der Natur der Sache, in einem so vielseitigen und sich ständig wandelnden Feld wie der IT nicht immer auf dem aktuellsten Stand sein zu können, und manche der Prüfer sind halt nun mal doch schon eine Weile bspw. aus dem aktiven Programmieren raus und eher mit der Planung, der Teamleitung und dem Ausbilden o.ä. beschäftigt. Berufsschullehrer sind sind nun mal auch eher Theoretiker, die mit den aktuellsten Technologien eher selten zu haben, aber die aktuellen Konzepte natürlich beherrschen. Wie gesagt, trifft mit Sicherheit nicht auf jeden zu, aber nur als Vorurteil abstempeln kann man das auch nicht. Ändert auch nix daran, dass ich höchsten Respekt vor den Prüfern habe, denn da gehört schon ein gewisser Enthusiasmus dazu
Kann ja auch etwas positives haben, wenn man beim Fachgespräch eine Zeitlang mit einem Prüfer bspw. über Delphi schwadronieren kann, der sich so in seine Jugend zurückversetzt fühlt

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

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.
 

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
 
 
 

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
 
 
 

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

Wir erwarten von Prüflingen ein professionelles Verhalten, das auch im Berufsalltag Anwendung finden kann. Frage dich doch mal, was du im Unternehmen machen würdest, wenn du einen Fehler entdeckst (egal ob von dir oder jemand anderem verursacht)? Schweigen? Ist das die richtige Vorgehensweise?
Fehler macht jeder. Fehler zu verschweigen führt nur zu noch mehr Problemen. Und nicht zu seinen eigenen Fehlern zu stehen, ist eine Eigenschaft, die ich mir bei keinem Kollegen wünschen würde.
Geh davon aus, dass die Prüfer Ahnung haben und den Fehler finden. Mit diesem Wissen solltest du selbst offensiv auf den Fehler hinweisen und gleich eine Lösung liefern. Dann wird dir der Fehler sicherlich weniger negativ angerechnet.

14 Stunden weiter runterbrechen Wo ist die Kundendokumentation? Welche Methodiken wendest du an (z.B. Flussdigramm, EPK)?

Autsch. Noch ein dicker Fehler im zweiten SQL: GROUP BY fehlt. Ohne das führt die Abfrage nicht zum richtigen Ergebnis.

Ich möchte Person XYZ nicht zunahe treten, aber das hört sich nach einem Fall von Selbstüberschätzung an. Der Azubi kann "total super" programmieren - teilweise besser als die fertigen Kollegen - und bekommt trotzdem für eine "total tolle" Projektarbeit eine 4. Das kann ich nicht ganz ernst nehmen.
Zunächst einmal bekommt niemand wegen eines "unzureichenden Berichtshefts" eine 4. Das Berichtsheft wird nicht bewertet, sondern das Projekt. Und wenn "1-2 Faktoren" fehlen, ist das auch kein Grund für drei Noten Abzug. "Jeder Prüfer" sagt, dass es "eigentlich" eine 1 wäre...
Ich würde ganz klar empfehlen, die theoretischen Inhalte vernünftig zu lernen und sich ggfs. ein Feedback von jemandem zu holen, der sich auskennt. Wenn sogar der Ausbilder nicht weiter weiß, ist das schon komisch. Wie sieht es denn mit den Lehrern aus? Was sagen die Berufsschulnoten? Hat er Klassenkameraden, die mit ihm lernen können? Oder Mitazubis? Welche Bücher hat er schon gelesen? Hat er sich mal nach professioneller Hilfe für Prüfungsangst erkundigt?
An der Prüfung geht kein Weg vorbei. Der "Self-Made-Programmierer" funktioniert vielleicht in den USA. Aber in Deutschland wird sicherlich in den meisten Betrieben Wert auf eine abgeschlossene Ausbildung gelegt.
Ich vermute, das (anscheinend selbst beigebrachte) Programmieren funktioniert "super", aber die Theorie wurde nie richtig gelernt. Wie gesagt, ich will niemandem zunahe treten, aber solche Geschichten habe ich leider schon oft genug gehört. Also das nächste halbe Jahr nutzen, um vernünftig zu lernen und dann die Prüfung wiederholen!

Natürlich kannst du auch 80 h an dem Projekt sitzen oder nur 15 h.... Entscheident ist, wie du daraus 35 h machst und es nachvollziehbar in der Dokumentation darlegst. Da kann man auch etwas tricksen, in dem man bei dem ein oder anderern Schritt etwas Zeit weg nimmt oder hier und da etwas Zeit ranhängst... Alles aber in einem Rahmen der Realisierbarkeit. Wenn es in einem Abschnitt um das Anschließen und einrichten eines Routers geht, kann der keine 10 h dauern. Oder wenn man bei eiiner Webserver-Bereitstellung inkl. Einbindung aller Clients nur 3 h dastehen hat.  Das wird von der PK dann als nicht in dem Rahmen durchführbar angesehen und schlechter bewertet.
Die 35 Stunden sind vorgegeben, damit dem Prüfling auch ein Rahmen gesetzt werden kann. Wenn es keine zeitliche Beschränkung geben würde, wäre eine gleichberechtigte Bewertung der einzelnen Prüflinge auch schwer realisierbar. Da kommt vielleicht einer mit einem 60h Mega-Projekt an, während der andere nur eins von 15 h hat. Damit jeder Prüfling die selben Voraussetzungen und Anforderugen hat, wurde der Zeitraum eben auf 35h +/-0 vorgeschrieben.
Hier ist wirklich gutes Zeitmanagement und Organisationstalent gefragt. In der Dokumentation solltest du auch ziemlich genau den Zeitplan haben, den du im Antrag schon ausgearbeitet hast.