stefan.macke

Das kann man nicht an einer Zahl festmachen. Du musst vor allem deine Inhalte vermitteln und dabei die dir zur Verfügung stehende Zeit bestmöglich nutzen. Ob 10 oder 50 Folien ist dabei irrelevant.

Hast du da konkrete Vorstellungen/Empfehlungen?

Hallo zusammen, ich vermute, dass viele Forenteilnehmer hier das "IT-Handbuch für Fachinformatiker" von Sascha Kersken kennen. Für mich ist es jedenfalls seit Jahren die beste ausbildungbegleitende Literatur. Mit jedem neuen Azubi gehe ich das komplette Buch durch und spreche über die ausbildungs-, praxis- und prüfungsrelevanten Inhalte. In wenigen Wochen erscheint nun die neue Auflage des Standardwerks mit neuen Themen wie Docker und HTML5/CSS3. Das habe ich zum Anlass genommen, mit dem Autor persönlich über das Buch zu sprechen. Über eine Stunde lang unterhalten wir uns über Saschas Weg zur IT, die Entstehung des IT-Handbuchs, seinen Schreibprozess, die Technik hinter einem 1.300 Seiten starken Buch und vieles mehr. Hört doch gerne einmal rein: http://anwendungsentwicklerpodcast.de/105 Über Feedback würden wir uns beide sehr freuen! Viele Grüße! Stefan

Es ist genau andersherum: diese Bilder sind gemeinfrei (="public domain"). Eine Namensnennung ist somit nicht erforderlich. Der Fairness halber (dem Fotografen gegenüber) würde ich dennoch einen Quellennachweis einbauen. Und potentielle Nachfragen der Prüfer vermeidest du damit auch.

So ist es. Vergleiche http://www.gesetze-im-internet.de/bundesrecht/itktausbv/gesamt.pdf

Das erzähl mal "Uncle Bob", der mit >60 immer noch jedes Jahr eine neue Programmiersprache lernt!

Und genau deswegen sollte man vielleicht keine "Brücke schlagen", sondern das schreiben, was die Prüfer - die das Ding bewerten - haben wollen. Ob später mal ein Kollege oder Kunde reinschaut und das toll findet, sollte dir in diesem Fall egal sein.

Sofern du hier von der Benutzer- oder Entwicklerdokumentation sprichst, bin ich voll dabei. Die Projektdokumentation ist allerdings ein Prüfungsartefakt, das nur für die IHK erstellt wird.

Kostenfrei ist es nicht, aber ich nutze EcoDMS. 70 Euro. Client/Server-Lösung. Automatische Beschlagwortung/Ablage nach Training. Kann auch Werte aus Dokumenten auslesen und in die Beschlagwortung packen. Für das Geld eine tolle Lösung!

Nein. Kunde fehlt. Kunde/Fracht 1:n. Pilot/Flugzeug m:n.

Meine Frage dazu wäre jetzt, was das mit Datenschutz zu tun hat. Du redest von betriebsinternen Daten, die ggfs. aus Gründen der Datensicherheit nicht nach außen gegeben werden dürfen. Aber mit personenbezogenen Daten im Sinne des Datenschutzes hat das nichts zu tun. Daher wird es deinen Prüfern auch herzlich egal sein, ob du die Daten zensierst, solange man nachvollziehen kann, worüber du redest. Und für das Fachgespräch bereite dann am besten nochmal den Unterschied zwischen Datenschutz, Datensicherheit und Datensicherung vor!

Wie willst du eine Wirtschaftlichkeitsbetrachtung durchführen, ohne die Projektkosten zu kennen? Das geht nur so: zuerst die Kosten planen, danach die Einsparungen gegenüberstellen. Eine andere Frage ist doch, wie du das in deiner Projektdokumentation anordnest. Da ist vielleicht eine andere Reihenfolge passender, weil es sich dann einfach besser liest. Die Dokumentation muss ja nicht unbedingt den realen/chronologischen Ablauf des Projekts abbilden. Es handelt sich hierbei um ein Prüfungsartefakt. Und zuletzt: Wenn dir die Reihenfolge in der Vorlage nicht zusagt, dann ändere sie doch einfach! Die Vorlage ist genau das: eine Vorlage. Du musst sie schon noch auf die konkreten Anforderungen deines Projekts anpassen!

