phph

Lieber lilith2k3, nach deiner Analyse frage ich mich ob du schon einmal Software entwickelt hast, denn du scheinst ja einige grundsätzliche Dinge nicht zu verstehen. Ich hätte bei einigen Punkten auch etwas einzuwenden, aber ich lass das mal. Was ich nun nach all den Aussagen hier allerdings feststellen muss ist wohl, dass möglicherweise das was ich ans Ausbildung zu Fachinformatiker für Anwendungsentwicklung von meiner Firma angeboten bekam nicht dem entspricht was sich die IHK darunter vorstellt. Das soll nicht den Wert dessen mindern was ich dort gelernt und mitbekommen habe, denn ich bin ein sehr guter Softwareentwickler geworden der gleichzeitig auch tiefgreifendes Fachwissen über Geografische Sachverhalte, Kommunale Verwaltungsabläufe, Straßenbauplanung und vieles mehr erworben hat, jedoch scheint gewisses anderes an mir vorrüber gegangen zu sein. Zunächst war ich überhaupt überrascht wie so eine Projektdokumentation auszusehen hat. Ich bin durchaus in der Lage Kosten zu kalkulieren, eine Zeitplan aufzustellen usw. jedoch gehört soetwas so gar nicht zu meinem Arbeitsalltag. Viele Zahlen und Informationen sind von mir hier völlig aus der Luft gegriffen, ein Projekt in der Form zu dokumentieren würde in der Realität bei uns sofort die Frage aufwerfen: Für wen und wozu? Ein Vertriebler muss nicht wissen wie ich ein Projekt umgesetzt habe, ein Geschäftsführer ebenso wenig. Ein Entwickler muss nicht wissen wie teuer ein Projekt war und wie lange es gedauert hat. Hier sind Infos zusammengefasst die zusammen keiner benötigt, nicht in unserem Geschäftsmodell. Ich denke ich sehe mittlerweile ein, dass ich unter diesen Umständen nicht viel an meinem Ergebnis ändern kann. Es ist eigendlich sehr schade, dass das System hier so starr und unflexibel ist. Der Ausbildungsberuf verlangt eben ganz bestimmte Strukturen und entsprechend muss vorgegangen werden. Dass Betriebe sich von einander in ihrer Arbeitsweise enorm unterscheiden, wobei jedes Modell seine Kritikpunkte hat, und hierbei manche Auszubildenden natürlich wesentlich im Vorteil sind ist außer Frage. Jetzt würde das Argument kommen, dass der Ausbildungsberuf alles abdecken muss, was die Wirtschaft von einem solche Auszubildenden verlangen könnte und desshalb all diese Vorgänge mit beinhaltet, doch das tut er nicht. Es interessiert weder ob ich in der lage bin komplexe Softwareprojekte umzusetzen, noch ob ich in der Lage bin Fachwissen jeder Art in Form von Software abzubilden. Es interessiert keinen ob ich in der Lage bin Kunden bei ihren Probleme zu betreuen oder Schulungen vorzubereiten und Anwendergerecht durchzuführen. All das sind aber genauso Dinge die die Wirtschaft von FIAEs verlangt. Und aus persönlicher Erfahrung durch Kontakt mit anderen Berufsschülern ist es der seltenste Fall, dass der Auszubildende das tut was er in der Ausbildung lernen muss. Wenn wir mal ganz ehrlich sind brauch man nur die schriftliche Prüfung anzusehen um festzustellen, dass das alles weit an der Realität vorbeizieht. Lächerlich einfache Fragen, aber z.B. Dinge die die Schulen und Universitäten nie verlassen haben, Sachen die inhaltlich so weit auseinander klaffen wie das Handwerk von Bäcker und Raumausstatter, museumsreifes Urgestein, und dann gibts noch einen Teil von Fragen die scheinbar überprüfen sollen ob man überhaupt lebensfähig ist, nach dem Motto "Wenn ers nicht schafft beim Bäcker ein Roggenbrot zu kaufen darf er auch kein Anwendungsentwickler werden".

