daZza

Wenn ich es richtig verstehe programmierst du selbst ja nicht, sondern machst im Grunde das Projektmanagement - als Schnittstelle zwischen Entwicklung und externen Zahlungsdienstleistern - und bist für die Kostenplanung zuständig. Das ist eigentlich geanu das, was ein Informatikkaufmann so macht. Effektiv sind alle Aufgaben kaufmännisch (da keine eigene Programmierung).

Abgesehen davon bekommt man aber auch eindeutige FIAE Projekte als Informatikkaufmann durch. Man fügt einfach "unter Berücksichtigung einer Kosten-Nutzen-Analyse" am Ende des Titels an und deckt damit den kaufmännischen Teil ab ;-)

So habe ich zumindest ein im Endeffekt sehr gutes Projekt durchbekommen, was zu 80% aus Programmierung bestand.

Ich denke also, dass du keine Probleme haben solltest und würde es einfach mal probieren.
 

Das heißt aber nicht, dass keinen "Gewinn" in Form von Einsparungen gibt.

Ich hatte in etwa die gleiche Ausgangssituation (statt Open Source war es Software, die durch uns selbst entwickelt wird) und mein Wirtschaftsteil in der Doku hatte 2/10 Seiten (bin Informatikkaufmann, daher nur 10 Seiten. Abgesehen davon war es aber ein reines Programmierprojekt).

Jedes Projekt muss ja einen Nutzen haben, sonst würde man es nicht durchführen... Ein Nutzen lässt sich immer quantifizieren.
Ich bin wie folgt vorgegagnen, ggf. ist ein ein erster Anhaltspunkt für dich:
 
Aufstellung der Gesamtkostenrechnung Einholen von internen (!) Kostensätzen über die Finance Abteilung. Jeweils für die verschiedenen Hierarchiestufen, welche am Projekt beteiligt sind (neben deinen 35 Stunden investieren andere Leute ja in der Regel auch ein wenig Zeit für Abstimmungsgespräche, technische Bereitstellung, Testing, ...) Hier sind bei uns bereits alle "Nebenkosten" und auch Lizenzgebühren, etc. enthalten. Da ich nur auf meinem Firmenlaptop und virtuellen Umgebungen gearbeitet habe - die bereits eingepreist sind - musste ich sonst nichts berücksichtigen. Wird extra Hardware angeschafft oder werden Spezialprogramme (Lizenzen) benötigt, dann sind diese natürlich noch hinzuzurechnen. Aufstellen einer entsprechenden Tabelle mit den Gesamtkosten des Projekts als Resultat Nutzenermittlung Bei mir resultierte der Nutzen aus der Zeiteinsparung Quantifizierung des Nutzens Treffen von grundlegenden Annahmen, bei mir war das z.B., dass mein entwickeltes Tool hauptsächlich von einer bestimmten Hierarchiestufe benutzt werden wird (auf Grund der damit durchführbaren Aufgaben) und solche Geschichten Feststellung der aktuellen Durchführungsdauer des Tasks, den du mit deinem Tool optimierst (waren bei mir z.B. knapp 7 Stunden) Aus den beiden Informationen kann man dann schon einmal die jetztigen Kosten des Tasks berechnen (7 * "Kostensatz (pro Stunde) der Hierarchiestufe X") Jetzt habe ich - basierend auf der geplanten Implementierung - mehrere Cases aufgestellt. Diese haben sich in dem durch meine Implementierung erreichten Automatisierungsgrad unterschieden. Basiert war das Ganze auf Dingen, die noch unklar waren und im Rahmen des Projekts erst noch ermittelt werden mussten (z.B. welche Schnittstellen gibt es eigentlich und was können diese? Kann ich dort mit meiner Implementierung direkt aufsetzen oder müsste eine eigene Schnittstelle entwickelt werden? Wie performant sind diese Schnittstellen? Welche Formate nehmen sie an? ... etc. pp. ...). Ergebnis war dann ein Worst-Case mit 30%iger Automatisierung ein Real-Case mit 60% und ein Best-Case mit 85% Darauf basierend habe ich dann für jeden Case die Einsparspotentiale ausgerechnet (Hatte ja vorher bereits die jetztigen Kosten für den Task ausgerechnet. Durch die Automatisierung kann man diese dann entsprechend dem Automatisierungsgrad verringern) Anschließend dann die Amortisation für jeden Case ausgerechnet, d.h. ab wann sich der Nutzen im Vergleich zu den Gesamtkosten des Projekts rentiert Fazit (für den wirtschaftlichen Teil --> Entscheidung zur Projektdurchführung ja/nein) Habe auf Basis eines anstehenden Projektes (also eines anderen) die monetäre und zeitliche Einsparung auf Basis des Worst-Case durchgerechnet Da kamen anständige Summen bei raus --> Projekt wird durchgeführt, da es sich schon in einem einzelnen Projekt amortisiert und anschließend bei jeder weiteren Durchführung des Tasks auf anderen Projekten o.Ä. einen "Gewinn" in Höhe der ausgerechneten Einsparung erzielt wird.  
Das ist nur ein Weg von vielen, aber einen Nutzen kannst du immer ausrechnen, auch für interne Projekte!

