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! :-D 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,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.