Ich habe doch in der Doku geschrieben, dass die Änderungen aktuell durch manuelle Eingabe von SQL auf dem MSSQL Server vorgenommen werden, ob ich die jetzt in die Konsole eingebe oder über das SQL Management Studio ist doch uninteressant die Vorgehensweise ist die Selbe. Die Anforderungen stehen im Fachkonzept aus dem Anhang, ich kann das gerne nochmal hochladen und ich gehe im Grunde ja schon durch das Usecase Diagramm auf die Anforderungen recht detailliert ein. Zum Thema warum C# etc. schreibe ich ja, im allgemeinen Teil der Realisierungsphase, dass ich vorhandene Logik aus dem Gesamtprojekt der Firma verwende, daraus kann doch jeder nicht allzu dumme Mensch schließen, dass ich an eine Sprache gebunden bin. Klar gibt es Alternativen, aber warum soll ich all das nennen was ich nicht mache? Ich erkläre doch warum ich das gewählt habe was ich gewählt habe. Echte Alternativen, wenn man es so nennen will gab es im Grunde sowieso nicht weil es eben so gewünscht ist, dass dinge mit diesen Mitteln bei uns umgesetzt werden. Aber es macht überhaupt keinen Sinn sich seitenweise darüber auszulassen "Ich habe nicht MVC verwendet weil es nicht zu WPF passt. Ich habe nicht Winforms benutzt weil es veraltet ist. Ich habe nicht wie ein Idiot ohne Struktur drauf los programmiert weil man dann am Ende keine Erweiterungen mehr einbringen kann ohne die Hälfte nochmal neu zu machen. Ich habe nicht Java oder C++ oder Delphi oder PHP benutzt weil es nicht mit dem kompatibel ist was bereits vorhanden ist." Es ist doch klar, dass es in der Softwareentwicklung für alles ein unendliches Spektrum an Möglichkeiten gibt ein Problem zu lösen, aber in eine verwobenen Kontext wo bereits ganz viel drum herum existiert und wo zahlreiche Menschen am Selben Projekt arbeiten macht in der Regel nur ein Weg den meisten Sinn. Diese Information kann doch jeder aus dem Kontext heraus erkennen. Die Aufgabe war so klar definiert und vorstrukturiert. Ich denke letztendlich, dass es einfach nicht hierfür geeignet war. Es gab im Grunde keine Entscheidungsfindung, es war von Anfang an zu 100% klar was da passieren soll, für mich und für alle beteiligten. Wie soll ein Bäcker eine Projektdokumentation zum Backen eines 1 Kilo Roggenbrots schreiben? "Ich hätte auch Weizenmehl beifügen können, aber dann wäre es ein Mischbrot geworden"?

Klar, es fängt an mit Punkt 2 hier werden nur Fakten genannt, denn der Ist-Zustand ist nunmal nicht zu begründen, da er schon vorhanden ist. Beim Soll-Zustand schreibe was das Projekt am Ende leisten soll (Das sagt ja das Wort Soll-Zustand im Grunde aus), Detaillierte Gründe und Beschreibungen zum Soll-Zustand sind im beiliegenden Fachkonzept genannt, das Fachkonzept umfasst nochmal 10 Seiten, die Projektdoku ist ja leider vom Umfang viel zu begrenzt um hier ins Detail gehen zu können. Bei Punkt 3.5. wird es ja im grunde interesant, weil es da an die Planung für die Umsetzung geht, da habe ich das wichtigste aus dem Fachkonzept nochmal rausgezogen. Ich schreibe hier, dass es sehr wichtig ist ein Usecase Diagramm zu erstellen, damit man den focus nicht verliert wozu man das Projekt überhaupt macht usw usw. (Entscheidung: Usecase als Leitfaden für die Entwicklung, Grund: Focus auf den Anwender) Hier schreibe ich auch, dass es wichtig ist Massenhafte Bearbeitung zu ermöglichen weil es sonst ohne das Tool schneller gehen würde (Wichtige Projektentscheidung). Bei 3.6. beschreibe ich dann, dass es wichtig ist verschiedene Ebenen von einander zu trennen und ich desshalb MVVM benutze (Auch eine Entscheidung). MVVM muss ich hier unbedingt erklären weil es nicht jeder kennt und man überhaupt nicht verstehen würde wovon ich spreche. 3.7. erläutere ich dann, dass ich ein Aktivitätsdiagramm angefertigt habe weil ich an ganz bestimmten Punkten des Projekts zu bestimmten andren Punkte zurück springen können möchte, d.h. auch hier begründe ich warum ich diese Form der Ablaufplanung verwende und keine andere. 4.1. Begründet dann ganz allgemeine Dinge wie die Art der codierung (Was sehr wichtig ist). Beispielsweise, dass wir keine Kommentare verwenden und stattdessen sehr aussagekräftige Namen die auch gerne aus zahlreichen Worten bestehen können. (Projektentscheidung und Begründung) Außerdem schreibe ich, dass ich mich an konventionen halte damit auch andere meinen Code verstehen usw usw. Danach folgt die Implementierung, ich erkläre warum ich in dieser Reihenfolge vorgehen, z.B., dass die Entityklassen die Basis darstellen ohne die ich keine andere Ebene entwickeln kann weil jede Ebene diese Klassen verwenden. Das meiste hier richtet sich ja nach dem MVVM Pattern, das detailliert vorgibt wie man so eine Programmbasis entwirft. Viel mehr ist es ja nicht mein Programm kann am Ende des Projekts fast nichts, es ist nur ein rohes Konstrukt, dass jetzt noch über Monate hinweg erweitert wird. Hier nimmt einem das Pattern die Entscheidungsfreiheit, die Entscheidung war das Pattern zu benutzen und in dem Moment kann ich nicht mehr beeinflussen wie ich das Programm aufziehe denn es ist ja im Pattern vorgegeben. Desshalb erkläre ich bei den Punkten nur Wie das Programm aufgebaut ist und warum das wichtig ist. Eine andere Möglichkeit habe ich hier ja garnicht. Ich kann nicht schreiben "Ich habe mich entschieden den Datenzugriff von der Oberfläche zu trennen weil es wichtig ist später die Oberfläche durch eine andere ersetzen zu können" denn das Pattern gibt mir das sowieso vor. In dem Moment wo ich mich dafür entscheide das Pattern zu verwenden kann ich diese Entscheidung nicht mehr treffen, also wäre jede Aussage dieser Art totaler Unsinn. Dann beschreibe ich kurz zwischendurch, dass ich Testroutinen entworfen habe um die untersten Ebenen des Projekts testen zu können (Entscheidung) weil ich sichergehen will, dass alles was darauf aufbaut nicht auf etwas aufbaut was nicht funktioniert (Begründung) und weil ich möchte, dass auch bei zukünfigen Änderungen immer diese Grundlegenden Tests bestanden werden (Begründung). Beim Soll/Ist-Vergleich begründe ich das Fehlen einer Komponente mit dem schlecht abschätzbaren Zeitaufwand. Ich begründe den größeren Zeitaufwand damit, dass ich noch keine Erfahrung mit bestimmter Technologie hatte die zum Einsatz kam. Ich Begründe den großen Erfolg des Projekts damit, dass ich mich an die Vorgaben unserer Firma und von MVVM gehalten habe. Bei 6.5. erkläre ich warum das Projekt so nützlich ist, nämlich weil die Personalkosten so hoch sind und die Zeitersparnis durch das Projekt imens ist.