Das sollte im Brief deiner IHK stehen.
Sofern es keine lokalen Unterschiede gibt, haben FIAE 70 Stunden Zeit, FISI sowie Informatikkaufleute 35 Stunden.

Die Vorgabe stellt nach meiner Erfahrung einen strikten Wert dar, den es unter allen Umständen einzuhalten gilt. Damit sollte auch im Antrag immer vollständig geplant werden und falls im Projektverlauf Abweichungen auftreten, müssen diese nachvollziehbar begründet werden. Eine Überziehung endet im Zweifel mit 0 Punkten, das Nichtausnutzen der vollen 35 Stunden mit Punktabzügen. Ich würde es also immer so hinbiegen, dass man den vollen Rahmen ausnutzt.

Ein paar erste Anmerkungen:
Erster Satz der Projektbeschreibung: Im zweiten Teil des Satzes ([...] sowie als Lieferant [...]) würde ich in der Aufzählung alles in einen einheitlichen Numerus bringen. Am Ende des Satzes fehlt zudem ein Wort wie z.B. "tätig" o.Ä. Datenbankverwaltungssystem würde ich in Datenbankmanagementsystem ändern, da es der Fachbegriff ist (DBMS) "Dadurch verliert man schnell den Überblick über die eingesetzten Geräte und hat keine aktuellen Listen z.B. für die Elektronikversicherung"

Mit solchen Aussagen wäre ich sehr vorsichtig. Ggf. verlangt die Versicherung in den Konditionen ein lückenloses Inventar o.Ä. und auch für die Buchhaltung könnte das recht schnell böse enden. Aus den Büchern sollte nämlich zu jeder Zeit ein Überblick über alle eingesetzten Geräte möglich sein, da ansonsten diverse Gesetze zur Anlagenbuchaltung nicht eingehalten werden. Sofern das Gerät einen Wert > 400€ hat (bzw. > 150€ bei Monitoren o.Ä.) muss es dort als eigener Posten mit eindeutiger ID (i.d.R. der Barcodenummer) auftauchen und lückenlos nachzuvollziehen sein. "Des Weiteren müssen die Geräte Brandschutzgeprüft werden, was eine eindeutige Identifikation wesentlich erleichtert."

Das musste ich ein paar Mal lesen, bevor ich verstanden habe was du meinst. Ich würde den Satz umstellen, etwa in die Richtung "Desweiteren erleichtert eine eindeutige Identifikation die Brandschutzprüfung der Geräte". Der Originalsatz impliziert für mich, dass eine Brandschutzprüfung die eindeutige Identifikation eines Geräts wesentlich erleichtert (was keinen Sinn macht). Auch hier der Hinweis: Eigentlich muss jedes Gerät bereits eindeutig identifizierbar sein, da es in den Büchern stehen muss. IIS ist kein "Intranet Information Server" 18 Stunden "Erstellen der Funktionen" ist zu grob. Feiner aufschlüsseln Präsentationsmittel: Ich würde zur Sicherheit noch ein Flipchart mit aufnehmen (ist aber Geschmackssache) Ansonsten hier und da einige Rechtschreibfehler o.Ä.. Einfach nochmal gründlich durchlesen und eine neutrale Person rüberschauen lassen Projekt an sich ist aber - aus meiner Sicht - in Ordnung  

Ich nehme an, dass du mit dieser Einstellung dann auch an das Projekt, die Doku und die Präsentation gegangen bist?
In dem Fall kann auch nichts anderes als eine 6 bei rumkommen

Es spiegelt sich ja auch in deinen anderen Geschichten wider. Da wären z.B. "Den (von der IHK geforderten) Beamer zähle ich nicht, da es sich um eine Kleinigkeit handelte, die eh schon im Raum war" oder "Die (gerechtfertigte) Note 6 zähle ich nicht, da es sich nur um kleine Ausrutscher in den Antworten handelte".

Diese Einstellung wird dich im Leben nicht weiterbringen...
 

Vorlagen dazu sollte es eigentlich wie Sand am Meer geben, da dieses Thema bei (fast) jeder Bachelor-/Masterarbeit aufkommt, die in Zusammenarbeit mit einem Unternehmen geschrieben wird.

Die für mich gängigen Ausdrücke sind in diesem Rahmen Sperrvermerk bzw. Geheimhaltungserklärung. Der Sperrvermerk steht dabei in der Arbeit selbst und die Geheimhaltungserklärungen werden zusätzlich mit den beteiligten Prüfern / Lehrstuhlmitarbeitern / ... abgeschlossen - das ist zumindest das mir bekannte Vorgehen.

Inwieweit man dieses Vorgehen aber für ein IHK Projekt übernehmen kann weiß ich nicht, da hängt auf jeden Fall immer ein wenig organisatorischer Aufwand hinter... Der sicherste Weg dürfte wohl ein direktes Abklären des Sachverhalts mit der betroffenen IHK sein.

