Anmeldung Registrierung
Auto Hell Dunkel
Erweiterte Suche
  1. Startseite
  2. Podcasts
  3. IT-Berufe-Podcast Podcast
  4. Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186
Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186

Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186

IT-Berufe-Podcast vor 2 Jahren
Zu Sammlung hinzufügen

Du hast noch keine Sammlungen.

Herunterladen (rechte Maustaste) Teilen Fundstellen Kommentare
0:00
37:00
Um die angemessene fachliche bzw. technische Tiefe des Themas für
das IHK-Abschlussprojekt für Anwendungsentwickler:innen geht es in
der einhundertsechsundachzigsten Episode des IT-Berufe-Podcasts.
Inhalt Viele Projektanträge zum Abschlussprojekt werden abgelehnt,
weil das umzusetzende Projekt nicht die nötige fachliche bzw.
technische Tiefe aufweist. In unserem Prüfungssystem gibt es dafür
sogar einen expliziten Ablehnungsgrund. Doch was heißt es genau,
dass die fachliche Tiefe nicht erreicht wurde? Welche fachliche
Tiefe ist überhaupt angemessen und wie erkenne ich als Prüfling, ob
ich sie erreiche? Mein Standardbeispiel: Projektverwaltung Ich
führe als Beispiel für eine übliche Projektarbeit für
Anwendungsentwickler:innen immer eine klassische Web-Anwendung an.
Nehmen wir das oft strapazierte Beispiel einer
Zeiterfassungssoftware oder einer Projektverwaltung. Dabei handelt
es sich um eine kleine Web-Anwendung mit ein paar
Datenbanktabellen, etwas fachlicher Logik und ein paar netten
Oberflächen. In solch einer Anwendung kann ich als
Anwendungsentwickler:in alles zeigen, was ich in meiner
dreijährigen Ausbildung gelernt haben sollte. Soll ich ein Projekt
enpfehlen, führe ich deswegen gerne dieses Beispiel für ein
fachlich ausreichendes Projekt für die Abschlussprüfung an. Ich
kann eine Datenbank modellieren, z.B. mit einem ERM oder
Tabellenmodell. Ich kann ein Klassendesign entwerfen, z.B. mit
einem Klassendiagramm oder gar mit Test Driven Development. Ich
kann die Oberflächen gestalten, natürlich nach ergonomischen
Gesichtspunkten und mit Mockups für den ersten Entwurf. Außerdem
muss ich mich um das Zusammenspiel der Komponenten kümmern und
brauche dafür eine tragfähige Architektur, z.B. MVC. Kurz gesagt
ist in solch einem Projekt alles Technische enthalten, was man
heutzutage in der Programmierung können muss. Und ich kann mich
vieler Methoden der Softwareentwicklung bedienen, die mein
planvolles Vorgehen dokumentieren. Hast du auch ein paar konkrete
Zahlen? Als ganz grobe Daumenregel für Anwendungsentwickler:innen
führe ich immer ein "klassisches" Webprojekt an: kleine Datenbank,
ein bisschen Logik, Frontend drüber. Da kann man das volle Spektrum
der Entwicklungstätigkeiten zeigen. ca. fünf Datenbanktabellen
("eine Hand voll") ca. fünf Oberflächen dazu ca. zehn Klassen
(tendenziell eher mehr) Sollte die Anwendung eine komplizierte
Logik umsetzen, kann natürlich bei den anderen Komponenten
entsprechend gekürzt werden. Diese grobe Richtlinie ist sicherlich
nicht allgemeinverbindlich. Es kommt immer auf den Einzelfall an.
Ich möchte nur deutlich machen, dass eine triviale
Konsolenapplikation, die eine Textdatei einliest und wieder
speichert, nicht ausreicht. Es sei denn, die Applikation verwendet
dafür einen selbst programmierten Verschlüsselungsalgorithmus. Die
Diagramme aus dem Titelbild dieser Episode sollten offensichtlich
zeigen, dass dieser Umfang für ein Abschlussprojekt nicht
ausreicht! Aber ich habe schon Artefakte in echten Dokus gesehen,
die nicht viel umfangreicher waren (z.B. nur zwei Use-Cases oder
drei Aktivitäten). Brauche ich alle Komponenten - Datenbank, Logik,
UI? Das heißt nicht, dass jedes Abschlussprojekt alle genannten
Komponenten umfassen muss. Nicht alle Unternehmen haben die
Anforderung, Weboberflächen über Datenbanken zu gestalten. In
vielen Betrieben wird eine bestehende Software erweitert, eine
Oberfläche angepasst, oder eine Datenbank um zusätzliche Tabellen
erweitert. Oft werden auch Programme benötigt, die gar keine
grafische Oberfläche haben. Wenn es z.B. um den Datenabgleich
zwischen ERP-System und Webshop geht, der nachts als Batchjob
laufen soll, ist es völlig unnötig, eine schön gestaltete grafische
Oberfläche dazu zu entwickeln. Auch werden inzwischen oft REST-APIs
als Abschlussprojekt erstellt, die natürlich auch nicht von
Menschen bedient werden. Daher ist es völlig legitim, auf die ein
oder andere Komponente im Abschlussprojekt zu verzichten. Auch
heißt es umgekehrt nicht automatisch, dass man ein fachlich
ausreichendes Projekt hat, nur weil alle Schichten Berücksichtigung
finden. Eine Weboberfläche mit einem Formular, die simple
CRUD-Operationen gegen eine Datenbanktabelle durchführt, ist
selbstverständlich nicht umfangreich genug. Mein Anti-Beispiel:
SAP-Projekte Dieses Problem haben meiner Erfahrung nach oftmals die
Anwendungsentwickler:innen im SAP-Umfeld. Hier wird häufig nur sehr
wenig tatsächlicher Code produziert, sondern viel mehr Zeit für die
hochkomplexe Infrastruktur verbraten. Da gehen allein schon 7
Stunden drauf, bis man den richtigen Einstiegspunkt in die
"Transaktion" (oder wie auch immer das dort heißt) gefunden hat.
Und die meisten Inhalte lassen sich dann mit SAP-Mitteln
generieren, sodass der Entwickler eigentlich fast gar nichts mehr
tun muss. In eine ähnliche Richtung gehen heutzutage immer mehr die
Low-Code- oder No-Code-Plattformen. Da wird kaum selbst
programmiert, sondern einfach was zusammengeklickt. Und da muss ich
mich dann schon fragen lassen, wie ich "Anwendungsentwickler:in"
werden will, wenn ich gar keine Anwendung entwickle. Aber es gibt
auch Negativbeispiele aus anderen Bereichen. Mein persönliches
Highlight aus einer Abschlussprüfung war eine einzelne HTML-Seite,
die mit 20 Zeilen JavaScript angereichert wurde. Das Problem war,
dass der Prüfling selbst überhaupt nicht verstand, warum dieses
Projekt nicht ausreichend war. Sein:e Ausbilder:in hatte ihn
offensichtlich überhaupt nicht darauf vorbereitet. Und er war sehr
enthusiastisch und freute sich richtig über sein Projekt. Das tat
mir dann wirklich leid, da die Schuld für dieses unzureichende
Projekt sicherlich nicht beim sehr motivierten Prüfling zu suchen
war. Methodik ist das A und O Kurz gesagt sollte ein
Abschlussprojekt zeigen, dass du methodisch Software entwickeln
kannst, die eine gewisse Komplexität aufweist. Dazu habe ich in
dieser Podcast-Episode noch viel mehr zu erzählen: Sinnvoller
Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung. Es
geht darum, dass du deine Fähigkeiten angemessen unter Beweis
stellst. Du sollst methodisch Software entwickeln und die
Projektarbeit wirtschaftlich umsetzen. Dazu gehört u.a. eine
Betrachtung der Kosten und der Amortisation, der Einsatz von
Modellierungs- oder Dokumentationsmethoden (z.B. ERM, UML, EPK,
Mockups), das Erstellen sinnvoller Dokumentationen (z.B. für
Kunden, Betrieb, Entwickler), das planvolle Vorgehen bei der
Projektumsetzung (z.B. Projektplan, Iterationsplanung,
Gantt-Chart), eine gute Qualitätssicherung (z.B. Unit-Tests,
Abnahmeprotokoll) usw. Individuelle Einschätzung Wenn du dir nicht
sicher bist, ob dein geplantes Programm als Abschlussprojekt
ausreicht, dann frag deine:n Ausbilder:in oder deine:n
Berufsschullehrer:in. Die sollten die nötige Erfahrung mitbringen
und die Anforderungen der IHKen einschätzen können. Alternativ
stell dein Projekt doch im Forum vor oder schreib mir eine Mail.
Ich helfe dir gerne mit einer kurzen Einschätzung weiter - aber
erst nachdem du diese Podcast-Episode gehört hast. Links Permalink
zu dieser Podcast-Episode RSS-Feed des Podcasts Sinnvoller
Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung
Episode melden

„Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186“

Worum geht es? Danach fragen wir noch nach dem Grund.

Teilen

Mein Archiv

Deine Privatkopie der Folgen, die du nicht verlieren willst.

Podcast-Folgen verschwinden. Feeds werden auf die letzten Episoden gekürzt, Hoster räumen alte Dateien ab, Formate wechseln den Anbieter und lassen ihr Archiv zurück. Mit „Mein Archiv“ sichert podcast.de die Folgen deiner Podcasts für dich — angefangen bei den ältesten, denn die sind zuerst weg.

  • Deine gesicherten Folgen bleiben hörbar, auch wenn das Original offline geht.
  • Auch Folgen, die im heutigen Feed gar nicht mehr stehen — podcast.de kennt sie noch.
  • Herunterladen bleibt möglich, solange die Folge beim Podcaster liegt. Der zählt seine Abrufe wie bisher.
Startet bald

Sei beim Start von Mein Archiv dabei

Mein Archiv ist fast fertig. Trag dich ein, dann bekommst du eine E-Mail, sobald es losgeht – und bist von Anfang an dabei. Wir schreiben dir nur zum Start, keine Werbung, keine Weitergabe deiner Daten.

Du bekommst zuerst eine Bestätigungsmail. Abmelden geht jederzeit. Datenschutz