In der neunundzwanzigsten Episode des Anwendungsentwickler-Podcasts
setze ich meine Podcast-Serie zu den Punkten einer sinnvollen
Gliederung der Projektdokumentation fort. TL;DR Für deine
Projektdokumentation als IT-Azubi empfehle ich dir, technische
Entscheidungen anhand der Anforderungen zu begründen und mit
passenden Modellen nachvollziehbar zu machen. In der Entwurfsphase
entsteht das Pflichtenheft, das die gewählte Technik sowie den
Aufbau deiner Anwendung beschreibt und bei Bedarf
Oberflächenentwürfe enthält. Wie detailliert du vorab planst, hängt
von deinem Entwicklungsprozess ab. Für die Implementierungsphase
gehören aussagekräftige Klassendiagramme und ausgewählte
Quelltextausschnitte mit den dazugehörigen Tests in die
Dokumentation. Kapitelmarken [00:00:00] Einstieg und Hinweise zur
Projektdokumentation [00:00:33] Anschluss an Analysephase und
Lastenheft [00:01:22] Entwurfsphase und Pflichtenheft als
Projektergebnis [00:03:29] Die passende Plattform auswählen
[00:05:55] Technologien begründen und mit Nutzwertanalyse bewerten
[00:08:25] Architektur und Komponenten planen [00:11:09] Das
Datenmodell herleiten und dokumentieren [00:13:49] Datenstrukturen
außerhalb einer Datenbank darstellen [00:14:28] Oberflächen
entwerfen und mit dem/der Kund:in abstimmen [00:17:17] Das
Pflichtenheft zusammenstellen [00:18:33] Entwurfstiefe und UML
passend zum Entwicklungsprozess [00:21:02] Inhalte der
Implementierungsphase dokumentieren [00:22:14] Testgetrieben
entwickeln und Klassendiagramme erstellen [00:23:42] Eigene
Kernklassen im Klassendiagramm zeigen [00:25:32] Diagramme und
Entwicklungsprozess aufeinander abstimmen [00:26:11] Zentrale
Algorithmen mit UML darstellen [00:28:14] Aussagekräftige
Quelltextausschnitte auswählen [00:30:01] Passende Tests als
Dokumentation des Verhaltens [00:31:44] Ausblick und Feedback
[00:32:43] Fragen und Kontaktmöglichkeiten [00:33:04] Newsletter
und Checklisten zur Abschlussprüfung Inhalt Entwurf Plattform und
Technologien Komponenten und Architektur Datenmodell Mockups der
GUI Implementierung Maßnahmen zur Qualitätssicherung
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 Entwurfsphase und
Pflichtenheft Aus den fachlichen Anforderungen im Lastenheft
entwickelst du einen technischen Entwurf. Dabei beschreibst du die
Software so genau, dass ein:e andere:r Entwickler:in sie anhand
deiner Unterlagen umsetzen kann. Im Pflichtenheft hältst du fest,
wie du die Anforderungen technisch erfüllen willst. Dazu gehören
beispielsweise das Datenmodell und die Ablauflogik. Falls deine
Anwendung eine grafische Oberfläche hat, kommen entsprechende
Entwürfe hinzu. Laut der im Podcast angesprochenen Berufsverordnung
kann auch ein Abschlussprojekt vorgesehen sein, das mit dem
fertigen Pflichtenheft endet. Damit zeigst du deine Fähigkeiten
beim methodischen Entwerfen von Software. Plane Zeit für das
Pflichtenheft ein und füge zumindest Auszüge im Anhang deiner
Projektdokumentation hinzu. In echten Projekten kann es zum Vertrag
gehören und festlegen, welche Leistung du erbringen sollst.
Plattform und Technologien begründet auswählen Ob deine Anwendung
im Browser oder auf einem Mobilgerät laufen soll, ergibt sich aus
den Anforderungen. Auch die vorgesehene Laufzeitumgebung
beeinflusst deine Entscheidung. Begründe, warum die gewählte
Plattform zu deinem Projekt passt. Bei einer Webanwendung entfällt
beispielsweise das Installieren auf den Clients, während du
berücksichtigen musst, welche Browser unterstützt werden sollen.
Für eine mobile Anwendung kann entscheidend sein, dass sie auch
offline funktioniert. Beschreibe anschließend die konkrete Technik,
mit der du arbeiten willst. Erläutere etwa, warum du eine bestimmte
Programmiersprache auswählst und welche Frameworks dazu passen.
Auch das Betriebssystem gehört zu diesen technischen
Entscheidungen. Mit einer Nutzwertanalyse kannst du mögliche
Technologien anhand projektbezogener Kriterien bewerten. Geeignete
Kriterien ergeben sich beispielsweise daraus, ob du XML verarbeiten
oder einen REST-Service bereitstellen musst. Begründe auch Technik,
die dein Betrieb bereits einsetzt, anhand ihrer Eignung für dein
Projekt. Dadurch kann ein:e Prüfer:in nachvollziehen, wie du zu
deiner Entscheidung gekommen bist. Architektur und Komponenten
planen Bevor du einzelne Klassen ausarbeitest, legst du fest, wie
deine Anwendung grob aufgebaut sein soll. Für ein überschaubares
Abschlussprojekt empfehle ich dir, dich an etablierten
Architekturen zu orientieren. Ein UML-Komponentendiagramm zeigt die
Bestandteile deiner Software und ihre Beziehungen. Bei MVC ordnest
du dabei zu, welche Aufgaben zu den jeweiligen
Architekturbestandteilen gehören. Falls Teile deiner Software auf
verschiedenen Systemen laufen, kannst du mit einem
Verteilungsdiagramm darstellen, wo sie ausgeführt werden. Das
betrifft etwa eine Serverkomponente und eine App auf einem
Mobilgerät. Berücksichtige beim Planen der Reihenfolge, welche
Komponenten voneinander abhängen. Welche du zuerst entwickelst,
richtet sich nach deinem Projekt. Datenmodell verständlich
dokumentieren Bei datenbankgestützten Anwendungen bauen viele
weitere Teile der Software auf dem Datenmodell auf. Deshalb räume
ich diesem Bereich in der Dokumentation ausreichend Platz ein.
Wähle eine Darstellung, die zu deinen Daten passt, beispielsweise
ein ER-Modell oder ein Tabellenmodell. Für eine Graphdatenbank
kommt ein entsprechendes Graphmodell infrage. Beschreibe, wie du
das Modell aus den Anforderungen abgeleitet hast. Erläutere
besondere Entscheidungen, etwa bewusst vorgesehene Redundanzen oder
weshalb du etwas als eigene Entität modellierst. Auch Daten aus
Dateien brauchen eine verständliche Darstellung. Wenn deine
Anwendung etwa JSON oder XML verarbeitet, dokumentierst du die
jeweilige Struktur in einer dafür geeigneten Form. Grafische
Oberflächen mit dem/der Kund:in abstimmen Wenn dein Projekt eine
grafische Oberfläche enthält, erstellst du vorab Entwürfe und
besprichst sie mit dem/der Kund:in. Änderungen lassen sich in
dieser Phase mit geringerem Aufwand einarbeiten. Mockups können auf
Papier entstehen oder mit einer passenden Software erstellt werden.
Auch PowerPoint oder Excel kommen dafür infrage. Für einen
gemeinsamen Papierentwurf kannst du einen Termin in deiner
Projektplanung vorsehen. Die Skizze lässt sich anschließend
einscannen und in die Dokumentation aufnehmen. Hole anhand des
Entwurfs Rückmeldungen ein, damit du die Oberfläche vor dem
Programmieren abstimmen kannst. Die Entwurfstiefe an deinen Prozess
anpassen Bei einem agilen Vorgehen empfehle ich dir, zunächst den
groben Aufbau und die Datenstrukturen festzulegen sowie vorhandene
Oberflächen zu entwerfen. Konkrete Details auf Methodenebene
ergeben sich dann beim Entwickeln. Wenn dein Prozess einen
detaillierten Entwurf verlangt, ergänze passende UML-Diagramme. Ein
Klassendiagramm beschreibt die konkreten Klassen, während
beispielsweise ein Sequenzdiagramm ihre Zusammenarbeit sichtbar
macht. Für solche Darstellungen empfehle ich UML; im Podcast werden
auch Programmablaufpläne und Nassi-Shneiderman-Diagramme als
Inhalte der schriftlichen Prüfung angesprochen. Die
Implementierungsphase nachvollziehbar zeigen Da das Programmieren
häufig den größten Zeitanteil im Projekt beansprucht, sollte dieser
Bereich entsprechend Raum in deiner Dokumentation erhalten. Für
objektorientierte Software gehört für mich ein Klassendiagramm
dazu. Du kannst es vorab entwerfen oder nachträglich aus deinem
Quelltext erzeugen. Der Zeitpunkt muss zu dem Entwicklungsprozess
passen, den du beschreibst. Beim Test Driven Development entsteht
die konkrete Struktur während des testgetriebenen Entwickelns.
Anschließend kannst du sie dokumentieren. Richte das
Klassendiagramm auf deine selbst entwickelten Kernklassen und deren
Logik aus. Beschränke dargestellte Framework-Bestandteile und
automatisch erzeugte Methoden auf das, was zum Verständnis
beiträgt. Für einen zentralen Algorithmus kann ein zusätzliches
UML-Diagramm sinnvoll sein. Ein Aktivitätsdiagramm stellt Abläufe
dar; bei einem Zustandsautomaten eignet sich ein Zustandsdiagramm.
Wähle solche zusätzlichen Darstellungen gezielt aus, da du sie bei
Änderungen pflegen musst. Quelltext und passende Tests auswählen
Mit ausgewählten Ausschnitten aus deinem eigenen Quelltext zeigst
du, wie du programmiert hast. Dafür eignen sich Stellen mit
aussagekräftiger Logik, beispielsweise der Umgang mit generischen
Klassen oder Lambdas. Begrenze die Ausschnitte auf Code, an dem
sich deine eigene Leistung erkennen lässt. So bleibt Platz für die
Modelle und das methodische Vorgehen. Ergänze Testcode, der zu den
gezeigten Quelltextausschnitten gehört. An den Tests lässt sich
ablesen, wie sich die Software unter bestimmten Bedingungen
verhalten soll. Tests dienen zugleich als Dokumentation des Codes.
Weil sie gemeinsam mit der Software weiterentwickelt und gepflegt
werden, helfen sie dabei, das erwartete Verhalten nachzuvollziehen.
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....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.