Die 17 häufigsten Fehler in der Projektdokumentation – Anwendungsentwickler-Podcast #9
IT-Berufe-Podcast - Ein Podcast von Stefan Macke - Montags
Kategorien:
In der neunten Episode meines Anwendungsentwickler-Podcasts gebe ich Beispiele für die 17 häufigsten Fehler in der Projektdokumentation und zeige wie man sie vermeiden kann. Inhalt * Formelle Fehler (leicht/schnell zu korrigieren) * Es sind Rechtschreib-, Interpunktions- und Grammatikfehler vorhanden. * Lasst eure Dokumentation von jemandem (am besten von mehreren Personen) korrekturlesen! * Es sind Rechenfehler vorhanden. * Kontrolliert unbedingt sämtliche Berechnungen (insb. Kosten, Amortisation) auf Fehler. * Es sind keine Quellenangaben vorhanden. * Was ihr euch nicht selbst ausgedacht habt, muss mit Quellen versehen werden. * Die mögliche Seitenzahl wird nicht komplett ausgenutzt. * Nutzt alle erlaubten Seiten bis aufs Letzte aus. Es wäre ärgerlich, wenn ihr eine schlechte Note bekommt, obwohl ihr noch mehr Inhalte hättet zeigen können. * Seiten werden mit uninteressanten Inhalten aufgefüllt. * Packt nur interessante Inhalte (z.B. Quelltexte, Screenshots, Dokumentation) in die Dokumentation und nicht seitenweise langweilige Inhalte. * Verweise auf Artefakte fehlen. * Alle Artefakte (Bilder, Tabellen, Code usw.) müssen im Text referenziert werden. * Fehler in der Nutzwertanalyse. * Achtet auf die formelle Korrektheit der Nutzwertanalyse. Erläutert die Kriterien, die Bewertungsskale und die konkrete Bewertung. * Fachliche Fehler (schwierig/aufwändig zu korrigieren) * Der Wirtschaftlichkeitsteil fehlt. * Eine wirtschaftliche Betrachtung des Projekts ist Pflicht! * Der Technikteil fehlt. * Die Technik sollte den Großteil der Dokumentation füllen. * Die Dokumentation fehlt. * Benutzer- und Entwicklerdokumentation sind absolutes Pflichtprogramm in der Projektdokumentation. * Es sind keine Quelltextbeispiele vorhanden. * Prüfer wollen euren (interessanten!) Quelltext sehen. * Es sind nur langweilige Quelltextbeispiele vorhanden. * Bitte keine Getter/Setter und Klassendefinitionen, sondern spannende Algorithmen zeigen. * Getroffenen Entscheidungen werden nicht begründet. * Insb. die zentralen Entscheidungen (Programmiersprache, Entwicklungsprozess, Datenbank usw.) müssen nachvollziehbar begründet werden. * Es ist kein methodisches Vorgehen erkennbar. * Wir programmieren nicht einfach drauflos, sondern folgen einem definierten Plan und wenden etablierte Methoden (z.B. UML, ERM) an. * Triviale Inhalte werden detailliert ausgeführt. * Bitte nicht eine einfache Berechnung auf drei Seiten bis ins letzte Detail auseinandernehmen, sondern auf einer abstrakteren Ebene euer Projekt und dessen Komponenten schildern. * Das Ziel des Projekts wird nicht deutlich. * Was hat der Prüfling eigentlich selbst gemacht? Warum ist das sinnvoll? * Die notwendige technische Tiefe wird nicht erreicht. * Ist der Umfang des Projekts für ein Abschlussprojekt nach drei Jahren Ausbildung angemessen oder wird nur eine triviale Aufgabe gelöst? Meine Vorlage für die Projektdokumentation könnt ihr als Grundlage für eure Dokumentation oder als Vergleichsdokument verwenden, um eure Dokumentation auf die obigen Fehler zu prüfen. Literaturempfehlungen