In der dreißigsten Episode des Anwendungsentwickler-Podcasts beende
ich meine Reihe rund um die Inhalte der Projektdokumentation. TL;DR
Ich zeige dir, welche Inhalte nach der Implementierungsphase in
deine Projektdokumentation gehören und wie du den abschließenden
Teil aufbaust. Du hältst fest, wie dein:e Kund:in die Software
abnimmt und wie sie bei den Anwender:innen ankommt; außerdem
erstellst du passende Handbücher für Anwender:innen und
Entwickler:innen. Im Fazit vergleichst du die geplanten mit den
tatsächlich benötigten Zeiten und beschreibst, wie dein Projekt
weitergeht. Übernommene Inhalte belegst du mit Quellen, während du
größere Artefakte im Anhang unterbringst und branchenspezifische
Begriffe bei Bedarf in einem Glossar erläuterst. Kapitelmarken
[00:00:00] Einstieg und Thema der Episode [00:01:47] Software
abnehmen lassen und das Verfahren dokumentieren [00:03:16] Software
bereitstellen und Wartezeiten einplanen [00:05:33] Handbücher für
Anwender:innen und Entwickler:innen erstellen [00:09:00] Fazit:
Geplante und tatsächliche Projektzeiten vergleichen [00:11:40]
Lessons Learned und Zukunft des Projekts [00:13:18] Fließtext und
ergänzende Teile der Dokumentation [00:14:20] Quellen zitieren und
ein Literaturverzeichnis erstellen [00:17:18] Branchenspezifische
Begriffe im Glossar erläutern [00:20:10] Eidesstattliche Erklärung
und IHK-Formblätter [00:21:28] Größere Artefakte im Anhang
unterbringen [00:22:59] Wie Bilder und Leerflächen den bewerteten
Textumfang beeinflussen [00:24:48] Sorgfalt bei der
Projektdokumentation und eigene Verantwortung [00:26:18] Feedback,
Vorlagen und Kontaktmöglichkeiten [00:27:48] Newsletter und
Checklisten für die Projektarbeit Inhalt Abnahme und Einführung
Dokumentation Kunden-/Entwicklerdokumentation Fazit
Soll-/Ist-Vergleich Ausblick Literaturverzeichnis Glossar
eidesstattliche Erklärung Anhang ggfs. nur Auszüge anhängen
Literaturempfehlungen * * Links Permalink zu dieser Podcast-Episode
RSS-Feed des Podcasts Vorlage für die Projektdokumentation
Einführung in LaTeX: 00. Einleitung 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! Zusammenfassung Wie du die Software
abnehmen lässt Nach dem Programmieren folgen weitere Aufgaben,
bevor die Software eingesetzt werden kann. Für deine
Projektdokumentation hältst du fest, wie du dabei vorgehst. Richte
dich danach, wie dein Betrieb Software abnimmt. Je nach Unternehmen
prüft der Fachbereich die Anwendung oder dein:e Kund:in bestätigt
mit einem unterschriebenen Abnahmeprotokoll, dass die Funktionen
geprüft wurden. Wenn dein Betrieb ein formelles Verfahren vorgibt,
hältst du es auch bei deinem Abschlussprojekt ein. Vorgaben zur
Qualität oder Sicherheit können dabei eine Rolle spielen. Ein
unterschriebenes Abnahmeprotokoll kannst du als Beleg in den Anhang
aufnehmen. Dafür reichen auch passende Auszüge. Wie die Anwendung
bei den Anwender:innen ankommt Beschreibe kurz, wie du deine
Software bereitstellst. Bei einer Webanwendung hältst du
beispielsweise fest, wie sie auf den Webserver gelangt und wie die
Anwender:innen die Adresse erhalten. Eine Desktopanwendung muss auf
die vorgesehenen Rechner verteilt werden. Bei einer App können
zusätzliche Schritte nötig sein, um sie in einem App-Store zu
veröffentlichen. Anbieter prüfen eingereichte Apps teilweise vorab,
wodurch Wartezeiten entstehen. Wenn solche Abläufe schon zu Beginn
bekannt sind, berücksichtigst du sie in deinem Projektplan. Was du
für Anwender:innen und Entwickler:innen dokumentierst Zur
Projektarbeit gehören auch Unterlagen für die Menschen, die später
mit der Anwendung arbeiten oder ihren Code pflegen. Die
Ausbildungsordnung fordert, dass du dein Projekt kundenspezifisch
dokumentieren kannst. In Bewertungsschemata gibt es dafür einen
eigenen Punkt. Ein Handbuch für Anwender:innen Beschreibe, wie die
zentralen Anwendungsfälle ablaufen. Ergänze Screenshots, wenn sie
beim Verstehen helfen. Das Handbuch darf auch farbig gestaltet
sein. Wähle eine Form, die zu deinem Projekt und deinen
Anwender:innen passt. Unterlagen für Entwickler:innen Bereits
erstellte Artefakte, etwa ein Klassendiagramm, können helfen, den
Code verständlich zu beschreiben. Aus Kommentaren im Quellcode
lassen sich beispielsweise mit Javadoc HTML-Seiten erzeugen, auf
denen Klassen und ihre Methoden beschrieben werden. Kommentiere
deinen Code während des Programmierens. Für das anschließende
Erzeugen der HTML-Seiten plane ich etwa eine halbe Stunde ein; eine
solche Dokumentation reicht für viele Projekte aus. Wie du dein
Fazit schreibst Geplante und tatsächliche Zeiten vergleichen Mit
einer Tabelle zeigst du für jede Projektphase, wie viele Stunden du
eingeplant und wie viele du gebraucht hast. Anschließend
vergleichst du die Summen und begründest, weshalb sich Zeiten
verschoben haben. Im hier beschriebenen Prüfungsrahmen beträgt die
Projektzeit 70 Stunden. Einzelne Phasen können davon abweichen,
etwa wenn du die Analyse schneller abschließt und mehr Zeit für
Tests brauchst. Bei einem kleinen Projekt machen schon wenige
Stunden einen merklichen Anteil aus. Größere Abweichungen lassen
Fragen dazu entstehen, wie genau du den Aufwand eingeschätzt hast.
Beschreiben, wie dein Projekt weitergeht Halte fest, welche
Aufgaben nach der Prüfung folgen. Dazu können zusätzliche Wünsche
deiner Kund:innen gehören oder die Frage, wer die Anwendung künftig
pflegt. Wenn du nach der Prüfung selbst weiter daran arbeitest,
beschreibst du diese Perspektive ebenfalls. Optional kannst du
persönliche Lessons Learned ergänzen: Was hast du beim Projekt
gelernt, und welche Erfahrungen hast du mit dem Vorgehen gemacht?
Damit bekommt deine Arbeit eine persönliche Note. Welche Teile nach
dem Fazit folgen Bei der IHK, für die ich tätig bin, sind 15 Seiten
Fließtext vorgesehen. Das Fazit endet damit auf Seite 15. Deckblatt
und vorangestellte Verzeichnisse zählen dort ebenso wenig zum
Fließtext wie die nachfolgenden Teile. Quellen belegen Führe
übernommene Inhalte im Literaturverzeichnis auf. Als Quellen kommen
beispielsweise gelesene Dokumentationen oder Webseiten infrage,
ebenso Bücher und Gespräche mit deinem/deiner Ausbilder:in. Setze
direkt an der betreffenden Textstelle einen Quellenhinweis, etwa
als Fußnote. So lässt sich nachvollziehen, woher ein Inhalt stammt
und welchen Anteil du selbst erarbeitet hast. Sortiere das
Literaturverzeichnis und gib die Angaben an, die zur jeweiligen
Quelle gehören, darunter Autor:in und Erscheinungsjahr sowie Titel
und Publikation. LaTeX kann aus BibTeX-Einträgen ein
Literaturverzeichnis erzeugen. Auch Word bietet Funktionen, mit
denen du Quellen im Text referenzierst. Wenn erkennbare Quellen
fehlen oder übernommene Inhalte ohne Beleg bleiben, ziehe ich bei
der Bewertung Punkte ab. Fachbegriffe erläutern Ein
Abkürzungsverzeichnis führt Kürzel mit ihrer ausgeschriebenen
Bedeutung auf, beispielsweise GUI für Graphical User Interface. In
einem Glossar erläuterst du Fachbegriffe mit einigen Sätzen. Ein
Glossar bietet sich an, wenn dein Projekt viele branchenspezifische
Begriffe enthält. Prüfer:innen bringen IT-Fachwissen mit, kennen
aber die Besonderheiten deiner Branche möglicherweise kaum. Auch
SAP-interne Begriffe brauchen deshalb eine verständliche Erklärung.
Allgemein bekannte IT-Begriffe kannst du als bekannt voraussetzen.
Die geforderte Erklärung beifügen Manche IHKs verlangen eine
eidesstattliche Erklärung oder stellen dafür ein Formblatt bereit.
Darin bestätigst du beispielsweise, dass du die Prüfungsleistung
selbst erbracht und sie bisher bei keinem anderen Prüfungsausschuss
eingereicht hast. Übernommene Inhalte müssen entsprechend
gekennzeichnet sein. Falls deine IHK eine solche Erklärung fordert,
unterschreibst du sie und fügst sie nach deren Vorgaben bei. Was in
den Anhang gehört Meine Faustregel lautet: Artefakte, die mehr als
eine halbe Seite beanspruchen, kommen in den Anhang. Dazu gehören
größere Tabellen oder Diagramme, ebenso Quelltextausschnitte und
Auszüge aus dem Pflichtenheft. Im Fließtext können kleinere
Tabellen stehen. Den begrenzten Platz brauchst du, um dein Projekt
verständlich zu beschreiben. Bei meiner Bewertung ziehe ich größere
Bilder und Tabellen im Fließtext vom tatsächlichen Textumfang ab;
das gilt auch für größere leere Flächen. Wenn dadurch deutlich
weniger Text übrig bleibt, wirkt sich das auf die Note aus. Wo du
meine ergänzenden Materialien findest Unter
anwendungsentwicklerpodcast.de findest du die Shownotes mit einem
Link zu meiner Vorlage für die Projektdokumentation und weiteren
Quellen. Über die Kommentare kannst du mir zusätzliche Inhalte
nennen, die bei deinem Projekt eine Rolle spielen. Fragen kannst du
auch per Mail an mail@anwendungsentwicklerpodcast.de oder über das
Kontaktformular stellen. Wenn du dich unter
anwendungsentwicklerpodcast.de/newsletter anmeldest, erhältst du
Zugriff auf meine Checklisten. Sie decken den Projektantrag ab und
helfen dir außerdem, deine Projektdokumentation sowie die
Projektpräsentation vor dem Abgeben zu prüfen. Transkription der
gesamten Episode Automatisch erzeugte Transkription der Episode
[0:00] Hi, hier ist Stefan. In dieser Podcast-Episode geht es um
die Projektdokumentation. Wenn [0:05] du dazu noch mehr
Informationen von mir haben willst, dann schau doch mal auf meiner
Website [0:08] vorbei unter dieperfekteprojektdokumentation.de. Und
jetzt viel Spaß mit der Podcast-Episode. [0:18] Herzlich willkommen
zum Anwendungsentwickler-Podcast, dem Podcast rund um die
Ausbildung zum Fachinformatiker ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.