IT-Berufe-Podcast

Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185

11 Mar 2024

Audio

Description

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,

Transcription

This episode hasn't been transcribed yet

Help us prioritize this episode for transcription by upvoting it.

0 upvotes

🗳️ Sign in to Upvote

Popular episodes get transcribed faster

Other recent transcribed episodes

Transcribed and ready to explore now

13:00H | 21 DIC 2025 | Fin de Semana

01 Jan 1970

Fin de Semana

10:00H | 21 DIC 2025 | Fin de Semana

01 Jan 1970

Fin de Semana

12:00H | 20 DIC 2025 | Fin de Semana

01 Jan 1970

Fin de Semana

2ª PARTE | 06 ENE 2026 | EL PARTIDAZO DE COPE

01 Jan 1970

El Partidazo de COPE

3ª PARTE | 22 ENE 2026 | EL PARTIDAZO DE COPE

01 Jan 1970

El Partidazo de COPE

3ª PARTE | 04 MAR 2026 | EL PARTIDAZO DE COPE

01 Jan 1970

El Partidazo de COPE

Comments

There are no comments yet.

Please log in to write the first comment.

Report any issue

IT-Berufe-Podcast

Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185

This episode hasn't been transcribed yet

Other recent transcribed episodes

13:00H | 21 DIC 2025 | Fin de Semana

10:00H | 21 DIC 2025 | Fin de Semana

12:00H | 20 DIC 2025 | Fin de Semana

2ª PARTE | 06 ENE 2026 | EL PARTIDAZO DE COPE

3ª PARTE | 22 ENE 2026 | EL PARTIDAZO DE COPE

3ª PARTE | 04 MAR 2026 | EL PARTIDAZO DE COPE

Sign in to Audioscrape

Share this moment