Ich habe mir vor einigen Monaten einen Fujitsu ScanSnap ix500 gekauft. 400 Euro, aber das Ding ballert super schnell alles durch, was es so gibt. Kassenbons, doppelseitige Dokumente. Und alles sofort inkl. OCR. Den kann ich definitv empfehlen, wenn du einen Berg Dokumente abzuarbeiten hast.

Aus eigener Erfahrung kann ich sagen, dass immer versucht wird, viele Punkte für die Prüflinge rauszuholen. Wenn du nicht völligen Unsinn schreibst, wirst du auch Punkte bekommen. Nicht umsonst steht fast unter jeder Musterlösung "andere Antworten möglich".

Es gibt eigentlich keine "Pflichtinhalte" in den Projektdokus. Wenn für dein Projekt eine Kundendoku nicht sinnvoll ist, dann erstellst du keine. Irgendeine Form der Dolumentation wird aber erwartet (siehe Bewertungsmatrizen der IHKen). Also "Wir dokumentieren in unserem Betrieb nicht" ist keine Ausrede Sicherlich steigt die Chance auf eine gute Note, wenn gewisse Inhalte in der Projektdoku enthalten sind. Eine Kunden-/Benutzerdoku zähle ich durchaus dazu. Aber sie muss halt auch zum Projekt passen und darf keinen Selbstzweck darstellen. In deinem konkreten Fall würde ich mal hinterfragen, warum euer Kunde keine Doku von euch bekommt! Ist das Produkt selbsterklärend? War er bei der Entwicklung beteiligt? Das sind Gründe, die gegen eine Kundendoku sprechen, die ich dann an deren Stelle in deiner Projektdoku erwarten würde. Bei einer Entwicklung für einen Kunden erwarte ich entweder eine Doku oder eine vernünftige Begründung, warum diese nicht erstellt wurde.

Das kann ich nur absolut unterstreichen! Die Vorlagen und Beispieldokus sind nicht dazu gedacht, sie 1-zu-1 abzuschreiben oder ohne Nachdenken ihre Struktur zu übernehmen! Sie dienen als Hilfe und Anregung, aber der Aufbau und natürlich die Inhalte sind immer an das eigene Projekt anzupassen! Kapitel, die nicht sinnvoll sind, gehören gestrichen und Inhalte, die fehlen, müssen natürlich ergänzt werden. Ansonsten kann die Doku wie jede andere Quelle auch zitiert werden. Allerdings bitte mit Beschreibung, was zitiert wurde, und nicht einfach die Doku ins Quellenverzeichnis packen. Das kann dann ja alles und nichts bedeuten.

Passwörter sollten gesalzen und gehasht werden (in der Reihenfolge). Das Salz steht einfach als individueller Wert für jeden Benutzer im Klartext in einer separaten Spalte in der Benutzertabelle. Gehasht wird dann z.B. Salz + Passwort, gerne auch mit Trennzeichen dazwischen. Das Salz dient nicht der Sicherheit des Passwortes und kann daher im Klartext vorliegen. Vielmehr soll das Salz verhindern, dass Benutzer mit gleichen Passwörtern einfach identifiziert werden können. Da das individuelle Salz vor dem Hashen zum eigentlichen Passwort hinzugefügt wird, sind auch bei identischen Passwörtern die zu hashenden Strings unterschiedlich. In der Datenbank ist somit nicht mehr ersichtlich, wenn mehrere Benutzer die gleichen Passwörter verwenden (was bedeuten würde, dass mehrere Accounts kompromittiert werden können, wenn ein einziges Passwort geknackt wird). Der Wert des Salzes kann beim Anlegen eines Benutzers zufällig generiert werden. Er muss dann aber natürlich in der DB gespeichert (und danach nicht mehr verändert) werden, da er jedes Mal beim Prüfen der Benutzerdaten verwendet werden muss, um das übergebene Passwort zu salzen und danach zu hashen.