Das war keine Entschuldigung sondern ein Ausdruck meines Unverständnis... :/ Dass ich bestanden habe ist für mich leider kein grund zur Freude, die Prüfung hätte ich auch schon vor 3 Jahren bestehen können, sie ist ja wohl alles andere als anspruchsvoll. Das einzige für das ich Zeit investiert habe (musste ich ja zwangsläufig) war diese Dokumentation. Und zum Thema Begründung von Entscheidungen... Es gibt noch zahlreiche Worte mit denen man etwas begründen kann, abgesehen von denen die du genannt hast. "um.. zu.." "da" "daher"... Ich denke ich habe die wichtigsten Dinge begründet, die Dinge die eben auf meinen eigenen Entscheidungen basieren, wenn ich allerdings beschreibe wie mein Modellayer aufgebaut ist, macht es meiner Ansicht nach keinen Sinn das zu begründen, denn das sind Vorgaben des Entwurfsmusters und warum ich das Entwurfsmuster benutze habe ich ja begründet... Meine Abweichungen, die Art der Codierung, den Nutzen des Projekts, die Vorgehensweise, all diese Absätze bestehen doch quasi nur aus der Frage "Wie? und Warum genau so?" Also ich versehe wahrlich nicht auf was du ansprichst... Sicher habt ihr ein paar Punkte genannt die Verbesserungspotenzial besitzen, aber den wirklich großen Punkt der diese unfassbar schlechte Bewertung begründen sehe ich immernoch nicht... Ich fühle mich weiterhin zu unrecht derart schlecht bewertet. Mein Ausbilder hat in 12 Jahre enttliche Auszubildende begleitet und er war schockiert. Er ist die Dokumentation selbst durchgegangen und hatte nichts zu bemängeln und so schlecht wurde in unserem Betrieb noch nie jemand bewertet... Was ist mit der Tatsache, dass die Präsentation identisch zum Inhalt der Dokumentation war und über 30% mehr bekommen hat?

Ich kann mir mein Projekt ja nicht aussuchen und wenn es eben so umfangreich und schwer zu beschreiben ist, sodass es die Prüfer mit dem wenigen Aufwand den sie scheinbar betreiben wollten nicht verstanden haben kann ich doch nichts daran änder...

