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

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Vorlage für die Projektdokumentation

Das komplette Regelwerk der deutschen Rechtschreibung

DIN-konformes Literaturverzeichnis mit LaTeX

Nutzwertanalyse – Wikipedia

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!