Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185

Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für
Fachinformatiker:innen Anwendungsentwicklung geht es in der
einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts.
Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der
Anwendungsentwicklung

Oft lese ich Projektdokumentationen für den Beruf
Fachinformatiker:in Anwendungsentwicklung, die in sich einfach
nicht stimmig sind. Der Projektablauf folgt keinem roten Faden
und Artefakte werden wild durcheinandergewürfelt. Oft werden auch
einfach nur Kapitel aus Dokumentationsvorlagen „ausgefüllt“,
scheinbar ohne über ihre Sinnhaftigkeit nachzudenken.


In dieser Podcast-Episode gebe ich einen Überblick über einen –
aus meiner Sicht – sinnvollen Ablauf eines IHK-Projekts im
Bereich Anwendungsentwicklung inkl. möglicher Artefakte und ihrem
Zweck. Dabei gehe ich nicht auf die Beschreibung des Projekts,
die Wirtschaftlichkeitsbetrachtung, das Projektmanagement, die
Ressourcenplanung usw. ein, sondern nur auf die Planung und
Durchführung der eigentlichen Aufgabe: der Entwicklung einer
Softwarelösung. Selbstverständlich gehören aber alle genannten
Punkte auch in eine IHK-Projektdokumentation.
Wahl des Vorgehensmodells

Fast immer ist das Wasserfallmodell das einzig sinnvolle
Vorgehensmodell, da das IHK-Projekt vom Prüfling alleine in einer
fest vorgegebenen Zeit mit vorgegebenem (weil im Antrag
genehmigten) Umfang umgesetzt werden muss.


Praxisbeispiele für unpassende Prozesse:


Scrum gewählt, aber

klassische Wasserfallphasen durchgeführt/beschrieben

Lasten-/Pflichtenheft erstellt statt User Stories

Projekt alleine umgesetzt ohne Team/Scrum Master/Product
Owner

gesamtes Projekt ist ein einziger Sprint



XP gewählt, aber

keine Praktiken (z.B. Pair Programming, Test Driven
Development) angewendet



Kanban gewählt, aber

Lanes nur ToDo/Doing/Done



Artefakte methodisch sinnvoll einsetzen

Software soll nicht einfach „runterprogrammiert“ werden,
sondern methodisch entwickelt werden. Dabei helfen verschiedene
Artefakte wie Entity-Relationship-Modelle, UML-Diagramme usw.

Diagramme können oft auf zwei Arten eingesetzt werden: zur
Modellierung (vor der Implementierung) und zur Dokumentation
(nach der Implementierung). Sie haben keinen Selbstzweck, sondern
sollen immer den jeweiligen Prozessschritt unterstützen.

Ihr Einsatz muss zum gewählten Prozess passen. Ein
Klassendiagramm zur Modellierung passt z.B. nicht so gut zu
Test-Driven-Development, bei dem die Klassen sich erst bei der
Implementierung ergeben.

Die Artefakte müssen auch zeitlich sinnvoll im Projekt
untergebracht werden. Die Anforderungen erst nach der
Implementierung zu dokumentieren ist sinnfrei.

Artefakte sollen im Prozess auch einen erkennbaren Mehrwert
für die späteren Prozessschritte bieten. Mockups sind z.B. sehr
hilfreich, um auf ihrer Basis ein Datenmodell zu erzeugen. Und
auf Basis des Datenmodells können dann wiederum Klassen
modelliert werden usw.

Durch den passenden Einsatz der Artefakte in den jeweiligen
Prozessschritten füllt sich die Projektdokumentation automatisch
mit spannenden Inhalten für die Prüfer:innen!

Anforderungen aufnehmen

Ist-Analyse durchführen

Bisherige Lösung untersuchen, Schwachstellen aufdecken.

mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN,
Screenshots/Fotos der bisherigen Lösung



Anforderungen an neue Lösung strukturiert erfassen

Interviews mit Stakeholdern führen

Priorisierung der Anforderungen

Ergebnis: z.B. User Stories, MoSCoW



Anwendungsfälle modellieren

Was wollen die Stakeholder mit der Anwendung fachlich
machen/erreichen?

Ergebnis: Use-Case-Diagramm



Anforderungen strukturiert dokumentieren

Ergebnis: Lastenheft



Lösung entwerfen

Neuen Ablauf bzw. neue Lösung skizzieren

