Chancen bei Einspruch gegen Bewertung der Projektdoku

[ein Bob]

Das Ding ist eben, dass es den Prüfern nicht darauf ankommt, interessante Projekte zu sehen. Die Dokumentation soll belegen, dass du in der Lage bist, ein Projekt von vorne bis hinten durchzuplanen und sauber abzuarbeiten. Wie ein echter Facharbeiter eben.

Diese Motivation sollte man beim schreiben der Dokumentation im Hinterkopf haben und entsprechend formulieren. Und das hattest du scheinbar nicht.

[phph]

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

[ein Bob]

Brauchst dich doch nicht zu entschuldigen

[Aras]

Weiß garnicht was ihr habt?

Das beste ist doch, dass du bestanden hast. Du kannst also ruhig Widerspruch bzw. Klage am Verwaltungsgericht einlegen und abwarten.

[Wuwu]

Ich denke nach wie vor nicht, dass es an dem Glauben fehlte, dass Du das ganze selbst umgesetzt hast.

Drück mal STRG+F und such nach den Worten Entscheidung, Wahl, weil, begründet oder ähnlichen.

[phph]

Brauchst dich doch nicht zu entschuldigen

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?

[Schiller256]

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

Kannst du in deiner Doku ein paar Beispiele aufzeigen wo du Projektentscheidungen getroffen und auch begründet hast? Der Gesamte Punkt 4 besteht nur aus Allgemeiner Beschreibung so wie du sie in jedem Pattern Buch zu lesen bekommst. Das kannst du vielleicht als Einleitung nehmen aber nicht deine Gesamte Realisierung damit beschreiben.

Der Punkt 5 Test gibt auch nicht mehr her als die Beschreibung das du die Testergebnisse in deiner IDE anzeigen lassen kannst. Welche Test hast du in deinem Projekt weshalb erstellt? Also Modultest und/oder Integrationstest und wieso machst du genau diese Tests in deinem Projekt das ist interessant und nicht das du in deiner IDE Management aufbereitet Tortengrafiken erstellt bekommst.

Ich glaube nicht das es einen großen Punkt gibt wo die viele Punkte verloren gegangen sind. Sondern das dir durch die in meinen Augen schlechte Beschreibung deines Projektes immer mal wieder einzelne Punkte abgezogen wurden. Hier macht es dann die Summe der vielen Einzelabzüge das eine solch schlechte Note bei raus kommt.

[phph]

Kannst du in deiner Doku ein paar Beispiele aufzeigen wo du Projektentscheidungen getroffen und auch begründet hast?

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.

[Klotzkopp]

Ich kann nur das bewerten, was ich sehe, die Anhänge hast du ja nicht hochgeladen. Für mich sieht die Doku ziemlich dünn aus.

Der Sollzustand ist eine Benutzeroberfläche? Es gibt bereits eine Benutzeroberfläche, nämlich das Werkzeug, das die Mitarbeiter bis dahin benutzt haben, um die Datenbank zu ändern. Leider hast du nicht erwähnt, was das ist. Hätte meiner Meinung nach hineingehört.

Du willst nicht eine Benutzeroberfläche, du willst den Mitarbeitern die Möglichkeit bieten, ihre Änderungen schneller, weniger fehleranfällig und überprüfbar umzusetzen. Die Lösung dafür könnte eine neue WPF-Anwendung sein, aber warum sie das ist, diese Erklärung bleibt deine Doku schuldig.

Was ist mit den gesammelten Anforderungen? Sind die irgendwo dokumentiert?

Im Soll-Ist-Vergleich hätte ich mir gewünscht, dass da irgendwie geprüft wird, ob es mit der neuen GUI wirklich schneller und einfacher geworden ist. Ist das in irgendeiner Weise in die Abnahme eingeflossen? Sind die erwähnten Anforderungen erfüllt worden?

Warum C#? Warum WPF? Du zeigst nirgendwo Alternativen auf. Wenn es welche gab, hast du sie nicht erwähnt, und insbesondere auch nicht, warum du dich gegen sie entschieden hast. Wenn es keine gab, kann man das nicht wirklich eine Entscheidung nennen.

Zusammenfassend: Ich finde die Bewertung gerechtfertigt.

[phph]

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

[lilith2k3]

Vorwort:

1.1 Worum geht es im Projekt?

2.2 Definition des Sollzustandes

Was ist die genaue Definition des Projektziels:

»Der AKIA Manager wird eine intuitive Bedienoberfläche zum Erzeugen neuer und Bearbeiten vorhandener Zuordnungen zur Verfügung stellen.« Das kann so ziemlich alles beinhalten

3.2 Ressourcenplanung

Vollkommen redundant. Das ist bis dahin schon mehrfach erwähnt worden. (cf. 2.4)

»Alle Ressourcen sind bereits vorhanden.« ja.

3.4 Softwareschnittstellen

Ebenfalls redundant. Dass auf einer vorhandenen Lösung aufgebaut weiß man zu dem Zeitpunkt schon.

3.5 Use-case

Meiner Meinung nach ist das Use-Case-Diagramm falsch.

