stefan.macke

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.

vor 56 Minuten schrieb Tician:

- Wie speichert man am besten Passwörter in einer Datenbank? Mit einem Hash ist klar, aber dann ein salt der im Quellcode steht? Einen automatisch generierten? (aber würde sich dann der Hash nicht mit jedem Programm-start ändern?)

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

Am 04/17/2017 um 01:29 schrieb Sheldor:

Die UML-Diagramme sind seit den 90ern obsolete und werden in der Praxis nicht verwendet. Die beiden Pseudocode Handlungsschritte verstoßen gegen so ziemlich alle Programmier-Best-Practices die es gibt (z. B. SOLID, Lines of Code, DRY) und heutzutage gibt es ORM Frameworks für die Datenbankinteraktion, was den obligatorischen 5. Handlungsschritt (SQL) überflüssig macht.

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

vor einer Stunde schrieb Whiz-zarD:

 

Viele Wege führen nach Rom aber ich halte die Lösung mit regulären Ausdrücken eine der schlechtesten.

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

vor einer Stunde schrieb Musashi94:

Dies impliziert schon das die Punktevergabe der Nutzweranalyse großteils eben subjektiv durch den Menschen geschieht.

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

Einfach nur um von Einzelschicksalen wieder auf den allgemeinen Arbeitsmarkt zurückzukommen: der Fachinformatiker gehört seit Neustem zu den 10 beliebtesten Ausbildungsberufen bei männlichen Azubis. Von einer Abnahme der Nachfrage - bei Betrieben und Bewerbern - kann also wahrlich nicht die Rede sein.

https://www.bibb.de/de/pressemitteilung_60513.php

Wir setzen in der Ausbildung auch eine wenig verbreitete Sprache ein: Natural. Sie ist ähnlich zu Cobol. Damit verdient unser Unternehmen sein Geld, also müssen auch die Azubis die Sprache lernen. Aber als Ausbilder achte ich darauf, dass sie zusätzlich mindestens eine "moderne" Sprache wie Java oder C# lernen. Sowohl die Konzepte der Objektorientierung als auch andere Plattformen wie das Web sollten meiner Meinung nach in der Ausbildung heutzutage vermittelt werden. Ich habe also nichts gegen eine Ausbildung auf RPG, wenn zusätzlich auch moderne Inhalte berücksichtigt werden. Man kann als Unternehmen evtl. nicht nur das ausbilden, was für das Tagesgeschäft nötig ist, sondern muss auch darüber hinaus Inhalte anbieten. Darauf würde ich bei der Wahl des Ausbildungsplatzes achten.

Für die Komposition habe ich irgendwo einmal eine noch krassere Definition in Code-Form gesehen: innere Klassen. Die können definitiv nicht ohne die umschließende Klasse existieren. Beispiel:
 

class Mensch {
    class Herz { ... }
    private Herz herz;
    ...
}

Aber in der Praxis (und der Prüfung) würde ich von dieser simplen Definition ausgehen:

• Assoziation: die Klassen "kennen" sich einfach nur (rufen Methoden auf oder nutzen Attribute voneinander)
• Aggregation: eine Klasse ist Teil der anderen (Teil/Ganzes-Beziehung), kann aber für sich allein existieren (Reifen -> Auto)
• Komposition: eine Klasse ist Teil der anderen und kann nicht ohne diese existieren (Raum -> Haus)

Kann mich nur anschließen. Das geht gar nicht! Und die geben sogar zu, dass die gleiche Aufgabe fertigen Entwicklern gestellt wurde. Tut mir leid, aber da schreit alles: "Wir brauchen billige Arbeitskräfte, die wir nicht ausbilden müssen!".

Überleg mal: Zwei Wochen Programmierung!? Das ist der Umfang des Abschlussprojekts für Anwendungsentwickler!

vor 1 Stunde schrieb Rienne:

Die Nutzwertanalyse ist eine Form des Angebotsvergleiches. Du kannst natürlich auch hingehen und einfach sagen: Das günstigste Angebot wird genommen. Punkt! Ohne Rücksicht auf nicht messbare Faktoren wie beispielsweise Zuverlässigkeit des Lieferanten, Wartungsangebot, Garantieansprüche, etc. zu nehmen.

Ich würde ergänzen, dass die Nutzwertanalyse ein Werkzeug ist, um nicht-monetäre Faktoren bewerten zu können. Die von dir genannten Punkte (Zuverlässigkeit, Wartung usw.) sind nämlich alle "weich" und lassen sich nicht mit einem Euro-Bertrag versehen.

vor 19 Stunden schrieb Whiz-zarD:

Und der Rest?

...wurde bislang noch nicht abgefragt. Was aber auch ok ist. Wer braucht denn schon wirklich ein Timing-Diagramm?

vor 19 Stunden schrieb Whiz-zarD:

UML sollte aber auch für die Modellierung nützlich sein und da ist die Schwierigkeit von UML. UML ist für die Modellierung ungeeignet.

Wie beschrieben setze ich die UML sehrwohl für die Modellierung ein. Allerdings nicht im Detail - also Klassen mit Attributen und allem Schnickschnack - sondern insb. für die Architekturplanung. Das detaillierte Klassendesign oder Abläufe, die man mit einem Sequenzdiagramm modellieren könnte, ergeben sich bei Anwendung von TDD erst bei der Entwicklung.

Nichtsdestotrotz gibt es viele gute Werkzeuge (z.B. den Enterprise Architect), die Roundtrip-Engineering beherrschen und Code zu Modell und Modell zu Code wandeln können. Dadurch wird die Aktualisierung der Modelle ein Kinderspiel.

