Das auf die Frage im Titel keine 100%ige Antwort möglich ist weis ich, aber was im groben sollte man in der Präsentation angesprochen haben?(FIAE)

Hab mal so als groben Stichpunkteplan

Ist-Zustand

Probleme des Ist-Zustand

Ziele

....(da verließen sie mich)

In wie weit sollte ich Informationen zur Umsetzung bringen oder gar Codebeispiele?

Soll ich / kann ich den modularen Aufbau meiner Anwendung ansprechen? am liebsten würd ich nämlich solche code-beispiele weglassen, da meine Programmiersprache (ILE-RPG [iBM i-Series]) sowieso keine sau kennt und wenn dann nur vom höhren-sagen.

Würd evtl. auf Probleme eingehen die ich während der Entwicklung hatte, z.b. "das war problematisch, weil..." oder " es gab nicht eingeplante schwirigkeiten bei....".

Wie exakt muss ich mich an meine Doku halten? Wenn die Doku schlecht abschneidet(hoffentlich nicht :-) ) wäre es ja dumm, die sache nochmal in der selben form zu bringen die bereits als schlecht bewertet wurden?

Für ein paar "Gedanken" wäre ich dankbar ....

Beschreibe dein Projekt, also wie du es gemacht hast - nicht was du gemacht hast. Bleibe an der Doku, wobei du diese weder ablesen noch auswendig aufsagen solltest

Beschreibe dein Projekt, also wie du es gemacht hast - nicht was du gemacht hast.

Den Unterschied musst Du mir bitte erklären. Evtl. mit Beispiel, denn es erscheint mir, als ob das Was bei einer Beschreibung des Wie zwingend enthalten ist.

Du beschreibst in deinem Projekt nicht, was du machst, also CD einlegen, hier klicken, dort klicken, sondern du beschreibst das warum, also die Begründungen, warum du so und nicht anders vorgehst, warum du eine bestimmte Konfiguration verwendest.

Genau so sollst du die Präsentation aufbauen.

Ja, soweit war ich schon. Was ich meine ist folgendes: Die Aussage "Ich habe als Metrik für die Produktauswahl eine Nutzwertanalyse über die Kriterien A,B,C durchgeführt" kann sowohl das Wie ("Wie haben sie das geeignetste Produkt gefunden?") als auch das Was ("Was haben sie gemacht, um das geeignetste Produkt zu finden?") beantworten.

Aber vielleicht steh ich auch gerade auf dem Schlauch, deswegen meine Frage.

Beide deiner Fragen zielen aber auf die gleiche Antwort: Lege deine Entscheidungsgrundlagen dar, statt deine Recherchearbeit zu beschreiben.

Danke! Was mich dann gleich zu der Frage führt, ob die Daten, Spezifikation etc. anhand derer man Entscheidungen getroffen hat in der Dokumentation unerwünscht sind? Wie verhält es sich da mit der Nachvollziehbarkeit?

Wieso sollten sie unerwünscht sein? Das ist doch gerade das, was der Rheinländer mit "Butter bei die Fische" bezeichnen würde. Das ist doch das Salz in der Suppe.

Bsp: Du suchst ein Programm um Aufgabe XYZ zu lösen, hast drei Programme zur Auswahl und musst diese drei Programme bewerten.

Du entwickelst eine Entscheidungsmatrix mit einer Wertigkeit deiner Anforderungen, analysierst aufgrund der vorhandenen Spezifikationen die Anwendungen und wählst dann die optimale Lösung aus. Sollten die Spezifikationen den Raum sprengen, dann nur kurze, wichtige Zitate in der Doku einbauen, den Rest dann in den Anhang verfrachten.

Nochmals Danke!

Also sollte ich weniger auf den Aufbau meiner Anwendung eingehen sondern eher beschreiben warum hab ich z.b. das Wasserfallmodell als vorgehensmodell gewählt hab.

Wieso ich anstelle des einkaufs der anwendung mich dafür entschieden hab eine neu entwicklung zu erstellen.

Wie deutlich muss mein eigenanteil in der präsi hervorkommen? ist eine allgemein gehaltene präsentation ohne klare abgrenzung = 6 - wie bei der doku?

Also sollte ich weniger auf den Aufbau meiner Anwendung eingehen sondern eher beschreiben warum hab ich z.b. das Wasserfallmodell als vorgehensmodell gewählt hab.

Wieso ich anstelle des einkaufs der anwendung mich dafür entschieden hab eine neu entwicklung zu erstellen.

Wie deutlich muss mein eigenanteil in der präsi hervorkommen? ist eine allgemein gehaltene präsentation ohne klare abgrenzung = 6 - wie bei der doku?

Genau, es geht um fachspezifische und nachvollziehbare Begründungen deiner Vorgehensweisen und deiner Auswahl (Stichwort: Evaluation). Du musst darlegen, daß du Probleme fachspezifisch bearbeiten und lösen kannst und die Ergebnisse zielgruppenorient präsentieren kannst.

Der reine Aufbau einer Anwendung lässt wenig erkennen, warum etwas gemacht wurde. Das eine Anwendung aus verschiedenen Methoden und Klassen bestehen kann ist schön und gut, ich möchte jedoch erkennen können, welche Gedankengänge jemanden bewogen haben, ein gestelltes Problem genau auf dieser Art und Weise zu strukturieren und zu lösen und warum alternative Lösungsmöglichkeiten nicht genutzt wurden.

Das es bei jedem Problem viele Möglichkeiten der Lösung gibt, ist klar. Warum aber die Gewählte Lösung eine praktikable Lösung ist, ist nicht jedem klar.

Und wenn es darum geht, spielt natürlich die Wirtschaftlichkeit des gesamten Projektes eine starke Rolle.

Wenn dein Eigenanteil nicht klar herauskommt, mag man der Vermutung nahe kommen, daß du entweder nichts gemacht hast, was nicht gut wäre, oder das du etwas geklaut hättest, ohne die genaue Quelle anzugeben, was einer Straftat gleichkommt. Beides ist nicht positiv.