Ich könnte mir vorstellen, dass man auf die gesonderten Geheimhaltungserklärungen verzichten kann, da die an der Prüfung beteiligten Personen m.W. bereits von Seite der IHK der Geheimhaltung unterliegen (IANAL). Das müsste sich dann aber im Zweifel ein Anwalt genauer anschauen, um mögliche Schlupflöcher o.Ä. aufzudecken.
Zur Absicherung kannst du dann noch einen Sperrvermerk reinpacken und ggf. dort deine kurze Erläuterung unterbringen. Aber auch das sollte vorher mit der IHK abgeklärt werden, nicht das es nachher von Seiten der IHK heißt "geheime" Arbeiten nehme man nicht an --> 0 Punkte 

 

Es gibt verschiedene Arten des Zitats.
Du kannst Passagen wortwörtlich übernehmen und entsprechend mit "" markieren. Damit hast du ein direktes Zitat.

Du kannst aber auch den Inhalt eines Abschnitts sinngemäß in deinen eigenen Worten wiedergeben oder zum Vergleich heranziehen. Das ist dann ein indirektes Zitat, dort setzt du nichts in "" und gibst in der Quellenangabe dann ein "vgl." oder "nach" Autor/Werk/Seite an. 


Zur Ausgangsfrage: Ich würde von Zitaten aus anderen Projektarbeiten ebenfalls abraten, v.a. im Zusammenhang mit Einleitung und Wirtschaftlichkeitsanalyse. Da gibt es eigentlich nichts zu zitieren... Zitate solltest du bei der Klärung von speziellen Fachfragen einsetzen und nicht um deine Einleitung zu schreiben ;-) 

Generell kannst du dich natürlich an anderen Arbeiten orientieren, das wird wohl jeder machen. Solange du nicht passagenweise wortwörtlich abschreibst, sollte das auch kein Problem darstellen. Ich würde es dann aber trotzdem nicht als Quelle angeben (dort hat m.E. nur Fachliteratur etwas zu suchen), sondern einfach zur persönlichen Inspiration nutzen. Ließ dir die andere Projektarbeit einfach durch, schlaf eine Nacht drüber und schreib dann deine eigene Einleitung / Wirtschaftlichkeitsanalyse. 

Ich würde bei der Projektdokumentation immer genau - d.h. keine Sekunde mehr oder weniger - das maximale Zeitlimit ausnutzen (i.d.R. also 35 bzw. 70 Stunden). Das Gleiche gilt für den Seitenumfang.   

Alles unter dem Zeitlimit wirkt "schluderig". Es gibt in jedem Projekt noch Dinge, die man verbessern kann, "zu viel" Zeit gibt es bei Projekten nicht.
Alles über dem Zeitlimit ist schlecht geplant, was entsprechende Abzüge nach sich zieht. Im Zweifel fällst du sogar direkt durch, da das maximale Limit überschritten wurde (hier kann Stefan Macke, als Prüfer, sicher etwas genaueres zu sagen. Ich kann mir aber durchaus vorstellen, dass eine nicht den Vorgaben entsprechende Arbeit entsprechend deklariert und mit 0 Punkten gewertet wird).
Optimal ist also die vollständige Ausnutzung des Rahmens.

Natürlich wissen alle Beteiligten, dass die 35 bzw. 70 Stunden in der Realität - zumindest bei fachlich anspruchsvollen Projekten - nie (ansatzweise) eingehalten werden. Über das "Warum werden die Zeiträume nicht angepasst?" kann man wohl nur spekulieren. Wahrscheinlich dient es als letzter "Test" vor der Entlassung in die freie Wirtschaft, denn dort sind die meisten Projekte ebenfalls nur auf dem Papier "in time". Oder es basiert auf irgendwelchen arbeitsrechtlichen Vorschriften (Jugendarbeitsschutz oder weiß der Teufel) oder sonstwas.

Am Ende möchte man nur die Zahl 35 bzw. 70 sehen und dann realistische Werte für die einzelnen Teilbereiche haben. Am besten du suchst dir also einfach einen Faktor und wendest den auf deine echten Arbeitsstunden an, dann passen auf jeden Fall die Verhältnisse.  

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

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

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

"IT-Dienstleister" ist ja nun ein sehr umfassender Begriff. 
Das kann von der kleinen Klitsche (Systemhaus o.Ä.) bis zu hoch spezialisierten Softwareschmieden reichen.

Ich persönlich würde versuchen mir ein relativ bekanntes Unternehmen zu suchen (muss nicht allgemein bekannt sein, sondern in seiner Branche. Auf die musst du dann aber auch Bock haben), welches eine hohe dreistellige oder untere/mittlere vierstellige Mitarbeiteranzahl hat.

Diese Unternehmen haben meist noch offene, flexible und flache Strukturen, während trotzdem genügend Ansprechpartner und Erfahrung verfügbar sind. Zudem gibt es dort die Möglichkeit relativ einfach zu "netzwerken" und die Chance spannende Projekte zu bearbeiten.

Großunternehmen mit 10k+ Mitarbeitern oder Konzerne würde ich meiden (--> meine Meinung, muss jeder selbst entscheiden, wo seine Interessen liegen), außer du hast die Chance über Vitamin B in DAX 30 zu kommen (sofern die ausbilden). Grund: Oft steile Hierarchien, es wird nach Seniorität statt Leistung befördert/bezahlt, festgefahrene Strukturen, oft nicht die  modernste IT (da Kosten viel zu hoch, wenn zehntausende MA mit neuen Geräten ausgestattet werden müssen), etc pp.