Was macht die (neue) Lösung besser? Welche
Personen/Systeme sind wann/wie beteiligt?

mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN



Plattform bzw. Art der Anwendung festlegen: GUI, Web, App
etc.

Welche Anwendungsform löst das gestellte Problem am
besten? Warum? Wie werden die Use-Cases umgesetzt?



UI gestalten

Daraus ergeben sich u.a. die benötigten Daten der
Anwendung.

Direkte Interaktion mit dem Kunden zur Abstimmung der
Inhalte und Abläufe.

Mögliche Ergebnisse: Mockups, Wireframes, Screendesigns,
Workflows, Corporate Design, Aktivitätsdiagramm



Datenmodell entwerfen

Welche Entitätstypen mit welchen Attributen gibt es und
wie hängen sie zusammen?

Welche Anwendungsfälle benötigten welche Daten?

Abstrakt und unabhängig von der konkreten späteren
Speicherlösung modellieren.

Ergebnis: Entity-Relationship-Modell



Architektur der Anwendung modellieren

Welche Architektur eignet sich am besten für die
Umsetzung der Anforderungen?

Beispiele: Domain Driven Design, MVC, Client/Server,
Monolith, REST etc.

Mögliche Ergebnisse: Komponentendiagramm,
Klassendiagramm, Aktivitätsdiagramm, Sequenzdiagramm, Glossar



Datenhaltung definieren

Welche Daten müssen wie/wo gespeichert und übertragen
werden?

Beispiele: Datenbank, Dateien, Cloud, REST-API, JSON/XML
etc.

mögliche Ergebnisse: Nutzwertanalyse



Programmiersprache und Frameworks auswählen

Wenn eine Wahl möglich ist: Welche Sprachen/Frameworks
eignen sich am besten für die Umsetzung? Warum?

Hat die getroffene Wahl eine Auswirkung auf die
Architektur? Muss sich die Anwendung dem Framework anpassen?

Nach welchem Paradigma wird entwickelt? Wie wird
getestet?

mögliche Ergebnisse: Liste der eingesetzten Technologien,
Nutzwertanalyse



Geschäftslogik und Domäne grob planen

Wie sollen die Anforderungen grob umgesetzt werden? Gibt
es besonders „schwierige“ Probleme?

Welche Entitätstypen sind von zentraler Bedeutung? Wie
hängen sie mit anderen zusammen?

Gibt es einen Workflow durch das System? Wie werden die
Daten ausgetauscht?

Mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN,
Sequenzdiagramm, Programmablaufplan, Struktogramm,
Pseudocode, Klassendiagramm



Build und Deployment modellieren

Welche Komponente (UI, Logik, DB etc.) läuft wo?

Wie/wo wird entwickelt?

Welches Build-Tool soll eingesetzt werden? Wo läuft der
Build? Welche Build-Schritte sind nötig?

Welche Stages gibt es? Werden Container verwendet?

Mögliche Ergebnisse: Deploymentdiagramm,
Aktivitätsdiagramm, Sequenzdiagramm, Build-Pipeline,
Dockerfile, Buildfile



Qualitätssicherung planen

Wie wird die Qualität bei der Softwareentwicklung
sichergestellt? Welche Qualitätskriterien sind besonders
wichtig?

Wie wird die fachliche Qualität sichergestellt? Wer
testet wann die Anwendung? Was kann automatisiert werden?

Mögliche Ergebnisse: Testkonzept, Testplan,
Branching-Strategie, Build-Pipeline, Schulungskonzept, zu
erstellende Dokumentationen, statische Codeanalyse,
Entwicklungsprozess (z.B. Pull Requests)



Technische Lösung strukturiert dokumentieren

Ergebnis: Pflichtenheft



Lösung implementieren

Vorgehen bei der Implementierung muss zum gewählten
Prozess/Vorgehen passen

Code First vs. Database First, TDD

mögliche Ergebnisse: interessante Code-Beispiele:
Frontend/Backend/SQL/HTML etc., Klassendiagramm,
Sequenzdiagramm, Screenshots der Anwendung, Tabellenmodell,
Screenshots der Projektstruktur



Deployment auf Zielumgebung durchführen

mögliche Ergebnisse: Dockerfile, Screenshots
Build-/Deployment-Pipeline, Ticketverlauf, Screenshots der
finalen Umgebung



Qualitätssicherung

Eigene Maßnahmen umsetzen (am besten schon während der
Implementierung)

