Mar 10 2024 105 mins 58 1 0

Other Episodes

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)

IT-Berufe-Podcast