Kleine Klitschen würde ich auch meiden. Dort gibt es meist wenig Erfahrung und damit auch wenig Unterstützung. Du bist eher billige Arbeitskraft und bekommst entsprechend nur das beigebracht, was im Tagesgeschäft gemacht werden muss. Den Blick über den Tellerrand gibt es dort selten. Ausnahme sind StartUps, die bilden aber m.W. eher nicht aus.
 

Bei "einer anderen IHK" sollten schon alle Alarmglocken angehen. Jede IHK kocht ihr eigenes Süppchen, es gibt keine Standardisierung.
Zudem sollte man sich nie auf mündliche Aussagen verlassen (das scheint von vielen Menschen auch gerne vergessen/ausgeblendet zu werden...).

Bzgl. Vorbereitung:
Die Prüfungsvorbereitung ist ja auch Privatsache, genauso wie beim Abi, in der Fahrschule, im Studium, bei Zertifizierungen, ...

Überall wo es eine Prüfung abzulegen gilt, ist die Vorbereitung deine eigene Verantwortung. Etwaige Vorbereitungskurse/Unterricht/... kann - logischerweise - immer nur einen Teil der erwarteten Kenntnisse vermitteln/wiederholen. Den Rest muss man sich privat aneignen oder - im Spezialfall der Ausbildung - zusätzlich im betrieblichen Rahmen. 

Das es eine Projektarbeit und eine Präsentation gibt ist auch kein Geheimnis. Wenn man also wenig Erfahrung darin hat, dann sollte man aus Eigeninitiative vielleicht mal auf den Chef zugehen und sich einige interne Projektdokumentation zeigen lassen und nach einigen Präsentationsterminen als Vorbereitung auf die Prüfung fragen. Bei uns haben alle Azubis ihre Projektpräsentation mindestens drei Mal gehalten und Feedback eingeholt. Die Dokus wurden intern an verschiedene Leute (mit jeweils einer anderen Perspektive --> Fachkollege, "BWLer", Manager, ...) zum Review verteilt, sodass die Ansprüche möglichst aller Zielgruppen abgedeckt waren (du weißt ja nicht, wer im PA sitzt).

Und die formalen Anforderungen an wissenschaftliche Arbeiten (Zitierregeln, etc.) findest du zu genüge im Internet, falls von der IHK nicht darauf hingewiesen wird oder die IHK dazu keine Standards hat (scheint aber nur bei der IHK München der Fall zu sein). Dafür muss man kein Experte sein oder schon mal eine Projektdokumentation geschrieben haben. Das sich der Aufbau bspw. an den einzelnen Projektphasen orientiert ist eigentlich auch einleuchtend. Mehr als gesunden Menschenverstand braucht man für die Gliederung nicht... Wenn man aber stattdessen die Gliederung von fremden Projekten übernimmt, kann ja nichts Gutes bei rauskommen und beim bloßen "Inhalt umschreiben" ist man eigentlich schon im Bereich Plagiat...

Ihr müsst doch selbst ein Projekt durchgeführt haben, in Eigenregie. Da muss doch Inhalt en masse vorhanden sein. Warum schreibt man den Inhalt von anderen Projekten um, statt den eigenen Inhalt wiederzugeben? Das verstehe ich nicht... Und dann auch noch die Erwartung zu haben, dass eine bloße Anpassung an einer Vorlage in einer guten Note resultiert. Wie soll das gehen? Wenn du eine fremde Doku einfach geringfügig umschreiben kannst, damit sie deinem Projekt genügt, dann kann der Projektinhalt ja eigentlich nur "generischer Bullshit" gewesen sein?! Und der führt in der Regel nicht zu einer guten Note, da er komplett austauschbar ist. 

Normalerweise wird dir das auch in den Wochen vor der Prüfung jeden Tag mehrfach eingetrichtert und in den Prüfung wurde des ebenfalls mehrfach betont (zudem steht es fett gedruckt auf dem Deckblatt). Uns wurde immer die Info gegeben, dass die IHK generell den letzten Handlungsschritt streicht, sofern auf dem Deckblatt nichts gegenteiliges angegeben wird. Zur Sicherheit sollte man auch noch die Seiten des gestrichenen HS großzügig durchstreichen 

Dem Beitrag von larsson kann ich eigentlich nur zustimmen.
Vergiss alles was du in der Berufsschule gelernt hast bzw. lernst. Das ist alles (meist auch noch veralteter) Humbug, den du in der Wirtschaft nicht gebrauchen kannst.

Programmieren lernst du nur durchs Selbermachen. Es gibt im Internet - je nach Sprache mehr oder weniger - sehr gute Einsteigertutorials, die auf einem "Projekt" aufbauen, sprich bei denen du am Ende etwas in der Hand hast (nen Taschenrechner, kleines Spiel, Kalender, etc. pp). Das ist dann schon ein guter Ausgangspunkt für die nächste Stufe und oft gibt es dann auch entsprechende Tutorials, die darauf aufbauen. Alternativ kannst du selbst Anpassungen vornehmen und den Kalender um eine Erinnerungsfunktion oder sonstwas erweitern. 

