Da ich gerade wieder einen Haufen Projektanträge für das
Abschlussprojekt gelesen habe, geht es in der fünfzigsten Episode
des Anwendungsentwickler-Podcasts um die häufigsten Fehler im
Projektantrag und wie man sie als Prüfling vermeiden kann. TL;DR
Aus meinen Erfahrungen als Prüfer zeige ich dir 14 häufige Fehler
im Projektantrag: Damit dein Abschlussprojekt als
Fachinformatiker:in Anwendungsentwicklung beurteilt werden kann,
muss erkennbar sein, wie du methodisch vorgehst und welche
technische Tiefe deine Aufgabe hat. Beschreibe das betriebliche
Problem verständlich, benenne die geplanten Technologien und
berücksichtige, ob sich das Projekt wirtschaftlich lohnt. Teile
deine Projektzeit in konkrete Arbeitsschritte auf, beachte die
Vorgaben deiner IHK und lass deinen Antrag vor dem Einreichen
gegenlesen. Kapitelmarken [00:00:01] Thema: Häufige Fehler im
Projektantrag [00:00:20] 50. Episode und Erfahrungen mit aktuellen
Projektanträgen [00:02:07] Fehler 1: Lange Projektphasen genauer
aufteilen [00:04:34] Fehler 2: Methodisches Vorgehen erkennbar
machen [00:06:37] Fehler 3: Geplante Artefakte benennen [00:08:38]
Fehler 4: Wirtschaftlichkeit berücksichtigen [00:10:28] Fehler 5:
Programmiersprache und Technologien angeben [00:12:27] Fehler 6:
Technische Tiefe deutlich machen [00:15:02] Fehler 7: Projektzeit
vollständig und konkret verplanen [00:17:26] Fehler 8:
Projektphasen angemessen gewichten [00:19:09] Fehler 9: Zeit für
die Projektdokumentation begrenzen [00:20:17] Fehler 10:
Dokumentation für Anwender:innen und Entwickler:innen einplanen
[00:22:32] Fehler 11: Das betriebliche Problem verständlich
beschreiben [00:26:27] Fehler 12: Verständliche Sätze schreiben
[00:27:24] Fehler 13: Rechtschreibung und Grammatik prüfen
[00:29:20] Fehler 14: Sachlich und passiv formulieren [00:30:37]
Rückblick auf die 14 häufigsten Fehler [00:33:42] Vertiefende
Artikel in den Shownotes [00:34:09] Bloghinweise zu Laserpointern
und Java 8 [00:34:58] Aktualisierte Checkliste für den
Projektantrag [00:35:59] Ausblick: Produktivität für
Softwareentwickler:innen Inhalt Lange Projektphasen von teils 40
Stunden werden nicht weiter runtergebrochen. Eine methodische
Softwareentwicklung wird nicht deutlich. Zu erstellende Artefakte
werden nicht genannt. Die Betrachtung der Wirtschaftlichkeit wird
vergessen. Zu verwendende Programmiersprache und -plattform werden
nicht genannt. Die technische Tiefe wird nicht deutlich. Die
Projektzeit wird nicht exakt verplant (Puffer). Die Zeitplanung ist
nicht sinnvoll (Verhältnis passt nicht). Die Problemstellung ist
unverständlich. Es wird zu viel Zeit für die Dokumentation
eingeplant (teils 20 Stunden). Benutzer- und/oder
Entwicklerdokumentation werden nicht eingeplant. Der Text ist
schwer verständlich (z.B. ohne Einleitung mitten ins Thema
einsteigen). Der Text ist voller Rechtschreibfehler. Der Prüfling
schreibt in der Ich-Perspektive. Links Permalink zu dieser
Podcast-Episode RSS-Feed des Podcasts Inhalte des Projektantrags
Ist die Projektdokumentation Teil der Bearbeitungszeit des
IHK-Abschlussprojekts? Wie viel Zeit sollte man für die
Projektdokumentation einplanen? Muss die Projektbearbeitungszeit
(70 Stunden) wirklich genau eingehalten werden? Die
Wirtschaftlichkeit interessiert niemanden – Mythen der
Projektpräsentation Erzählperspektive der Projektdokumentation
Weitere Infos zum ProjektantragDu suchst noch mehr Tipps rund um
den Projektantrag? Dann schau doch mal in diese Artikel- und
Podcast-Kategorie: Alle Artikel rund um den Projektantrag.Und wenn
du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort
meine Checkliste für den Projektantrag herunterladen.Jetzt
anmelden! Zusammenfassung 14 häufige Fehler im Projektantrag Als
Prüfer muss ich anhand deines Antrags einschätzen können, ob dein
Projekt zum Berufsbild Fachinformatiker:in Anwendungsentwicklung
passt und innerhalb der vorgesehenen Zeit machbar ist. Die
Zeitbeispiele hier beziehen sich auf 70 Stunden Projektzeit. Meine
Empfehlungen zu einzelnen Zeitansätzen sind persönliche Richtwerte;
bei IHK-spezifischen Fragen gelten die Vorgaben deiner zuständigen
IHK. 1. Lange Projektphasen genauer aufteilen Wenn du 40 Stunden
pauschal für das Programmieren einplanst, bleibt offen, welche
Aufgaben du bearbeitest und wie du dabei vorgehst. Teile solche
Phasen in konkrete Arbeitsschritte auf, damit sich der Aufwand
fachlich beurteilen lässt. Mein Richtwert liegt bei höchstens acht
Stunden pro Arbeitsschritt, also einem ganzen Arbeitstag. 2.
Zeigen, wie du methodisch Software entwickelst Beschreibe, mit
welchen Methoden du deine Lösung planst. Bei einer Datenbank lässt
sich beispielsweise ein Entity-Relationship-Modell vorsehen,
während bei objektorientierter Software nachvollziehbar werden
sollte, wie du Klassen und Architekturschichten entwirfst. Der
Antrag muss erkennen lassen, dass du planvoll Software entwickelst
und auf Qualität achtest. 3. Geplante Artefakte benennen Über die
Ergebnisse deiner einzelnen Arbeitsschritte wird dein Vorgehen
greifbar. Nenne die Artefakte, die du im Projekt erstellen wirst.
Je nach Aufgabe kommen beispielsweise infrage: Lastenheft und
Pflichtenheft ER-Modell oder Tabellenmodell für die Datenbank
UML-Diagramme, etwa Use-Case-, Klassen-, Aktivitäts-, Zustands-
oder Sequenzdiagramme Architekturskizzen oder Paketdiagramme
Mock-ups für die Oberfläche EPKs, Struktogramme oder
Programmablaufpläne Welche davon passen, ergibt sich aus deinem
Projekt. Mit ihnen lässt sich erkennen, wie du Anforderungen und
technische Zusammenhänge durchdenkst. 4. Prüfen, ob sich das
Projekt wirtschaftlich lohnt Zum Abschlussprojekt gehört ein
Praxisbezug. Plane deshalb ein, Kosten und benötigte Ressourcen zu
betrachten und den wirtschaftlichen Vorteil deiner Lösung zu
prüfen. Dafür erwarte ich etwa zwei bis drei Stunden; eine
Amortisationsrechnung sollte ergänzend berücksichtigt werden. 5.
Die konkreten Technologien nennen Gib an, welche Programmiersprache
du einsetzt und auf welcher Plattform deine Anwendung laufen soll.
Auch die Datenbank und eingesetzte Frameworks gehören in den
Antrag. Diese Angaben helfen mir, den Aufwand einzuschätzen, weil
ein Framework bestimmte Aufgaben bereits übernimmt und damit
beeinflusst, wie viel Zeit du dafür brauchst. 6. Die technische
Tiefe deutlich machen Beschreibe deine Aufgabe so konkret, dass der
fachliche Anspruch erkennbar wird. Dazu gehören technische
Anforderungen und Angaben dazu, was du selbst entwickeln wirst. Das
Projekt muss die berufsspezifischen Fähigkeiten zeigen, die nach
einer dreijährigen Ausbildung erwartet werden. Bleibt der Umfang
deiner eigenen Entwicklungsarbeit unklar, kann der Antrag abgelehnt
werden. 7. Die gesamte Projektzeit konkret verplanen Ordne die
verfügbaren 70 Stunden vollständig konkreten Aufgaben zu. Pauschale
Pufferzeiten halte ich für ungeeignet; einige IHKen verlangen
allerdings einen Puffer, weshalb du ihre Vorgaben prüfen musst.
Auch pauschal reservierte Stunden für spätere Fehler werfen Fragen
auf, solange Umfang und Art dieser Fehler unbekannt sind. Tests
lassen sich bereits während der Entwicklung einplanen,
beispielsweise als Unit-Tests. 8. Die Projektphasen angemessen
gewichten Wenn du zwei Stunden für die Analyse und 45 Stunden fürs
Programmieren vorsiehst, fehlt aus meiner Sicht ausreichend Zeit,
um die Anforderungen zu klären. Berücksichtige neben dem
Implementieren auch Analyse und Entwurf sowie Qualitätssicherung
und gegebenenfalls Abnahme. Die Zeitansätze müssen zum jeweiligen
Aufwand passen. In einem Projekt zur Anwendungsentwicklung sollte
das Implementieren den größten Anteil erhalten. 9. Für die
Projektdokumentation angemessen viel Zeit vorsehen Ob die bewertete
Projektdokumentation innerhalb der 70 Stunden entstehen muss, hängt
von deiner IHK ab. Prüfe das vorab. Falls sie zur Projektzeit
zählt, empfehle ich etwa sieben bis acht Stunden dafür. Mehr als
zehn Stunden halte ich bei diesem Projektumfang für zu viel. 10.
Dokumentation für Anwender:innen und Entwickler:innen
berücksichtigen Plane diese Dokumente ein, sofern sie für dein
Projekt sinnvoll sind. In vielen IHK-Bewertungsschemata werden sie
separat bewertet. Für ein überschaubares Handbuch mit Screenshots
und kurzen Erläuterungen setze ich ungefähr drei bis vier Stunden
an. Wenn die Dokumentation für Entwickler:innen aus bereits
geschriebenen Quelltextkommentaren erzeugt wird, etwa mit Javadoc,
rechne ich für das Erzeugen und Bereitstellen ungefähr eine halbe
Stunde. Zusätzlicher Aufwand muss entsprechend berücksichtigt
werden. 11. Das betriebliche Problem verständlich beschreiben Führe
so in dein Projekt ein, dass eine betriebsfremde Person den
Zusammenhang versteht. Beschreibe dein Unternehmen und die
relevante Infrastruktur, bevor du das Problem und das Projektziel
erläuterst. Erkläre interne Produktnamen ebenso wie
betriebsspezifische Fachbegriffe. Lass eine Person außerhalb deines
Unternehmens prüfen, ob sie versteht, worum es geht. Bei
Kolleg:innen sind viele Begriffe bereits bekannt, sodass fehlende
Erläuterungen beim Gegenlesen leicht übersehen werden. 12.
Verständliche Sätze schreiben Achte beim Überarbeiten darauf, ob
verschachtelte Sätze oder unklare Einschübe den Text schwer lesbar
machen. Auch fehlende Sätze können Zusammenhänge unterbrechen. Eine
externe Person kann dir beim Gegenlesen zeigen, an welchen Stellen
sie hängen bleibt. Wenn ich als Prüfer den Inhalt nicht
nachvollziehen kann, lässt sich die Eignung des Projekts nicht
beurteilen. 13. Sprachliche Fehler korrigieren lassen Prüfe deinen
Antrag auf Rechtschreibfehler und achte beim Gegenlesen auch auf
Grammatik sowie Zeichensetzung. Falls dir das schwerfällt, hole dir
Unterstützung, beispielsweise bei deinem/deiner Ausbilder:in oder
einer anderen Person, die sprachlich sicher ist. Ein sorgfältig
geprüfter Antrag vermittelt, dass du auf die Qualität deiner Arbeit
achtest. 14. Den Antrag sachlich formulieren Für technische
Projekttexte empfehle ich eine neutrale, passive Schreibweise....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.