stefan.macke

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

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!

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.

...wurde bislang noch nicht abgefragt. Was aber auch ok ist. Wer braucht denn schon wirklich ein Timing-Diagramm? 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. Genau wie bei Code 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. 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. 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.

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.

Das sehe ich ganz genauso! Meine Azubis fangen im zweiten Lehrjahr mit der regelmäßigen Bearbeitung von IHK-Prüfungen an. Und bereits im ersten Lehrjahr beginnen wir mit dem Durcharbeiten zentraler Literatur wie dem Handbuch für Fachinformatiker. Das hat sich bei uns absolut bewährt. Außerdem lernt man den ganzen Kram ja nicht nur für die Prüfung. Es sind auch sehr viele praxisrelevante Themenfelder zu erarbeiten, die man bei seiner täglichen Arbeit anwenden kann. Beispiel Programmierung: Da sollte man schon im ersten Lehrjahr ein Klassendiagramm zeichnen und Vererbung und Polymorphie erklären können. Das sind klassische Prüfungsthemen, die aber auch in der Praxis eine hohe Relevanz haben. Ich finde es immer schade, wenn Prüflinge die ganzen Inhalte nur für die Prüfung lernen. Man kann doch im Arbeitsalltag viele Sachen direkt anwenden und damit z.B. seinen täglichen Job besser machen.

Das zweite stimmt, das erste nicht. Das ist ein Fehler, den viele Prüflinge auch in der mündlichen Prüfung machen: "Den Stundensatz darf ich Ihnen nicht nennen. Der unterliegt dem Datenschutz." Das ist falsch. Es handelt sich beim Stundensatz nicht um ein personenbezogenes Datum, da er nicht einer konkreten Person zuzuordnen ist, sondern wenn überhaupt einer Personengruppe (z.B. Azubis, Entwickler). Außerdem lässt er keinen Rückschluss auf die Höhe des Gehalts zu, da ja noch Neben- und Gemeinkosten einkalkuliert sind und bei externen Sätzen sogar der Gewinn. Nur der zweite Teil wäre richtig: "Den soll ich nicht herausgeben, da mein Chef ihn geheimhalten möchte.". Zurück zum Thema: Prüflinge müssen in ihrer Doku nicht eine komplette Umlageberechnung mit BAB und was weiß ich abliefern. Die ist im Zweifel ohnehin unvollständig, weil dem Azubi gar nicht alle Informationen vorliegen. Es reicht definitiv die Angabe von Stundensätzen aus der Buchhaltung. Allerdings sollte man das gut begründen und aufschreiben, woher die Sätze kommen! Darüber hinaus empfehle ich jedem Prüfling wärmstens, sich für das Fachgespräch auf die Erläuterung der Ermittlung dieser Stundensätze vorzubereiten (also: fixe vs. variable Kosten, Einzel vs. Gemeinkosten, BAB, Lohnnebenkosten usw.). Denn das ist klassischer Berufsschulstoff, der gerne abgefragt wird. Man muss die Stundensätze also theoretisch berechnen können (was im Fachgespräch ggfs. gefragt wird), aber in der Doku reicht die Angabe von betrieblichen Sätzen, die der Prüfling nicht selbst ermittelt hat.

Du hast - mal wieder - völlig recht, was die Praxis angeht. Allerdings kann man das den Prüflingen definitiv nicht empfehlen! Die Wahrscheinlichkeit, einen Punktabzug zu bekommen bzw. sogar durchzufallen, weil die zeitlichen Vorgaben nicht eingehalten wurden, ist sehr hoch! Jeder weiß, dass die Projektarbeit geschönt ist. Dieser Fakt steht auch bei der anstehenden Neuordnung der IT-Berufe ganz oben auf der Mängelliste. Es wird überlegt, von diesem starren Projektrahmen wegzugehen. Bis es jedoch soweit ist, kann ich nur jedem Prüfling raten, die Zeit exakt einzuhalten!

Einfach, um noch einmal deutlich zu widersprechen https://www.informatik-aktuell.de/aktuelle-meldungen/2017/februar/bereits-jedes-dritte-unternehmen-entwickelt-eigene-software.html -> Ein Viertel aller deutschen Unternehmen (laut der Studie) beschäftigt eigene Softwareentwickler. Ein Drittel entwickelt sogar ganz eigene Software.

Das kommt auf die Prüfung an. Geht es um GA1 und GA2, die von Menschen korrigiert werden, wirst du Teilpunkte bekommen. Wenn es um die maschinell korrigierten Prüfungsteile (Zwischenprüfung, WiSo) geht, bin ich mir nicht sicher.

Ich würde behaupten, dass Copy und Paste von StackOverflow auch den Alltag "fertiger" Entwickler bestimmt Allerdings sollte man immer verstehen, was man da kopiert. Btw, unterstützt dich dein/e Ausbilder/in nicht bei der Einarbeitung?

Ok, das stimmt natürlich. Ich würde aber einfach mal behaupten (allein weil in allen Bewertungsmatrizen auf der ersten Google-Suchergebnisseite explizit eine Benutzerdokumentation gefordert wird), dass die meisten IHKen eine separate Benutzerdokumentation erwarten. Im Zweifel geht natürlich der Wunsch der eigenen IHK vor! Und es bietet sich natürlich auch nicht für jedes Projekt eine solche Doku an! Wenn es keine Benutzer gibt, kann man auch keine Doku für sie schreiben. Dann würde ich aber schauen, ob es andere Zielgruppen gibt (z.B. Admins, Entwickler), für die eine Dokumentation sinnvoll wäre.

Da muss ich leider entschieden widersprechen. Es kann sein, dass einige IHKen auf Kunden- und/oder Entwicklerdoku verzichten, aber meiner Erfahrung nach, wollen die meisten IHKen das explizit haben. Das steht sogar in den Bewertungsmatrizen für die Dokumentation (s.u.). Zumindest die Benutzerdokumentation ist demnach Pflichtprogramm als Teil jeder Projektdokumentation. Eine Entwicklerdokumentation (z.B. mit JavaDoc) würde ich im Sinne einer guten Bewertung aber auch noch zusätzlich erstellen. Vgl. (u.a.): http://www.ihk-niederrhein.de/downloads/ihk/Bewertungsmatrix_Doku_FIAN.pdf https://www.darmstadt.ihk.de/blob/daihk24/produktmarken/aus_und_weiterbildung_channel/pruefungen/downloads/downloads/2551166/bdb388bedbc086ef6af8038551c207d2/Bewertungsmatrix_FIAE-data.pdf http://www.dortmund.ihk24.de/blob/doihk24/bildung/downloads/305454/d4d06e5b78c03eaf279dbfdb8e000292/Handreichungen_IT_Berufe-data.pdf