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?