mögliche Ergebnisse: interessanter Code aus
Unit-Tests/Integrationstests/Systemtests/Oberflächentests,
Screenshots der Code Coverage oder statischen Codeanalyse



Externe Unterstützung

mögliche Ergebnisse: Code-Reviews (was ist
herausgekommen?), Pull-Requests, Code-Walkthroughs,
Testprotokoll, Abnahmeprotokoll, Testsuite in Testtool



Dokumentation

Langfristigen Betrieb der Lösung zielgruppengerecht
dokumentieren

mögliche Ergebnisse: Kunden-/Benutzerdokumentation,
Entwicklungsdokumentation, Administrationsdokumentation,
Installationsanleitung, README, Verteilungsdiagramm,
Wiki-Artikel, Build-Pipeline, Klassendiagramm, Tabellenmodell



Beispielablauf

Fiktives Beispiel: Es soll eine bestehende Excel-Lösung abgelöst
werden durch eine Webanwendung.


Ist-Analyse/Anforderungen: Gespräch mit bisherigen
Anwender:innen, Ablauf als EPK dokumentieren, daran
Schwachstellen (z.B. Medienbrüche) aufzeigen, Anforderungen
währenddessen unstrukturiert als Notizen sammeln

Artefakte: EPK (alt), Screenshots der bisherigen
Excel-Datei



Anforderungen strukturieren: Notizen aufbereiten und um
weitere Stakeholder (z.B. Entwickler:innen) ergänzen,
einheitliche Formulierung als User Storys, Anwendungsfälle
modellieren

Artefakte: Use-Case-Diagramm, Lastenheft (Liste der User
Storys)



Neue Lösung skizzieren: Prozess für Lösung des Problems als
EPK modellieren (zum besseren Vergleich zur bisherigen Lösung)

Artefakt: EPK (neu)



Plattform festlegen: Webanwendung, da am einfachsten zu
deployen

UI gestalten und mit Stakeholdern abstimmen, gerne low-level
auf Papier oder dem iPad

Artefakt: Mockups



Datenmodell aus den Mockups (und weiteren Anforderungen)
ableiten

Artefakt: Entity-Relationship-Modell



Architektur der Anwendung mit Domain Driven Design planen,
Domäne ohne Abhängigkeiten und losgelöst von Infrastruktur

Artefakte: Komponentendiagramm, Glossar der zentralen
Domänenbegriffe



Datenhaltung definieren: MariaDB, weil schon etabliert im
Unternehmen

Programmiersprache und Frameworks auswählen: Java mit
Quarkus, weil schon im Unternehmen etabliert und gut für
Container geeignet

Artefakte: Liste der eingesetzten Technologien mit
konkreten Versionsnummern



Geschäftslogik und Domäne aus Datenmodell ableiten

Artefakte: grobes Klassendiagramm ohne Methoden zur
Orientierung, Sequenzdiagramm für zentralen Algorithmus



Build und Deployment modellieren: Build mit Gradle/Jenkins
und Betrieb in Docker/Kubernetes

Artefakte: Deploymentdiagramm, Build-Pipeline (Code),
Dockerfile (Code), Buildfile (Code)



Qualitätssicherung planen: Implementierung mit TDD,
technische Abnahme über Pull-Requests, statische Codeanalyse mit
Sonarqube

Obige Ergebnisse im im Pflichtenheft zusammenfassen

Artefakt: Pflichtenheft



Implementierung Code-First durchführen mittels TDD orientiert
am Datenmodell/Klassendiagramm/Komponentendiagramm mit
Feature-Branches in Git

Artefakte: Code-Beispiele (Produktiv- und Testcode),
Screenshots der Anwendung, Screenshot grünes Quality-Gate in
Sonarqube, Screenshot Pull-Request, Kommentare aus dem
Code-Review



Deployment auf Zielumgebung durchführen mittels Pipeline in
Jenkins

Artefakte: Screenshots der grünen Deployment-Pipeline



Dokumentation für Anwender:innen und Entwickler:innen
erstellen

Artefakte: Benutzerdokumentation, API-Dokumentation mit
JavaDoc, README im Git-Repository, komplettes Klassendiagramm
(generiert), Tabellenmodell (generiert)



Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Word-Vorlage für die Projektdokumentation der IT-Berufe



Weitere Infos zur Projektdokumentation

Du 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!