Wenn ein Use-Case einen anderen use-case einschließt, so bedient sich der einschließende der Funktionalität des eingeschlossenen. Allerdings ist der eingeschlossene Use-case in jedem Falle auszuführen und der einschließende ist von dem eingeschlossenen abhängig. Wenn das "Mapping Management" jeweils "Mapping neu erstellen", "entfernen" und "bearbeiten" beinhaltet, heißt das, daß jedes mal, wenn das "Mapping Management" ausgeführt wird, alle drei Schritte durchgeführt werden müssen. Des Weiteren sind hier Use-Cases, die Systemverhalten modellieren und nichts mit Anwenderverhalten zu tun haben: "Fehlende Information erkennen", "Konsistenzprüfung" sind im eigentlichen Sinne keine Anwendungsfälle und besser in einem Activity-Diagramm aufgehoben.

»Bei einem Softwareprogramm mit grafischer Oberfläche stehen immer die Bedienfreundlichkeit und die Erleichterung von Arbeitsabläufen im Vordergrund.« Soweit d'accord - aber:

»Eine Bearbeitung mehrerer Datensätze zugleich ist unumgänglich, da andernfalls die Manipulation der Daten durch manuelle Eingabe von SQL schneller ginge als die Bearbeitung mit dem AKIA Manager.«

Ja, und? Dann wäre das "Tool" immer noch sinnvoll, da es vom gemeinen Benutzer nicht verlangt SQL zu können.

3.6 Programmebenen

Abbildung 4 ist kein UML.

Abbildung 5 Ist zwar ein Aktivitätsdiagramm. Allerdings wäre eine Aktivitätsdiagramm im Hinblick auf dass, was Deine Software macht intressanter gewesen.

4. Realisierungsphase

»Quellcode sollte sich grundsätzlich nie wiederholen, Copy & Paste ist bei der Programmierung mit modernen Programmiersprachen fehl am Platz.« Copy&Paste war noch nie richtig - auch schon zu Fortran-Zeiten nicht.

4.2 Projekt Basisstruktur erstellen

Bis hierher ist immer noch nicht wirklich klar, was Du eigentlich machst. Stattdessen verliert sich die Dokumentation in Oberflächlichkeiten. Mal im Ernst: »so wird zum Beispiel der Firmenname etc. in den Assemblyinformationen von dll und exe Dateien eingetragen.« Wen interessiert das?

4.3. Implementierung des Entity Layers

Was ist eine "Entity"?

4.5. Erstellen automatischer Testroutinen

»Die Testroutinen befinden sich in der Projektmappe AkiaTests.« Ja, und?

Wie sieht so ein Test aus?

4.6. Implementierung des Core Layers / der ViewModels

»Eine ViewModel Klasse beinhaltet in unserem Fall immer ein Entity Objekt oder eine Collection davon. Somit muss das Entity nicht in ein ViewModel konvertiert werden, sondern es wird von ihm lediglich umschlossen (Wrapper Klasse)«

Was?

4.7. Implementierung der WPF Oberfläche

»Für den AKIA Manager entwerfen wir zunächst ein Hauptfenster mit einem TreeView Steuerelement auf der linken Seite und einem DataGrid auf der rechten Seite« Und warum kein Bild? Wozu ist die Treeview geeignet? Warum ein TreeView und keine andere? Und was um alles in der Welt wird dargestellt?

4.8. Zusammenführen von ViewModels und Oberfläche

»Zunächst muss beim Laden der Oberfläche das MainViewModel initialisiert werden. Dies geschieht in unserem Fall in der Code-Behind-Datei des Hauptfensters.« Ahja.

5.1. Testphase

"M..... Schi.."<- Name vergessen zu entfernen.

6.1. Projektübergabe

»Nur eine kurze mündliche Einweisung in die einzelnen

Funktionen der Software war notwendig, um die intuitive Bedienoberfläche zu verstehen.«

Bis zu dem Zeitpunkt weiß der Leser immer noch nicht, was genau gemacht worden ist.

Fazit:

Ich kann nicht verstehen, wie Du überhaupt auf 51% bei der Bewertung durch die IHK gekommen bist. Im Grunde hast Du das Ziel der Dokumentation in meinen Augen komplett verfehlt. Ich habe nach dem Lesen der Dokumentation nicht den leisesten Schimmer worum es ging. "Irgendwas mit Daten managen" ... Das ist das, was nach dem Lesen der Dokumentation im meinem Gedächtnis geblieben ist. Die Dokumentation ist vollkommen oberflächlich. Es ist nicht erkennbar, was Du gemacht hast, geschweige denn wie. Und dass das Thema "absrtrakt" ist, kann hier nicht als Entschuldigung dienen. Anhand der Dokumentation wäre ich mir nicht sicher, ob Du überhaupt in der Lage bist, ein Softwareprojekt durchzuführen. Dass Du es anscheinend doch kannst, hast Du wohl in der Präsentation unter Beweis gestellt.

