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?