Es ist wirklich schade, ich ging nicht davon aus, dass die Bewertung so oberflächlich erfolg, schließlich habe ich alle Ergebnisse des Projekts (Testergebnisse, den gesamten Quellcode, Screenshots, alle zusätzlichen Dokumente die ich erstellt habe) in digitaler Version beigelegt und dies ja auch in der Dokumentation erwähnt. Das Projekt ist sehr umfangreich und auf diesen paar wenigen Seiten wollte ich eben alles erläutern was das Projekt umfasst, damit der Leser versteht um was es überhaupt geht und was bei der Umsetzung wichtig war. Wenn es wirklich einen Prüfer interessiert hätte was ich genau für Klassen implementiert habe hätte er ja das detailiertere DV-Konzept aus dem Anhang lesen können und in den Quellcode schauen können, hier sind noch Klassendiagramme und alles mögliche zu finden, das hätte allerdings alles nicht mehr in die Doku gepasst. Was bringt es jemandem zu wissen was ich genau implementiert habe wenn er nichtmal weiß wie die gesamte Architektur des Projekts aussieht? Im Projektantrag war eindeutig die Angabe, dass ich alle nicht selbst erstellten Dokumente usw. unterstreichen sollte, hier habe ich nichts unterstrichen, daher ging ich von aus, dass ich nicht explizit erwähnen muss, dass ich alles was dem Projekt sowohl in digitaler als auch in Papierform beigelegt ist von mir stammt. Wenn meine Aufgabe ist ein Projekt durchzuführen und eine Dokumentation zu schreiben und ich erwähne mit keinem Wort, dass ich eine der Aufgaben des Projekts NICHT erledigt habe, muss doch davon ausgegangen werden, dass ich alles selbst umgesetzt habe?!

Der Quellcode lag in digitaler Version bei, es macht keinen Sinn irgend eine Klasse von 80 als Code Snippet beizulegen. Da kann sowieso keiner etwas mit anfangen.

Das verstehe ich nicht ganz, ich habe dieses Programm so wie es in der Doku beschrieben ist komplett umgesetzt... Das ist meine eigene Leistung bei der Erstellung der Software... Wo ist hier das Problem?

Interessante Diskussion aber das alles beantwortet nicht so richtig meine Frage.. ;-)

Hier meine Doku, ich war leider Krank und konnte das nicht früher erledigen. Die Anlagen habe ich jetzt nicht extra anonymisiert und hochgeladen, ich denke die Doku allein reicht für eine kurze Einschätzung ob die 51% gerechtfertigt sein können. Bestimmte Firmennamen, Produktnamen und Personennamen habe ich entfernt. File-Upload.net - Projektdokumentation.pdf

Die IHK hat mir nun als Antwort auf meine E-Mail, in der ich die Situation geschildert habe, angeboten Einsicht in die Bewertung zu nehmen. Ich kann die Doku gerne später auch mal hier zur Verfügung stellen. Kleine Info am Rande: Der Mann heißt Mehdorn und das Wort Mühe kennt er nicht.

Hallo, ich habe ein recht kompliziertes Projekt dokumentieren müssen. Bei meiner Doku habe ich an vorrangegangenen Auszubildenden unseres Unternehmes orrientiert. Ich habe meine Doku auch von allen vorherigen Absolventen lesen lassen und anpassungen vorgenommen. Trotz all dem habe ich einen riesen Schock bekommen als mir von der IHK-Lahn-Dill mitgeteilt wurde, dass meine Dokumentation nur 51% erreicht hat. Meine Schriftliche Prüfung habe ich insgesamt mit 86% abgelegt und auf die Präsentation habe ich 83% bekommen. Die Bewertung der Doku zerstört mir das ganze Ergebnis und das obwohl ich hier die größte Mühe investiert habe. Ich weiß nicht was ich machen soll, mir wurde nichmal richtig erklärt was das Problem war. Es klang lediglich so, als habe keiner richtig Verstanden was Inhalt des Projekts war, bzw. was von dem geschriebenen ich umgesetzt habe und was nicht (Wobei ich alles davon umgesetzt habe, daher habe ich nicht explizit bei jedem Punkt erwähnt, dass ich es selbst umgesetzt habe). Ich verstehe aber überhaupt nicht warum, denn meine Präsentation orentierte sich zu 100% an der Dokumentation. Ich habe sämtliche Grafiken aus der Dokumentation entnommen. Wie kann soetwas sein? Hat jemand Erfahrung damit gemacht, wie so ein Einspruch verläuft, ob das Aufwändig ist und ob man da überhaupt große Erfolgschancen hat?