Vielleicht bist du auch ein Serienfreak und bräuchtest eigentlich mal etwas, was deine Serien verwaltet. Könnte man auch mit einer Excelliste machen, aber solche Sachen kannst du natürlich auch mit einer schönen GUI versehen und weitere Funktionen einbauen. IMDB hat bestimmt eine API, die man anzapfen kann, der VLC-Player ggf. auch (Liste der zuletzt geöffneten Dateien). Dann könntest du automatisiert alle Informationen zu deinen Lieblingsserien abrufen und würdest - sofern du immer über den VLC-Player schaust - auch immer wissen wo du aktuell stehst (Season / Episode).
Oder du brauchst öfters ein Wörterbuch, hast aber nicht immer Internetzugang. Zieh dir den Wörterbuchbestand als CSV/XML/... (geht m.W .bei dict.cc) Datei und bau ein entsprechendes Programm oder eine kleine Webseite (z.B. mit Livesuche über AJAX o.Ä.) drum herum. Entwickle einen Algorithmus, der häufig gesuchte Wörter automatisch in eine Favoritenliste aufnimmt, optimiere die Performance über Datenbank Indexes, oder oder oder. 

Ich würde einfach versuchen mir einige solcher "Komfortprogramme" als Übung zu schreiben, auch (oder vor allem) privat. Wenn dir etwas auffällt, was man zu einem Mini-Programmierprojekt machen könnte, dann schreib dir das auf und setz dich am Wochenende ein paar Stündchen hin. Wenn du auf der Arbeit merkst, dass du einen bestimmten Arbeitsschritt mehr als 1 mal machst, dann bau dafür eine Automatisierung (sofern dein Zeitplan das erlaubt). Es muss ja nicht immer eine Hochsprache sein, auch kleine VBA-Skripte helfen in die "Logik" des Programmierens hineinzukommen und sind vor allem für ihren geringen Aufwand oft sehr nützlich / zeitsparend. 


Bezüglich Programmierparadigmen und anderen Prinzipen (wie oben genannt z.B. KISS, YAGNI, DRY) würde ich mich aber immer am Arbeitgeber orientieren. Das sind im Zweifel einfach Glaubensfragen und zudem ist das auch abhängig von der generellen Vorgehensweise (agil oder nicht) und dem Anwendungsgebiet des Programmes. KISS ist sicherlich immer sinnvoll, aber bei YAGNI und DRY mache ich zum Beispiel grundsätzlich das Gegenteil.

Ich programmiere generell alles generisch, sodass ich wechselnde oder neu hinzukommende Kundenanforderungen ohne großen Zeitaufwand einbauen kann oder im Zweifel sogar nur eine Datenbanktabelle mit den neuen Werten befüllen muss und der Rest läuft automatisch (das ist also so ziemlich das 100%ige Gegenteil des YAGNI Prinzips). Am Anfang habe ich das nicht so gemacht, aber nachdem ich mehrfach Dinge implementiert hatte, bei denen sich die Anforderungen auf Kundenseite dann auf einmal doch wieder geändert haben (das kommt nämlich häufiger vor, als man erwarten würde...) und ich dadurch ernneut eine große Rüst- und Implementierungsaufwand hatte, habe ich mir das generische Programmieren angewöhnt. Es braucht in der ursprünglichen Entwicklung dann zwar ein bisschen länger, diese Zeit zahlt sich aber bei späteren CRs (Change Request) vielfach aus.

 
Deim DRY-Prinzip ist es das gleiche. Je nach Anwedungsfall macht das durchaus Sinn, aber wenn du bspw. im Bereich Data Warehousing unterwegs bist, kannst du das Prinzip direkt wieder über Bord werfen. Dort setzt du oft bewusst redundante Daten ein, um Abfragen über viele Tabellen zu verhindern. Bei großen Datenmengen kosten diese nämlich unglaublich viel Zeit. Um aber weiterhin einen sauberen Stand zu haben, setzt du dann auf das SPOT Prinzip. Es gibt dann eine oder mehrere Punkte, die immer die "Wahrheit" für einzelne (oder ggf. alle) Daten beinhalten. Änderungen führst du also auch nur an einem Punkt durch. Die redundanten Daten werden dann durch entsprechende ETL-Strecken aktualisiert, sodass ein konsistenter Stand gewährleistet bleibt.  

Deshalb: Grade bei Paradigmen, Prinzipien und ähnlichem solltest du dich immer nach dem konkreten Anwendungsfall richten und nicht blind eines durchziehen, weil 90% der Internetcommunity drauf stehen und es voll geil finden. 
 
 

Dem Beitrag von larsson kann ich eigentlich nur zustimmen.
Vergiss alles was du in der Berufsschule gelernt hast bzw. lernst. Das ist alles (meist auch noch veralteter) Humbug, den du in der Wirtschaft nicht gebrauchen kannst.

Programmieren lernst du nur durchs Selbermachen. Es gibt im Internet - je nach Sprache mehr oder weniger - sehr gute Einsteigertutorials, die auf einem "Projekt" aufbauen, sprich bei denen du am Ende etwas in der Hand hast (nen Taschenrechner, kleines Spiel, Kalender, etc. pp). Das ist dann schon ein guter Ausgangspunkt für die nächste Stufe und oft gibt es dann auch entsprechende Tutorials, die darauf aufbauen. Alternativ kannst du selbst Anpassungen vornehmen und den Kalender um eine Erinnerungsfunktion oder sonstwas erweitern. 