Ich würde alles, was du beschreibst, in einem gemeinsamen Unterkapitel zur Nutzwertanalyse erwarten. Ob du es nun vor oder nach der eigentlichen Nutzwertanalyse (also der Tabelle) schreibst, ist mehr oder weniger egal. Zusätzliche Kapitel würde ich dafür aber nicht extra einführen. Du wirst ja kaum mehrere Seiten damit füllen. Und allein die Tatsache, dass du an all diese Informationen denkst, unterscheidet dich schon von anderen Prüflingen ;-) Allerdings würde ich mir noch einmal Gedanken über die Benennung, also die Überschrift des Kapitels machen. Einfach nur "Nutzwertanalyse" finde ich wenig aussagekräftig. Wichtiger wäre doch, warum du die Nutzwertanalyse überhaupt erstellst. Sie hat ja keinen Selbstzweck. Ein besserer Titel wäre also so etwas wie "Anbieterauswahl" oder "Vergleich der Softwarelösungen".

Uhhh. Da überträgt aber jemand seine Erfahrungen aus dem Alltag gefährlich auf die Allgemeinheit. UML ist weder veraltet noch praxisfern. Im Gegenteil: Es ist der Industriestandard für den modellbasierten Softwareentwurf und die Dokumentation. Natürlich braucht man UML nicht, wenn man einfach drauflos programmiert und eh nichts dokumentiert Und Softwareentwicklern zu empfehlen, SQL nicht zu lernen, weil es ORMs gibt, halte ich schlichtweg für völlig falsch. ORMs sind kein Allheilmittel und haben ihre ganz eigenen Probleme (z.B. N+1). Entwickler, die SQL nicht beherrschen, sind meiner Meinung nach keine richtigen Entwickler. Das wäre so als wüsste der KFZ-Mechaniker nicht, wie eine Bremse funktioniert, weil es ja ABS gibt. Von den Pseudocodeaufgaben mag man halten, was man will. Aber es ist immer wieder erstaunlich, wie viele "Anwendungsentwickler" keine for-Schleife auf die Reihe bekommen. Da helfen dann auch keine "modernen" Ansätze mehr. Ich halte es jedenfalls für ansolut richtig, gerade diese absoluten Grundlagen der Programmierung abzufragen. Denn sie werden von allen Programmiersprachen angeboten und müssen allen Prüflingen bekannt sein. Nur weil ich z.B. heute eher Map/Filter/Reduce verwende (vorausgesetzt meine Sprache erlaubt es mir), heißt das ja nicht, dass ich Schleifen oder if-Abfragen nicht mehr verstehen muss. Das sehe ich analog zu ORM und SQL. Also kurz zusammengefasst: Mit pauschalen Aussagen wie "X braucht doch niemand mehr" wäre ich sehr vorsichtig. Was ich letztens noch in einem Artikel gelesen habe: die Entwicklerin der Software für die Voyager-Sonde (die seit den 1960ern immer noch weiterentwickelt wird) wäre froh über "moderne" Konzepte wie switch/case

Ich würde den kostbaren Platz in deiner Doku besser für die Dinge nutzen, die deine fachlichen Fähigkeiten unter Beweis stellen. Klickorgien mit 15 Seiten Screenshots sind keine ausreichende Projektarbeit. Du musst dein methodisches Vorgehen zeigen, deine Entscheidungen begründen, die Wirtschaftlichkeit berechnen, das System mit üblichen Diagrammen dokumentieren, Anbieter vergleichen, Tests durchführen usw. Es gibt so viele spannende Inhalte, die du in der Doku unterbringen kannst. Bitte spar dir die "Installationsanleitungen" bzw. reduziere sie auf ein Minimum. Ich vergleiche das mal mit einem Anwendungsentwickler: Wenn der mir auf 3 Seiten detailliert eine for-Schleife beschreibt, weiß ich, dass das Projekt kaum Substanz hat. Für die Projektdoku sind z.B. eher die architekturellen Entscheidungen interessant, also das große Ganze. Die trivialen Details kleiner Algorithmen haben in einer Doku meiner Meinung nach nichts verloren. Um es wieder in deinen Kontext zu setzen: Anstatt detailliert zu zeigen, wie du einen Installationswhizard durchklickst, solltest du lieber schreiben, warum du diesen überhaupt nutzt. Wieso wurde dieses Tool überhaupt ausgewählt? Welche Vor- und Nachteile hat es? Welche Alternativen wurden aus welchen Gründen ausgeschlossen? Was soll ich als Prüfer bewerten, wenn du mir eine "Klickorgie" zeigst? Dass du gut auf "Ok" klicken kannst? Das kann bereits ein Azubi im 1. Lehrjahr ohne Nachzudenken. Nach 3 Jahren Ausbildung solltest du darüber hinaus sein und stattdessen Entscheidungen auf höherem Niveau treffen können. Zu deinem konkreten Beispiel: Welche Rollen gibt es überhaupt in deiner Software? Warum wird ein "Operator" angelegt? Welche Rechte muss/darf er haben? Welches grundlegende Authentifizierungs- und Autorisierungskonzept wird verwendet und warum? Wird das Tool an einen Verzeichnisdienst angebunden und warum (nicht)?