Nicht falsch verstehen: Es geht nicht um die Bewertung Deiner Person oder Deiner gesamten Fähigkeiten, sondern nur, dass die Dokumentation gelinde gesagt, "schlecht" war und ihren Zweck nicht erfüllt. An Deiner Stelle würde ich abstand davon nehmen, gegen die Bewertung vorzugehen. Ich würde das Ergebnis hinnehmen, denn es ist bestenfalls noch geschmeichelt.

[Klotzkopp]

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?

Das Backen eines Roggenbrots ist eben kein Projekt. Vielleicht sind wir damit beim Kern des Problems angekommen.

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

Bearbeitet 29. Juni 2013 von phph

[bubu44]

Hallo phph

deinen Ausbildern solltest du vielleicht doch ein Danke sagen. Zumindest haben die dich anscheinend recht gut vorbereitet für deinen Bereich. Um etwas programmieren zu können, ist sicherlich das eigentliche Programmieren wichtig. Aber, um zu verstehen was du da schreibst, musst du auch die Zusammenhänge kennen. Deshalb ist ein tiefgreifendes Fachwissen in anderen Bereichen auch sehr wichtig.

Wenn du in deine Dokumentation genau das gleiche Engagement gezeigt hättest wie mit der Frage warum du so schlecht bewertest wurdest, dann würde sich diese Frage nicht stellen! Wenn dich dann auch noch überrascht hat, wie so eine Dokumentation auszusehen hat, dann hast du da sicher ein Defizit. In jedem Geschäftsmodell ist es wichtig zu wissen, wer was macht, für wen und wozu und wie viel es kostet. Ansonsten gibt es dieses Geschäftsmodell nicht mehr lange.

Die IHK und die Prüfer wissen sehr wohl, das Arbeitsweisen sich in Betrieben unterscheiden. Und genau deshalb gibt es Vorgaben, um alle einheitlich bewerten zu können. Jede dieser Vorgaben sind in einem Projekt vorhanden. Es wird auch nicht das Thema des Projektes bewertet, sondern die Durchführung des Projektes. Alle die Argumente, die du in deinem letzten Absatz aufführst, werden in der freien Wirtschaft verlangt. Nichts anderes sind die Vorgaben für ein Projekt. In der Ausbildung werden die Grundlagen geschaffen, dass du das gelernte umsetzen kannst. Wenn du das kannst, nennt man das Berufserfahrung und du lässt es dir teuer bezahlen.

Für mich willst du einfach, trotz sachlicher Kritik der anderen hier, deine gezeigte Leistung anders sehen. Wenn du von 100 Leuten der einzige bist der dich toll findet, sollte man etwas ändern. Vielleicht solltest du auch die Möglichkeit prüfen, deine Anwendungen dahingehend zu entwickeln, als Bäcker ein Roggenbrot zu verkaufen!

[lilith2k3]

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

Ob Du ein sehr guter Softwareentwickler geworden bist oder nicht, sei einmal dahingestellt. Zumindest ist Deine Fähigkeit, technisch zu kommunizieren nicht wirklich entwickelt. Und das ist der Grund, weshalb Deine Dokumentation mit »ausreichend« bewertet worden ist. Du kannst nicht das, was Du gemacht hast kommunizieren. Du bist nicht in der Lage, technische Sachverhalte anschaulich zu präsentieren. Du benutzt Fachbegriffe, ohne sie zu erklären. Du verlierst Dich im Jargon.

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 denke nicht, dass es hier darum gehen sollte, ob ich schon einmal Software entwickelt habe, sondern ob Du in der Lage bist, eine Projektdokumentation zu schreiben. Und die Antwort ist schlicht: Nein!

Ich denke, Du solltest die Gelegenheit nutzen und mit Dir selbst ins gericht zu gehen. Das wäre allenfalls besser als hier die beledigte Leberwurst zu spielen - oder der mißverstandene Softwarearchitekt, der für die Banalitäten des Programmiererlebens nur ein müdes Lächeln übrig hat.

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.

Das ist vollkommener Käse. A) scheinst Du überhaupt nichts einzusehen zu wollen und ist nicht das System starr, sondern Du erfüllst nicht die Erwartungen, die man an Dich herangetragen hat.

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.

Das stimmt so nicht. Im Gegenteil: Aufgabe der Projektdokumentation ist es, in einer vorgegebenen Form zu dokumentieren, daß Du diese Fähigkeiten - die Du vorgibst zu besitzen - auch tatsächlich hast. Dass es dazu einer Kulturtechnik, die Du nicht zu beherrschen scheinst, bedarf, ist ein notwendiges Übel und in Deinem Fall bedauerlich.

Nimm das Ergebnis sportlich. Die Leistung war diesmal schlecht und Deine nächste Doku - vielleicht machst Du ja mal einen Bachelor, dann eben Deine "Bachelorarbeit" - wird besser.

[spix]

denn ich bin ein sehr guter Softwareentwickler geworden der gleichzeitig auch tiefgreifendes Fachwissen

Du bist überhaupt kein Softwareentwickler, du bist frisch ausgelernter FIAE. Softwareentwickler kannst du dich nennen, wenn du einige Jahre Berufs-Erfahrung hast.