Vielleicht bist du auch ein Serienfreak und bräuchtest eigentlich mal etwas, was deine Serien verwaltet. Könnte man auch mit einer Excelliste machen, aber solche Sachen kannst du natürlich auch mit einer schönen GUI versehen und weitere Funktionen einbauen. IMDB hat bestimmt eine API, die man anzapfen kann, der VLC-Player ggf. auch (Liste der zuletzt geöffneten Dateien). Dann könntest du automatisiert alle Informationen zu deinen Lieblingsserien abrufen und würdest - sofern du immer über den VLC-Player schaust - auch immer wissen wo du aktuell stehst (Season / Episode).
Oder du brauchst öfters ein Wörterbuch, hast aber nicht immer Internetzugang. Zieh dir den Wörterbuchbestand als CSV/XML/... (geht m.W .bei dict.cc) Datei und bau ein entsprechendes Programm oder eine kleine Webseite (z.B. mit Livesuche über AJAX o.Ä.) drum herum. Entwickle einen Algorithmus, der häufig gesuchte Wörter automatisch in eine Favoritenliste aufnimmt, optimiere die Performance über Datenbank Indexes, oder oder oder. 

Ich würde einfach versuchen mir einige solcher "Komfortprogramme" als Übung zu schreiben, auch (oder vor allem) privat. Wenn dir etwas auffällt, was man zu einem Mini-Programmierprojekt machen könnte, dann schreib dir das auf und setz dich am Wochenende ein paar Stündchen hin. Wenn du auf der Arbeit merkst, dass du einen bestimmten Arbeitsschritt mehr als 1 mal machst, dann bau dafür eine Automatisierung (sofern dein Zeitplan das erlaubt). Es muss ja nicht immer eine Hochsprache sein, auch kleine VBA-Skripte helfen in die "Logik" des Programmierens hineinzukommen und sind vor allem für ihren geringen Aufwand oft sehr nützlich / zeitsparend. 


Bezüglich Programmierparadigmen und anderen Prinzipen (wie oben genannt z.B. KISS, YAGNI, DRY) würde ich mich aber immer am Arbeitgeber orientieren. Das sind im Zweifel einfach Glaubensfragen und zudem ist das auch abhängig von der generellen Vorgehensweise (agil oder nicht) und dem Anwendungsgebiet des Programmes. KISS ist sicherlich immer sinnvoll, aber bei YAGNI und DRY mache ich zum Beispiel grundsätzlich das Gegenteil.

Ich programmiere generell alles generisch, sodass ich wechselnde oder neu hinzukommende Kundenanforderungen ohne großen Zeitaufwand einbauen kann oder im Zweifel sogar nur eine Datenbanktabelle mit den neuen Werten befüllen muss und der Rest läuft automatisch (das ist also so ziemlich das 100%ige Gegenteil des YAGNI Prinzips). Am Anfang habe ich das nicht so gemacht, aber nachdem ich mehrfach Dinge implementiert hatte, bei denen sich die Anforderungen auf Kundenseite dann auf einmal doch wieder geändert haben (das kommt nämlich häufiger vor, als man erwarten würde...) und ich dadurch ernneut eine große Rüst- und Implementierungsaufwand hatte, habe ich mir das generische Programmieren angewöhnt. Es braucht in der ursprünglichen Entwicklung dann zwar ein bisschen länger, diese Zeit zahlt sich aber bei späteren CRs (Change Request) vielfach aus.

 
Deim DRY-Prinzip ist es das gleiche. Je nach Anwedungsfall macht das durchaus Sinn, aber wenn du bspw. im Bereich Data Warehousing unterwegs bist, kannst du das Prinzip direkt wieder über Bord werfen. Dort setzt du oft bewusst redundante Daten ein, um Abfragen über viele Tabellen zu verhindern. Bei großen Datenmengen kosten diese nämlich unglaublich viel Zeit. Um aber weiterhin einen sauberen Stand zu haben, setzt du dann auf das SPOT Prinzip. Es gibt dann eine oder mehrere Punkte, die immer die "Wahrheit" für einzelne (oder ggf. alle) Daten beinhalten. Änderungen führst du also auch nur an einem Punkt durch. Die redundanten Daten werden dann durch entsprechende ETL-Strecken aktualisiert, sodass ein konsistenter Stand gewährleistet bleibt.  

Deshalb: Grade bei Paradigmen, Prinzipien und ähnlichem solltest du dich immer nach dem konkreten Anwendungsfall richten und nicht blind eines durchziehen, weil 90% der Internetcommunity drauf stehen und es voll geil finden. 
 
 

Dem Beitrag von larsson kann ich eigentlich nur zustimmen.
Vergiss alles was du in der Berufsschule gelernt hast bzw. lernst. Das ist alles (meist auch noch veralteter) Humbug, den du in der Wirtschaft nicht gebrauchen kannst.