vor 19 Stunden schrieb Whiz-zarD:

Man erkennt nicht, ob der Ersteller der Diagramme das Problem komplett verstanden hat.

Genau wie bei Code

vor 19 Stunden schrieb Whiz-zarD:

Komplexe Abläufe sind in den Diagrammen nur sehr schwer zu verstehen.

Das kommt auf den Grad der Abstraktion an. UML hat nicht den Anspruch, die Details perfekt abzubilden. Das kann Code tatsächlich besser. Dafür kannst du in deinen Diagrammen die Sicht und den Grad der Detaillierung frei wählen und komplexe Abläufe auf ihren Kern herunterbrechen. Von daher sehe ich die UML gerade bei komplexen Abläufen als äußerst hilfreich an.

vor 19 Stunden schrieb Whiz-zarD:

Das nächste ist, dass sich daraus kein Code generieren lässt. So kann der spätere Code vom Diagramm abweichen.

Siehe oben. Das geht sehrwohl. Allerdings sollte nicht der Anspruch sein, "fertigen" Code zu generieren, sondern z.B. Klassenrümpfe oder Pakete. Das spart dann tatsächlich sogar Zeit, wenn man mit dem Modell beginnt.

vor 19 Stunden schrieb Whiz-zarD:

Für sowas sind DSL-Ansätze sinnvoller. Darum verwendet man UML eigentlich nur noch aus Dokumentationsgründen und nicht für die Entwicklung und in diesem Punkt hat UML einfach versagt.

Da wir auch mehrere selbst entwickelte DSLs im Einsatz haben, kann ich nur zustimmen: für die Codegenerierung optimal! Aber für die Dokumentation und grobe Modellierung würde ich trotzdem ein grafisches Werkzeug wie die UML vorziehen.

In der Ist-Analyse wird der aktuelle Zustand der durch das umzusetzende Projekt zu lösenden Problemstellung dargestellt. Du erläuterst die bisherige Situation mit dem konkreten Problem, das es zu lösen gilt. Beispiel: Urlaubsanträge werden noch auf Papier eingereicht, was jetzt durch ein elektronisches System abgelöst werden soll. Dabei gehst du z.B. auf die Schwachstellen des aktuellen Zustands ein (z.B. langsamer Prozess, Medienbrüche, menschliche Fehler, hohe Kosten) und begründest, warum eine andere Lösung sinnvoll ist.

Häufig geht es aber auch um eine Ist-Aufnahme und Visualisierung bestehender Prozesse, die bislang vielleicht gar nicht komplett verstanden wurden. Dabei können dann z.B. EPKs oder Aktivitätsdiagramme helfen.

Letztlich soll am Ende der Ist-Analyse der aktuelle Prozess oder Zustand verständlich dokumentiert sein, sodass klar wird, warum eine neue Lösung geschaffen werden muss.

vor einer Stunde schrieb Whiz-zarD:

UML ist aus meiner Sicht einfach nicht wirklich wichtig. DIe Praxis zeigt deutlich, dass UML versagt hat. Kaum keiner verwendet diese Diagramme und selbst die IHK kennt wohl die Unterschiede einzelner Diagramme nicht.

Da muss ich widersprechen. Für die IHK-Prüfung sind mind. 5 UML-Diagrammtypen (Use-Cases, Aktivität, Zustand, Klassen, Sequenz) absolut relevant, da sie in den letzten Jahren fast immer abgefragt wurden.

Und auch in der Praxis sehe ich nicht, dass die UML "versagt" hat. Wenn sie nicht zur Modellierung verwendet wird (worüber man in Zeiten von TDD streiten kann), so ist sie doch der allgemein akzeptierte Standard, wenn es um die Dokumentation geht. Wir verwenden z.B. regelmäßig Klassen-, Verteilungs- und Komponentendiagramme, um die Architektur von Anwendungen zu dokumentieren. Und eine gewisse Modellierungsphase vor der Entwicklung empfinde ich auch als äußerst hilfreich. Gerade um Azubis vor der Programmierung die geplanten Schichten (oder wie auch immer die Architektur aussieht) näherzubringen.

Ich berichte mal aus der Prüferpraxis: Ich wäre froh, wenn Prüflinge wenigstens die Wikipedia zitieren würden! Die meisten Dokus, die ich lesen darf, enthalten nämlich einfach gar keine Quellenangaben.

An die Projektdoku werden nicht so hohe Ansprüche gestellt wie an wissenschaftliche Arbeiten. Aber wenn fremde Inhalte wiedergegeben werden, ist eine Quellenangabe notwendig, damit die eigene von fremder Arbeit abgegrenzt werden kann. Allein für die Benotung ist das schon wichtig. Ich persönlich würde bei Wikipedia als Quelle ein Auge zudrücken. Immerhin besser als gar nichts!

Allgemein kann ich mich der Aussage aber anschließen, dass Wikipedia nicht als Quelle angegeben werden sollte. Mit einer kurzen Google-Suche finden sich auch immer "vernünftige" Quellen (einfach mal auf das zweite Suchergebnis klicken und nicht direkt aufs erste). Oder man nimmt halt die Wikipedia als Einstieg und folgt den dort angegebenen Primärquellen. Dass das natürlich Arbeit macht, ist klar. Aber immerhin reden wir hier von einer Abschlussprüfung eines Ausbildungsberufs und nicht von einem Referat in der 7. Klasse.