In der achtundzwanzigsten Episode des Anwendungsentwickler-Podcasts
führe ich die Punkte einer sinnvollen Gliederung der
Projektdokumentation fort. TL;DR Ich zeige dir, wie du
Projektplanung und Analysephase in deiner Projektdokumentation
beschreibst. Du gliederst dein Projekt in überschaubare Aufgaben,
begründest deinen Entwicklungsprozess und planst die benötigten
Ressourcen samt Kosten ein. In der Analyse prüfst du, ob sich das
Projekt wirtschaftlich lohnt, und recherchierst vorhandene Software
für deine Make-or-Buy-Entscheidung. Ein Use-Case-Diagramm und
schriftlich festgehaltene Anforderungen, etwa in einem Lastenheft,
machen nachvollziehbar, was dein System leisten soll. Kapitelmarken
[00:00:19] Gliederung der Projektdokumentation: Teil 2 [00:01:26]
Projektplanung und Aufgaben eines/einer Projektleiter:in [00:02:22]
Projektphasen und Wasserfallmodell [00:05:03] Zeitanteile der
Projektphasen einschätzen [00:06:00] Aufgaben im Zeitplan sinnvoll
aufteilen [00:08:00] Zeit und Iterationen bei agilen Prozessen
planen [00:09:15] Entwicklungsprozess beschreiben und begründen
[00:11:13] Ressourcen und Eh-da-Kosten berücksichtigen [00:13:12]
Projektablauf bei verschiedenen Vorgehensmodellen [00:14:15]
Analysephase und Wirtschaftlichkeit des Projekts [00:15:51]
Projektkosten und Arbeitszeit berechnen [00:17:12] Einsparungen und
Amortisation ermitteln [00:18:02] Make-or-Buy-Entscheidung und
Marktrecherche [00:21:05] Funktionen mit einem Use-Case-Diagramm
beschreiben [00:22:49] Fachliche Anforderungen und Lastenheft
[00:23:42] Anforderungen als User Stories formulieren [00:24:56]
Anforderungen mit MoSCoW priorisieren [00:26:41] Anforderungen
überprüfbar dokumentieren [00:27:45] Lastenheft erstellen und den
Fachbereich unterstützen [00:30:11] Vorlage, LaTeX-Kurs und
Shownotes [00:30:54] Feedback und Kontakt [00:31:44] Newsletter und
Checklisten zum Abschlussprojekt Inhalt Projektplanung
Projektphasen mit Zeitplanung Entwicklungsprozess Ressourcenplanung
Projektablauf Analyse Wirtschaftlichkeitsbetrachtung, Make or buy
Use-Cases Lastenheft Literaturempfehlungen * * Links Permalink zu
dieser Podcast-Episode RSS-Feed des Podcasts Themenfindung für das
Abschlussprojekt - Anwendungsentwickler-Podcast #24 Inhalte des
Projektantrags - Anwendungsentwickler-Podcast #25 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 Projektplanung in der
Projektdokumentation Ich setze die Gliederung nach der Einleitung
mit der Projektplanung und der Analysephase fort. Als IT-Azubi
zeigst du hier, wie du dein Abschlussprojekt als
Fachinformatiker:in Anwendungsentwicklung methodisch angehst und
praktisch umsetzt. Projektphasen festlegen Gliedere dein Projekt
vor Beginn in Phasen, die zu deinem Entwicklungsprozess passen.
Damit übernimmst du Aufgaben eines/einer Projektleiter:in, zu denen
auch das Planen der Zeit und der benötigten Ressourcen gehört. Beim
Wasserfallmodell durchläuft dein Projekt üblicherweise Analyse,
Entwurf, Implementierung, Test und Dokumentation. Diese Bereiche
gehören auch in deine Projektdokumentation, damit dein Vorgehen und
die entstandene Software nachvollziehbar werden. Für das im Podcast
betrachtete 70-Stunden-Projekt eignet sich das Wasserfallmodell
durch seine klar abgegrenzten Phasen. Ich begegne diesem Modell in
einem großen Teil der Dokumentationen, die ich als Prüfer lese.
Auch bei einem iterativen Vorgehen wie Scrum kommen Analyse,
Entwurf und Test vor. Du durchläufst diese Schritte innerhalb der
einzelnen Iterationen und planst vorab, welche Inhalte du darin
bearbeiten möchtest. Zeit für konkrete Aufgaben einplanen Schätze,
wie viel Zeit jede Phase braucht. Die Zeitanteile sollen zur
Aufgabe passen und in einem sinnvollen Verhältnis stehen. Aus dem
Plan lässt sich auch erkennen, welche technische Tiefe dein Projekt
hat. Teile umfangreiche Phasen in konkrete Aufgaben auf. Eine mit
30 Stunden angesetzte Implementierungsphase braucht Angaben dazu,
welche Arbeiten in dieser Zeit stattfinden. Für das betrachtete
70-Stunden-Projekt empfehle ich als Daumenregel eine bis sieben
Stunden je Aufgabe. Sieben Stunden entsprechen einem Zehntel der
gesamten Projektzeit. Das ist eine Empfehlung für eine
nachvollziehbare Gliederung. Beschreibe beispielsweise, welche
Oberflächen du entwirfst. Der Plan soll zeigen, dass du die Arbeit
durchdacht hast, und zugleich übersichtlich bleiben. Plane auch bei
agilen Prozessen deine Iterationen innerhalb der verfügbaren Zeit.
So lässt sich einschätzen, welchen Umfang du bis zum Projektende
schaffen kannst. Den Entwicklungsprozess begründen Benenne
ausdrücklich, nach welchem Prozess du arbeitest. Dadurch kann ein:e
Prüfer:in nachvollziehen, wie deine Projektphasen zustande kommen
und ob deine Zeitansätze realistisch sind. Begründe, warum der
Prozess zu deinem Projekt passt. Dabei kannst du seine Vor- und
Nachteile erläutern. Ob du Wasserfall, V-Modell oder einen agilen
Prozess wählst, hängt von deinem Projekt ab. Für ein bekanntes
Modell wie Wasserfall reicht eine kurze Beschreibung. Einen selbst
zusammengestellten Prozess, etwa mit Test-Driven Development,
solltest du ausführlicher darstellen. Dafür kommen einige Sätze bis
etwa eine halbe Seite infrage. Begründe auch deine weiteren
Entscheidungen, denn das gehört zu den Punkten, die bei der
Projektdokumentation bewertet werden. Ressourcen vollständig
erfassen Liste auf, welche Hardware und Software du brauchst. Dazu
können dein Arbeitsplatz, ein Gerät zum Testen und kostenpflichtige
Lizenzen gehören. Eine Übersicht im Anhang bietet dafür Platz.
Plane die Arbeitszeit weiterer Beteiligter ein, etwa für
Besprechungen, Code-Reviews oder Abnahmetests. Berücksichtige
vorhandene Infrastruktur und bereits beschäftigte Kolleg:innen bei
den Kosten. Auch ein Server, der schon im Unternehmen steht,
verursacht Kosten, die anteilig auf Projekte entfallen. Solche als
"Eh-da-Kosten" bezeichneten Aufwände gehören in deine Rechnung.
Analysephase Prüfen, ob sich das Projekt lohnt Ermittle, warum das
Projekt umgesetzt werden soll und welchen wirtschaftlichen Ertrag
es für das Unternehmen bringt. Die Wirtschaftlichkeitsbetrachtung
gehört in die Analysephase; fehlt sie, kann das zu Punktabzug
führen. Erfasse deine eigene Arbeitszeit und die anteiligen Kosten
der benötigten Ressourcen. Rechne ebenso die Arbeitszeit von
Kolleg:innen ein, die dein Projekt unterstützen. Bei einem
beispielhaften Stundensatz von 50 Euro kosten vier Stunden
Unterstützung durch dein:e Ausbilder:in bereits 200 Euro. Berechne,
welche Ausgaben das Projekt künftig einspart. Wenn eine eigene
Software eine bisher eingekaufte Lösung ersetzt, können
beispielsweise Lizenz- oder Wartungsgebühren entfallen. Auch die
laufenden Kosten der eigenen Lösung gehören in die Rechnung. Mit
einer Amortisationsrechnung bestimmst du, ab wann die Einsparungen
die Projektkosten decken. Bei langfristig geplanter Software kann
dieser Zeitpunkt mehrere Jahre entfernt liegen. Prüfe anhand der
Zahlen, ob das Projekt wirtschaftlich sinnvoll ist. Ein Projekt,
das Geld kostet und keinen wirtschaftlichen Ertrag bringt, sollte
bereits bei der Themenwahl ausscheiden. Make-or-Buy-Entscheidung
dokumentieren Recherchiere, welche fertigen Softwareprodukte am
Markt verfügbar sind. Prüfe deren Kosten und wie sie die
Anforderungen deines Unternehmens abdecken. Reserviere für diese
Recherche Zeit im Projektplan. Als Beispiel nenne ich ein bis zwei
Stunden. Begründe anhand deiner Ergebnisse, warum du selbst
entwickelst. Wenn vorhandene Produkte benötigte Funktionen nicht
abdecken, halte konkret fest, welche Anforderungen offenbleiben.
Die Aussage, dein Unternehmen habe individuelle Anforderungen,
braucht Belege. Besonders bei häufig gelösten Aufgaben wie
Zeiterfassung oder Projektverwaltung gehört diese Prüfung zur
fachlichen Begründung des Projekts. Die Make-or-Buy-Entscheidung
kann auch im Fachgespräch aufgegriffen werden. Anwendungsfälle mit
einem Use-Case-Diagramm beschreiben Stelle dar, welche Akteur:innen
mit deinem System arbeiten und welche Anwendungsfälle sie ausführen
können. Im UML-Use-Case-Diagramm stehen die Anwendungsfälle als
Ovale innerhalb der Systemgrenze; Verbindungen ordnen sie den
Akteur:innen zu. Besprich das Diagramm mit deinem/deiner Kund:in,
um den vorgesehenen Funktionsumfang abzustimmen und fehlende
Anwendungsfälle zu erkennen. Ich empfehle ein Use-Case-Diagramm für
jede Projektdokumentation als Einstieg in die fachlichen
Anforderungen. Es ist außerdem für die schriftliche
Abschlussprüfung relevant. Anforderungen schriftlich festhalten
Dokumentiere, was dein System fachlich leisten soll. In der
Projektdokumentation sollten mindestens Auszüge dieser
Anforderungen enthalten sein. Daraus muss später erkennbar werden,
ob die geforderten Funktionen erfüllt wurden. Ein Lastenheft hält
die fachlichen Anforderungen des/der Kund:in fest. Im späteren
Pflichtenheft beschreibst du die technische Umsetzung. Du kannst
Anforderungen auch durch andere geeignete Formen festhalten. Ein
Aktivitätsdiagramm kann beispielsweise einen einzelnen
Anwendungsfall genauer beschreiben. User Stories folgen dem Muster
"Als X möchte ich Y, damit Z". Sie benennen die Rolle und die
gewünschte Aktion samt Zweck. Ich verwende sie auch außerhalb
agiler Projekte, weil sich Anforderungen damit einheitlich und
verständlich formulieren lassen. Mit MoSCoW priorisierst du
Anforderungen: Must kennzeichnet zwingend erforderliche
Funktionen,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.