Einen kurzer Rückblick auf meine "Highlights" der
Projektdokumentationen zur Sommerprüfung 2016 gibt die
fünfundsechzigste Episode des Anwendungsentwickler-Podcasts. TL;DR
Bei meinen Prüfungen im Sommer 2016 sind mir häufig kopierte
Inhalte und Lücken in der Projektdokumentation begegnet. Für deine
Abschlussarbeit brauchst du eigene Formulierungen, sauber belegte
Quellen und nachvollziehbare Gründe für deine technischen
Entscheidungen. Halte dich an die Vorgaben deiner IHK und zeige
anhand konkreter Ergebnisse, was du entwickelt hast. Alles, was du
über dein Vorgehen und deinen Code schreibst, muss zu deinem
Projekt passen und sich im Fachgespräch erklären lassen.
Kapitelmarken [00:00:18] Rückblick auf die mündlichen Prüfungen
2016 [00:02:39] Prüfungsbereiche und Gewichtung von Teil A
[00:03:44] Plagiate in Dokumentation und Präsentation [00:09:08]
Zeit für die Dokumentation mit der IHK klären [00:10:48] Erlaubten
Seitenumfang ausschöpfen [00:12:26] Fehlende Inhalte und
Screenshots [00:13:57] Realistische Stundensätze für die
Kostenrechnung [00:15:00] Technologien passend zum Projekt
auswählen [00:16:14] Betriebliche Systeme verständlich beschreiben
[00:18:02] Vorhandene Software und Eigenentwicklung abwägen
[00:21:00] Projektablauf stimmig dokumentieren [00:22:55]
Code-Reviews durchführen und Ergebnisse erklären [00:24:59]
Anforderungen an die Entwickler:innen-Dokumentation [00:26:11]
Kurze Projekttitel und lesbare Kopfzeilen [00:27:02] Sprache und
Layout prüfen [00:28:22] Commit-Regeln als vermeintliche
Entwickler:innen-Dokumentation [00:29:05] Amortisationsrechnung
verständlich halten [00:29:55] Open-Closed-Prinzip verstehen und
belegen [00:33:30] Fachbegriffe und Kanban im Fachgespräch erklären
[00:35:13] Einheitliche Sprache im Quellcode [00:37:32] Ausblick
auf Präsentation und Fachgespräch Inhalt Plagiate nehmen Überhand.
Insbesondere von dieser Seite. Dringende Warnung: Das kann die Note
und/oder die Prüfung kosten! Viele Dokumentationen nutzen die
verfügbare Seitenzahl nicht aus. Zentrale Inhalte fehlen (z.B.
Benutzerdoku, Screenshots, Code-Beispiele). Azubis scheinen
heutzutage richtig Geld zu verdienen, gemessen an bis zu 120 EUR
Stundensatz. Der Einsatz von in den Unternehmen etablierten
Technologien wird nicht begründet, sondern einfach hingenommen.
Jeder Prüfer sollte sich mit den Details der Plattformen der
Prüflinge auskennen. Das kann man jawohl erwarten. Es werden
offensichtlich am Markt verfügbare Softwareprodukte (schlecht)
nachprogrammiert. Der Projektablauf ist in sich nicht stimmig (z.B.
angeblich agil entwickelt, aber riesiges Klassendiagramm vorab
erstellt). Bei Code Reviews kommt seltsamerweise nie etwas heraus.
Der Azubi-Code ist anscheinend immer perfekt. Highlights "Der
Objektkatalog in Visual Studio reicht als Entwicklerdoku."
Projekttitel über 3 Zeilen (!) in der Kopfzeile. Suche ",", ersetze
durch "". Die Entwicklerdoku ist eine Ansammlung von Regeln für die
Formulierung von Commit-Nachrichten. Eine hochmathematische
Amortisationsrechnung mit Formeln über eine ganze Seite (hätte auf
3 Zeilen reduziert werden können). "Ich habe das
Open-Closed-Prinzip umgesetzt. Weiß aber nicht wie." Der gesamte
Programmcode war auf Englisch, aber die zentrale Entität war auf
Deutsch benannt. Links Permalink zu dieser Podcast-Episode RSS-Feed
des Podcasts Verwendung von fremden Vorlagen für die
Projektdokumentation Verdacht auf Täuschungsversuch! Was nun? Warum
ein sprechender Kurztitel für das Abschlussprojekt sinnvoll ist Ist
die Projektdokumentation Teil der Bearbeitungszeit des
IHK-Abschlussprojekts? SOLID (object-oriented design) Weitere Infos
zur ProjektdokumentationDu 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! Zusammenfassung Erfahrungen aus den
Prüfungen 2016 Bei meinen Prüfungen im Sommer 2016 habe ich viele
Projektdokumentationen gelesen, deren Schwächen sich wiederholt
haben. Daraus ergeben sich konkrete Hinweise für deine
Abschlussarbeit als Fachinformatiker:in Anwendungsentwicklung. Im
damals beschriebenen Teil A entfielen 50 Prozent der Note auf die
Dokumentation; die übrigen 50 Prozent ergaben sich aus
Projektpräsentation und Fachgespräch zusammen. Eigene Texte und
belegte Quellen Wenn du fremde Sätze oder Absätze übernimmst, musst
du die Quellen sauber angeben. Übernommene Inhalte ohne
Quellenbeleg sind Plagiate, die zu Punktabzug und in schweren
Fällen zum Nichtbestehen führen können. Auch die Person, deren
Arbeit kopiert wurde, kann dadurch Schwierigkeiten bekommen.
Prüfer:innen kennen öffentlich verfügbare Beispiele und können nach
auffälligen Textstellen suchen. An den Berufsschulen, mit denen ich
zusammenarbeite, kamen bereits Plagiatsscanner zum Einsatz. Solche
Programme erkennen auch Texte, bei denen einzelne Wörter ersetzt
oder Sätze umgestellt wurden. Formuliere die Inhalte deiner
Dokumentation selbst. Das gilt ebenso für allgemeine Kapitel, etwa
zur Kostenplanung oder zur Amortisationsrechnung. Vorgaben deiner
IHK Erkundige dich bei deiner IHK, welche Regeln für deine
Projektarbeit gelten. Bei meiner IHK gehörte das Schreiben der
Projektdokumentation damals nicht zu den vorgesehenen 70
Projektstunden für die Anwendungsentwicklung beziehungsweise den 35
Stunden in anderen IT-Berufen. Andere IHKs handhabten das anders.
Kläre deshalb, wie viel Zeit du für deine Dokumentation einplanen
darfst. Für den Umfang waren bei meiner IHK höchstens 15 Seiten
Fließtext und 25 Seiten Anhang vorgesehen. Einige eingereichte
Arbeiten blieben deutlich darunter; eine bestand aus zwölf Seiten
ohne Anhang. Dabei fehlten Inhalte, die für die Bewertung relevant
waren. Schöpfe den erlaubten Rahmen mit passenden Inhalten aus und
halte die Grenzen deiner IHK genau ein. Ergebnisse deines Projekts
zeigen Damit ich deine Arbeit bewerten kann, brauche ich konkrete
Einblicke in das entwickelte Programm. Zu den häufig fehlenden
Inhalten gehörten: eine Dokumentation für Benutzer:innen,
Screenshots der Anwendung, Codebeispiele, Diagramme und weitere
Artefakte aus dem Projekt. Screenshots helfen dabei, Beschreibungen
der Oberfläche nachzuvollziehen. Wenn du etwa über einen Button
oder die Bedienbarkeit schreibst, sollte sichtbar sein, worauf du
dich beziehst. Anhand der beigefügten Ergebnisse lässt sich
außerdem besser erkennen, welche Software du erstellt hast. Kosten
nachvollziehbar berechnen Für die Kostenrechnung brauchst du
realistische Stundensätze, deren Herkunft du erklären kannst. In
einer Arbeit wurden beispielsweise 120 Euro pro Stunde für einen
IT-Azubi angesetzt, ohne dass sich dieser Wert im Fachgespräch
begründen ließ. Auch sehr niedrige Ansätze wie 3,50 Euro pro Stunde
habe ich gesehen. Sprich mit dem Rechnungswesen oder deiner
Führungskraft über einen passenden Wert. Halte die Rechnung
verständlich: Eine Amortisationsrechnung lässt sich mit
überschaubaren Rechenschritten darstellen, wenn die zugrunde
liegenden Werte klar sind. Eine Seite voller komplizierter Formeln
erschwert das Lesen, wenn sich dieselbe Rechnung kurz ausdrücken
lässt. Technische Entscheidungen begründen Wenn du eine
Programmiersprache oder ein Framework auswählst, beschreibe, warum
es zu deinem Projekt passt. Auch Technologien, die dein
Ausbildungsbetrieb regelmäßig einsetzt, brauchen einen
nachvollziehbaren Bezug zu den Anforderungen. Erkläre
betriebsinterne Plattformen und fachliche Besonderheiten so, dass
Prüfer:innen dein Problem und die gewählte Lösung verstehen können.
Ich kann beispielsweise allgemeine Kenntnisse zur
Objektorientierung mitbringen, während mir Details deiner internen
Systeme oder deiner Branche erst durch deine Beschreibung
zugänglich werden. Vorhandene Software prüfen Bevor du eine eigene
Lösung entwickelst, prüfe verfügbare Produkte. Gerade für Aufgaben
wie Zeiterfassung oder Projektverwaltung gibt es bereits Software
am Markt, teilweise kostenlos als Open Source. Dein Projekt soll
wirtschaftlich sinnvoll sein und deinem Ausbildungsbetrieb
weiterhelfen. Eine pauschale Aussage über spezielle Anforderungen
reicht als Grund für eine Eigenentwicklung nicht aus. Zeige
konkret, welche Anforderungen vorhandene Produkte erfüllen und wo
Lücken bestehen. Dafür kann eine Nutzwertanalyse geeignet sein, in
der du verfügbare Lösungen mit einer Eigenentwicklung vergleichst
und deine Entscheidung belegst. Den tatsächlichen Projektablauf
beschreiben Deine Dokumentation muss zu dem passen, was du gemacht
hast. Bei einigen Arbeiten wurde ein agiles Vorgehen behauptet,
während der beschriebene Ablauf mit einer langen vorgelagerten
Analyse- und Entwurfsphase einem Wasserfallmodell entsprach. Wähle
die Kapitel deshalb passend zu deinem eigenen Projekt. Wenn du ein
Code-Review dokumentierst, solltest du erläutern können, wer deinen
Code geprüft hat, wie die Person dabei vorgegangen ist und welches
Feedback daraus entstand. Im Fachgespräch frage ich nach solchen
Angaben. Beschreibe durchgeführte Schritte und ihre Ergebnisse so
konkret, dass du sie erklären kannst.
Entwickler:innen-Dokumentation und Form Aus kommentiertem Code
erzeugte Dokumente, etwa mit Javadoc oder XML-Kommentaren in C#,
habe ich als Entwickler:innen-Dokumentation akzeptiert. Ein
automatisch gefüllter Objektkatalog in Visual Studio enthält
dagegen allein durch das Schreiben von Klassen noch keine
entsprechende zusätzliche Dokumentationsarbeit. Regeln für
Commit-Nachrichten beschreiben ebenfalls etwas anderes als die
entwickelte Software. Achte beim fertigen Dokument auch auf die
Lesbarkeit: Verwende einen kurzen Projekttitel für die Kopfzeile,
damit er dort übersichtlich bleibt. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.