Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für Fachinformatiker:innen Anwendungsentwicklung geht es in der einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts.

Podcast: Play in new window | Download (Duration: 1:45:34 — 47.7MB)

Abonnieren: Apple Podcasts | Spotify | RSS

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)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Word-Vorlage für die Projektdokumentation der IT-Berufe

Weitere Infos zur Projektdokumentation

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.

---

Jetzt anmelden!