Programmieren lernst du nur durchs Selbermachen. Es gibt im Internet - je nach Sprache mehr oder weniger - sehr gute Einsteigertutorials, die auf einem "Projekt" aufbauen, sprich bei denen du am Ende etwas in der Hand hast (nen Taschenrechner, kleines Spiel, Kalender, etc. pp). Das ist dann schon ein guter Ausgangspunkt für die nächste Stufe und oft gibt es dann auch entsprechende Tutorials, die darauf aufbauen. Alternativ kannst du selbst Anpassungen vornehmen und den Kalender um eine Erinnerungsfunktion oder sonstwas erweitern. 

Vielleicht bist du auch ein Serienfreak und bräuchtest eigentlich mal etwas, was deine Serien verwaltet. Könnte man auch mit einer Excelliste machen, aber solche Sachen kannst du natürlich auch mit einer schönen GUI versehen und weitere Funktionen einbauen. IMDB hat bestimmt eine API, die man anzapfen kann, der VLC-Player ggf. auch (Liste der zuletzt geöffneten Dateien). Dann könntest du automatisiert alle Informationen zu deinen Lieblingsserien abrufen und würdest - sofern du immer über den VLC-Player schaust - auch immer wissen wo du aktuell stehst (Season / Episode).
Oder du brauchst öfters ein Wörterbuch, hast aber nicht immer Internetzugang. Zieh dir den Wörterbuchbestand als CSV/XML/... (geht m.W .bei dict.cc) Datei und bau ein entsprechendes Programm oder eine kleine Webseite (z.B. mit Livesuche über AJAX o.Ä.) drum herum. Entwickle einen Algorithmus, der häufig gesuchte Wörter automatisch in eine Favoritenliste aufnimmt, optimiere die Performance über Datenbank Indexes, oder oder oder. 

Ich würde einfach versuchen mir einige solcher "Komfortprogramme" als Übung zu schreiben, auch (oder vor allem) privat. Wenn dir etwas auffällt, was man zu einem Mini-Programmierprojekt machen könnte, dann schreib dir das auf und setz dich am Wochenende ein paar Stündchen hin. Wenn du auf der Arbeit merkst, dass du einen bestimmten Arbeitsschritt mehr als 1 mal machst, dann bau dafür eine Automatisierung (sofern dein Zeitplan das erlaubt). Es muss ja nicht immer eine Hochsprache sein, auch kleine VBA-Skripte helfen in die "Logik" des Programmierens hineinzukommen und sind vor allem für ihren geringen Aufwand oft sehr nützlich / zeitsparend. 


Bezüglich Programmierparadigmen und anderen Prinzipen (wie oben genannt z.B. KISS, YAGNI, DRY) würde ich mich aber immer am Arbeitgeber orientieren. Das sind im Zweifel einfach Glaubensfragen und zudem ist das auch abhängig von der generellen Vorgehensweise (agil oder nicht) und dem Anwendungsgebiet des Programmes. KISS ist sicherlich immer sinnvoll, aber bei YAGNI und DRY mache ich zum Beispiel grundsätzlich das Gegenteil.

Ich programmiere generell alles generisch, sodass ich wechselnde oder neu hinzukommende Kundenanforderungen ohne großen Zeitaufwand einbauen kann oder im Zweifel sogar nur eine Datenbanktabelle mit den neuen Werten befüllen muss und der Rest läuft automatisch (das ist also so ziemlich das 100%ige Gegenteil des YAGNI Prinzips). Am Anfang habe ich das nicht so gemacht, aber nachdem ich mehrfach Dinge implementiert hatte, bei denen sich die Anforderungen auf Kundenseite dann auf einmal doch wieder geändert haben (das kommt nämlich häufiger vor, als man erwarten würde...) und ich dadurch ernneut eine große Rüst- und Implementierungsaufwand hatte, habe ich mir das generische Programmieren angewöhnt. Es braucht in der ursprünglichen Entwicklung dann zwar ein bisschen länger, diese Zeit zahlt sich aber bei späteren CRs (Change Request) vielfach aus.

 
Deim DRY-Prinzip ist es das gleiche. Je nach Anwedungsfall macht das durchaus Sinn, aber wenn du bspw. im Bereich Data Warehousing unterwegs bist, kannst du das Prinzip direkt wieder über Bord werfen. Dort setzt du oft bewusst redundante Daten ein, um Abfragen über viele Tabellen zu verhindern. Bei großen Datenmengen kosten diese nämlich unglaublich viel Zeit. Um aber weiterhin einen sauberen Stand zu haben, setzt du dann auf das SPOT Prinzip. Es gibt dann eine oder mehrere Punkte, die immer die "Wahrheit" für einzelne (oder ggf. alle) Daten beinhalten. Änderungen führst du also auch nur an einem Punkt durch. Die redundanten Daten werden dann durch entsprechende ETL-Strecken aktualisiert, sodass ein konsistenter Stand gewährleistet bleibt.  

Deshalb: Grade bei Paradigmen, Prinzipien und ähnlichem solltest du dich immer nach dem konkreten Anwendungsfall richten und nicht blind eines durchziehen, weil 90% der Internetcommunity drauf stehen und es voll geil finden. 
 
 

Dem Beitrag von larsson kann ich eigentlich nur zustimmen.
Vergiss alles was du in der Berufsschule gelernt hast bzw. lernst. Das ist alles (meist auch noch veralteter) Humbug, den du in der Wirtschaft nicht gebrauchen kannst.