Als kleine Ergänzung, warum das so ist: http://stackoverflow.com/questions/590747/using-regular-expressions-to-parse-html-why-not

Um die NWA aber sinnvoll nutzen zu können, sollte diese Subjektivität möglichst eliminiert werden. Daher ist die Angabe der Werteskala und die Begründung für die vergebene Punktzahl so wichtig. Bei Skalen von 1 bis 100 kann fast nur eine rein subjektive Bewertung erfolgen. Wie beschrieben: Wie soll der Unterschied zwischen 75 und 76 Punkten glaubhaft begründet werden? Kleinere Skalen, die für jeden Wert genau festlegen, wann er zu vergeben ist, sind objektiv(er) einsetzbar. Beispiel: Kriterium "Dokumentation des Produkts" -> 0 Punkte: Keine Doku vorhanden, 1 Punkt: Englische Doku vorhanden, 2 Punkte: Deutsche Doku vorhanden, 3 Punkte: Deutsche Doku mit lauffähigen Beispielanwendungen vorhanden. Diese Bewertung kann von jedem Mitarbeiter vorgenommen werden, ohne großen Interpretationsspielraum. Natürlich ist es ein bestimmter Aufwand, für jedes Kriterium so eine Skala vorzubereiten. Aber genau das würde ich von einem Prüfling im Rahmen seiner Projektarbeit erwarten. Ansonsten kann man sich die NWA auch sparen und sich wahllos irgendwelche "Nutzwertkoeffizienten" ausdenken.

Eine Gewichtung brauchst du, wenn es halt etwas zu gewichten gibt. In deinem ersten Beispiel sind alle Kriterien gleich wichtig. Für den unwahrscheinlichen Fall, dass das wirklich so ist, brauchst du keine Gewichtung. Was du unabhängig von der Gewichtung aber unbedingt noch einbauen solltest, ist eine Erklärung der zu vergebenden Punkte. Die Skala ist schon sehr krass: 0-50 Punkte. Was heißt das? Warum bekommt man z.B. 47 und nicht 48 Punkte? Wer bewertet das? Wie wird das überhaupt bewertet? Und durch die unterschiedlichen Skalen der Kriterien hast du eigentlich eine versteckte Gewichtung. Denn bei Kriterium 4 sind ja mehr als doppelt so viele Punkte möglich wie bei 1. Alles etwas seltsam. Mein allgemeines Feedback: Werteumfang deutlich reduzieren (z.B. 0-3); erklären, was die Werte bedeuten (z.B. 0 nicht vorhanden, 1 schlecht, 2 mittelmäßig, 3 hervorragend); Gewichtung einführen (es gibt immer Kriterien, die wichtiger sind als andere); erläutern, wer die Bewertung durchführt und wie sie auf die Werte kommen.

Bei Arbeiten im Format DIN A4 wäre ein größerer Zeilenabstand, z.B. 1,5 Zeilen, angebracht, damit das Auge beim Lesen leichter die nächste Zeile findet. Ich kann mir aber nicht vorstellen, dass deine IHK keine Vorgaben dazu macht. Eine Schriftgröße ohne Zeilenabstand vorzugeben ist doch sinnlos, wenn man einheitliche und vergleichbare Dokumentationen haben möchte. Frag doch bitte bei deiner IHK nach, bevor du einfach frei entscheidest und vielleicht etwas übersehen hast. Nur das wird dir die Sicherheit geben, alles richtig zu machen.

Verwende die Stundensätze deines Unternehmens, die dir eure Buchhaltung nennen kann. Selbst berechnen ist nicht sinnvoll, da du sicherlich irgendetwas vergisst oder falsch machst. Und das führt nur zu Fragen im Fachgespräch