Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für
Fachinformatiker:innen Anwendungsentwicklung geht es in der
einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts. TL;DR
Für dein Abschlussprojekt als Fachinformatiker:in
Anwendungsentwicklung empfehle ich das Wasserfallmodell, weil du
deine eigene Prüfungsleistung innerhalb von 80 Stunden umsetzt und
die Anforderungen früh klären kannst. Wenn du Diagramme und andere
Artefakte passend zum Projektablauf erstellst, helfen sie dir beim
Entwickeln und machen deine Entscheidungen für Prüfer:innen
nachvollziehbar. Aus den fachlichen Anforderungen entstehen ein
abgestimmter Lösungsentwurf und das Pflichtenheft, auf deren
Grundlage du programmierst, die Qualität prüfst und die Software
zielgruppengerecht dokumentierst. Kapitelmarken [00:00:00] Ein
Abschlussprojekt mit nachvollziehbarem Aufbau [00:03:54]
Softwareentwicklung und weitere Pflichtbestandteile [00:05:13] Das
Vorgehensmodell selbst wählen und begründen [00:08:23] Scrum im
kurzen Einzelprojekt [00:13:45] Extreme Programming und Kanban im
Prüfungsrahmen [00:16:50] Meine Empfehlung für das Wasserfallmodell
[00:17:08] Artefakte als Belege für methodisches Entwickeln
[00:19:25] Softwareentwicklung im Zusammenhang mit KI [00:21:04]
Den Zweck von Artefakten deutlich machen [00:24:18] Vorab
modellieren und nachträglich dokumentieren [00:28:13] Artefakte
passend zur Methode und Reihenfolge einsetzen [00:31:28] Vom
abgestimmten Mockup zum Datenmodell [00:35:34] Den bisherigen
Zustand untersuchen [00:37:58] Anforderungen erfassen und
strukturieren [00:39:38] Anwendungsfälle mit einem
Use-Case-Diagramm abstimmen [00:41:50] Den künftigen Prozess
entwerfen [00:44:51] Die Plattform auswählen und begründen
[00:46:21] Oberfläche und externe Schnittstellen skizzieren
[00:49:23] Ein unabhängiges ER-Modell ableiten [00:52:06]
Architektur und Komponenten planen [00:54:51] Fachbegriffe im
Glossar festhalten [00:56:15] Datenhaltung festlegen [00:58:24]
Programmiersprache und Framework auswählen [01:00:39]
Geschäftslogik und Domäne entwerfen [01:04:27] Build und Deployment
vorbereiten [01:10:15] Qualitätskriterien und Tests planen
[01:13:45] Technische Entscheidungen im Pflichtenheft festhalten
[01:15:55] Mit TDD programmieren und das Datenbankvorgehen wählen
[01:18:25] Code und Ergebnisse im Anhang zeigen [01:20:11] Die
Anwendung auf der Zielumgebung bereitstellen [01:21:36] Tests
ausführen und Qualität belegen [01:23:35] Die Software
zielgruppengerecht dokumentieren [01:27:18] Beispielprojekt: Eine
Excel-Lösung ablösen [01:27:59] Beispiel: Den alten Ablauf und
Anforderungen erfassen [01:30:19] Beispiel: Neuen Prozess und
Mockups entwerfen [01:32:21] Beispiel: Datenmodell und Architektur
ableiten [01:33:34] Beispiel: Datenbank und vertraute Technologien
wählen [01:34:37] Beispiel: Geschäftslogik und Build vorbereiten
[01:36:36] Beispiel: Qualität planen und Pflichtenheft erstellen
[01:38:42] Beispiel: Mit TDD entwickeln und deployen [01:40:08]
Beispiel: Dokumente erzeugen und Belege auswählen [01:42:35]
Frühzeitiges Feedback im Fachbereich einholen [01:43:56] Newsletter
und Shownotes 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,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.