Programmieren lernst du nur durchs Selbermachen. Es gibt im Internet - je nach Sprache mehr oder weniger - sehr gute Einsteigertutorials, die auf einem "Projekt" aufbauen, sprich bei denen du am Ende etwas in der Hand hast (nen Taschenrechner, kleines Spiel, Kalender, etc. pp). Das ist dann schon ein guter Ausgangspunkt für die nächste Stufe und oft gibt es dann auch entsprechende Tutorials, die darauf aufbauen. Alternativ kannst du selbst Anpassungen vornehmen und den Kalender um eine Erinnerungsfunktion oder sonstwas erweitern. 

Vielleicht bist du auch ein Serienfreak und bräuchtest eigentlich mal etwas, was deine Serien verwaltet. Könnte man auch mit einer Excelliste machen, aber solche Sachen kannst du natürlich auch mit einer schönen GUI versehen und weitere Funktionen einbauen. IMDB hat bestimmt eine API, die man anzapfen kann, der VLC-Player ggf. auch (Liste der zuletzt geöffneten Dateien). Dann könntest du automatisiert alle Informationen zu deinen Lieblingsserien abrufen und würdest - sofern du immer über den VLC-Player schaust - auch immer wissen wo du aktuell stehst (Season / Episode).
Oder du brauchst öfters ein Wörterbuch, hast aber nicht immer Internetzugang. Zieh dir den Wörterbuchbestand als CSV/XML/... (geht m.W .bei dict.cc) Datei und bau ein entsprechendes Programm oder eine kleine Webseite (z.B. mit Livesuche über AJAX o.Ä.) drum herum. Entwickle einen Algorithmus, der häufig gesuchte Wörter automatisch in eine Favoritenliste aufnimmt, optimiere die Performance über Datenbank Indexes, oder oder oder. 

Ich würde einfach versuchen mir einige solcher "Komfortprogramme" als Übung zu schreiben, auch (oder vor allem) privat. Wenn dir etwas auffällt, was man zu einem Mini-Programmierprojekt machen könnte, dann schreib dir das auf und setz dich am Wochenende ein paar Stündchen hin. Wenn du auf der Arbeit merkst, dass du einen bestimmten Arbeitsschritt mehr als 1 mal machst, dann bau dafür eine Automatisierung (sofern dein Zeitplan das erlaubt). Es muss ja nicht immer eine Hochsprache sein, auch kleine VBA-Skripte helfen in die "Logik" des Programmierens hineinzukommen und sind vor allem für ihren geringen Aufwand oft sehr nützlich / zeitsparend. 


Bezüglich Programmierparadigmen und anderen Prinzipen (wie oben genannt z.B. KISS, YAGNI, DRY) würde ich mich aber immer am Arbeitgeber orientieren. Das sind im Zweifel einfach Glaubensfragen und zudem ist das auch abhängig von der generellen Vorgehensweise (agil oder nicht) und dem Anwendungsgebiet des Programmes. KISS ist sicherlich immer sinnvoll, aber bei YAGNI und DRY mache ich zum Beispiel grundsätzlich das Gegenteil.

Ich programmiere generell alles generisch, sodass ich wechselnde oder neu hinzukommende Kundenanforderungen ohne großen Zeitaufwand einbauen kann oder im Zweifel sogar nur eine Datenbanktabelle mit den neuen Werten befüllen muss und der Rest läuft automatisch (das ist also so ziemlich das 100%ige Gegenteil des YAGNI Prinzips). Am Anfang habe ich das nicht so gemacht, aber nachdem ich mehrfach Dinge implementiert hatte, bei denen sich die Anforderungen auf Kundenseite dann auf einmal doch wieder geändert haben (das kommt nämlich häufiger vor, als man erwarten würde...) und ich dadurch ernneut eine große Rüst- und Implementierungsaufwand hatte, habe ich mir das generische Programmieren angewöhnt. Es braucht in der ursprünglichen Entwicklung dann zwar ein bisschen länger, diese Zeit zahlt sich aber bei späteren CRs (Change Request) vielfach aus.

 
Deim DRY-Prinzip ist es das gleiche. Je nach Anwedungsfall macht das durchaus Sinn, aber wenn du bspw. im Bereich Data Warehousing unterwegs bist, kannst du das Prinzip direkt wieder über Bord werfen. Dort setzt du oft bewusst redundante Daten ein, um Abfragen über viele Tabellen zu verhindern. Bei großen Datenmengen kosten diese nämlich unglaublich viel Zeit. Um aber weiterhin einen sauberen Stand zu haben, setzt du dann auf das SPOT Prinzip. Es gibt dann eine oder mehrere Punkte, die immer die "Wahrheit" für einzelne (oder ggf. alle) Daten beinhalten. Änderungen führst du also auch nur an einem Punkt durch. Die redundanten Daten werden dann durch entsprechende ETL-Strecken aktualisiert, sodass ein konsistenter Stand gewährleistet bleibt.  

Deshalb: Grade bei Paradigmen, Prinzipien und ähnlichem solltest du dich immer nach dem konkreten Anwendungsfall richten und nicht blind eines durchziehen, weil 90% der Internetcommunity drauf stehen und es voll geil finden.