stefan.macke

Rate mal!

Vergessene Zeilen sind meiner Erfahrung nach leider Standard. Macht das Korrigieren nicht gerade leichter. :-/ Von daher ist der Tipp mit dem Schmierzettel sehr gut! Ansonsten würde ich niemals Zeilennummern nutzen. Das macht es nur noch unübersichtlicher und vor allem deutlich aufwendiger in der knappen Prüfungszeit. Einfach ein Sternchen an die betreffende Stelle und den fehlenden Code unten drunter schreiben. In einigen Prüfungen musste ich mir dann allerdings den Code mit *1 bis *9 selbst zusammenbasteln ;-) Von daher hier nochmal der Hinweis auf den Schmierzettel!

Wenn dein Unternehmen das so handhabt, würde ich mir ein anderes suchen. Auszubildende sollen ausgebildet und nicht als fertige, billige Arbeitskräfte ausgebeutet werden. Ja, das wäre sinnvoll, wenn du wirklich in die IT willst. Das hängt stark vom Studiengang ab und lässt sich nicht verallgemeinern. Wirtschaftsinformatiker machen z.B. (auch wieder je nach Hochschule unterschiedlich) "nur" ein bisschen Mathe und Statistik, haben dafür aber einen hohen BWL-Anteil. Da hast du dir aber auch gleich den absoluten Klopper rausgesucht. Wie der Name schon sagt, handelt es sich bei theoretischer Informatik um reine Theorie. Und das ist halt Mathe. Es gibt aber auch noch angewandte Informatik, Medizininformatik, Medieninformatik und und und... Dann solltest du definitiv nicht dort anfangen, sondern dein eigentliches Ziel verfolgen und Informatik anstreben. Für dich ist noch nichts verbaut. Du bist jung und weißt was du willst. Und wenn die Suche ein Jahr länger dauert, dann studier halt erstmal was in die Richtung. Wenn dir das nicht gefällt, hast du wenigstens für die nächsten Bewerbungen gezeigt, dass du willst.

Die Frage nach der Zeit für die Erstellung der Projektdokumentation lässt sich leider nicht allgemeingültig beantworten. Jede IHK dreht ihr eigenes Ding (siehe auch Ist die Projektdokumentation Teil der Bearbeitungszeit des IHK-Abschlussprojekts?). Deine Quelle liest sich stark nach FISI. Um auf Nummer sicher zu gehen, ruf doch deine IHK an! Nur dort bekommst du eine verbindliche Aussage für deinen Ausbildungsberuf. Im Zweifel würde ich einfach ein paar Stunden für die Projektdokumentation einplanen. Das war in den Dokus, die ich bislang gelesen habe, fast immer der Fall.

Aus meiner Sicht gehört eine Kostenplanung mit Amortisationsrechnung zu jedem Abschlussprojekt. Das zeigt deine kaufmännischen Fähigkeiten.

Wer soll den die Projektbeschreibung übernehmen? Es handelt sich hierbei doch um einen für jedes Projekt individuellen Text. Oder verstehe ich dich gerade irgendwie falsch?

Na klar! Gerne auch mit interessanten (!) Quellcodebeispielen

Alles was du beschrieben hast ist deine Geschäftslogik Deine Domäne ist das Erstellen von Berichtsheften!

Es geht um die Logik deiner Domäne. MVC ist gut und schön, aber das wird in jedem Webprojekt verwendet. Welche Logik ist für dein Projekt individuell? Diese Logik beschreibt deine Domäne. Beispiele: Versicherung: Berechnung der Beiträge, Bewertung des Risikos Autovermietung: Berechnung des Mietpreises, Empfehlung von passenden Autos Shopsystem: Empfehlung von Produkten, Rabattberechnung

Das darf in den Fließtext. Aber ist das auch sinnvoll? Das wird ja bestimmt viel Platz wegnehmen, der dir dann für den Text fehlt. Füll den wertvollen Platz besser mit wichtigen Inhalten und pack das Diagramm in den Anhang. Ich persönlich ziehe z.B. bei der Bewertung der Dokumentationen alle Grafiken, Tabellen usw. größer 1/2 Seite von der Seitenzahl ab.

Das kann ich nur bestätigen! Unbedingt zu Beginn der Dokumentation alles zum Verständnis Notwendige erklären. Zur Not (wenn du im Fließtext zu wenig Platz hast) packst du es mit einer deutlichen Referenz in der Einleitung in den Anhang. Und lass mal jemanden drüberlesen, der den Kontext nicht hat (also vielleicht einen unbeteiligten Kollegen oder noch besser einen betriebsfremden Mitschüler) und frag, ob die Inhalte verständlich sind. Einer meiner Hauptkritikpunkte an Dokumentationen ist, dass das Thema unverständlich erklärt wird. Da frage ich mich teilweise noch nach dem Lesen der gesamten Doku, was überhaupt der Sinn des Projekts war.

Ich würde es auch übernehmen. Die Arbeit, die du dir für den Antrag gemacht hast, soll ja nicht umsonst gewesen sein Es handelt sich dabei auch nicht um ein Plagiat, da du den Text selbst formuliert hast. Du willst keinen Preis für die blumigste Prosa gewinnen, sondern fachliche Inhalte zielgerichtet rüberbringen. Und wenn du für den Antrag schon eine kurze, präzise Beschreibung des Problems gefunden hast, dann kannst du sie auch in der Dokumentation wiederverwenden.

Ok, das ist gut zu wissen. Im Zweifel würde ich den Prüfern allerdings nicht meine Lebensgeschichte erzählen (oder noch schlimmer die des Unternehmens), sondern den wertvollen Platz für bewertbare (!) Inhalte nutzen. Die Ich-Form geht allerdings meiner Meinung nach absolut nicht. Wir schreiben ja keinen Aufsatz, sondern eine technische Dokumentation. Und die muss sachlich formuliert werden.

Das sehe ich anders. "Abweichungen vom Projektantrag" sind meiner Meinung nach Abweichungen, die sich zwischen Antrag und Umsetzung ergeben haben (z.B. der Kunde will jetzt doch einen anderen Server als ursprünglich gedacht) und dazu führen, dass das umgesetzte Projekt im Vergleich zum Antrag inhaltlich anders ablief. Diese Information würde ich direkt zu Beginn der Dokumentation platzieren. Zusätzlich ist ein Soll-/Ist-Vergleich der Zeitplanung sinnvoll, der am Ende der Dokumentation durchgeführt wird. Hier sind ggfs. ein paar Stunden verschoben, aber die grundsätzlichen Projektinhalte sind gleich geblieben.

...und das kann man auch gar nicht! Wenn wir uns kurz an die Definition erinnern: Erfahrene Entwickler skizzieren ein Tabellenmodell sicherlich gleich in der dritten Normalform runter. Aber gerade als Anfänger würde ich die drei Normalformen der Reihe nach durchgehen, damit nichts vergessen/übersehen wird. Dein Problem mit der Modellierung lässt sich wohl eher lösen, indem du dem Prozess der Normalisierung strikt folgst, anstatt Schritte zu überspringen. Später bekommst du dann einen Blick dafür, wie du dir die expliziten Einzelschritte sparen kannst.

Wenn du die Änderung sauber begründest, sollte das kein Problem sein. Außer natürlich die Funktion war die zentrale Funktionalität deines Projekts. Dann hast du leider falsch geplant.

Bitte nicht! Das interessiert niemanden und ist auch noch in der Ich-Form geschrieben. Das geht gar nicht. Im Zweifel komplett weglassen und stattdessen sinnvolle - technische - Inhalte einbauen, die auch bewertet werden können.

Ich kann meinen Vorrednern nur zustimmen. Eine wichtige Ergänzung noch: Du solltest alles, was du in deinem Abschlussprojekt verwendet hast (Sprachfeatures, Frameworks usw.), zu 100% verstanden haben und erklären können. Das sind beliebte Fragen im Fachgespräch.

Da stimme ich zu: Frag deinen zukünftigen Arbeitgeber. Allerdings wundert mich, dass du das noch nicht weißt. Was hat man dir denn beim Bewerbungsgespräch über deine nächsten drei Jahre erzählt? Nichtmal, womit du täglich arbeiten wirst? Ansonsten kann ich nur wiederholen: Du musst für eine Ausbildung nicht programmieren können. Es wird niemand böse sein, wenn du es kannst, aber es sollte keine Voraussetzung für die Ausbildung sein. Hierzu kann ich nun endlich auch auf den Podcast verweisen! Häufige Fragen im Forum - Fachinformatiker-Podcast #1

Wenn du die wichtigsten Phasen deines Projekts eigentlich agil entwickelst, warum nennst du es dann Wasserfall? Welchen Vorteil hast du davon? Welche Unternehmensvorgaben sprechen dafür? Bzw. was hat dein Unternehmen gegen ein agiles Vorgehen? Ich würde den letzten Schritt gehen und das gesamte Projekt agil entwickeln. Du nutzt offensichtlich die Vorteile der agilen Herangehensweise, aber wagst nicht den letzten Schritt. Mit diesem Mischmasch wirst du dir in der Prüfung eher Probleme einhandeln, als wenn du einfach klar Stellung beziehst. Aber auch wenn du letztlich doch deine Mischung anwendest: Natürlich kannst du auch nur einzelne Phasen deines Projektes agil entwickeln. Das sehe ich sogar recht häufig in den Projekten. Wenn du das sauber begründest (z.B. Qualitätsgewinn, bessere Erfüllung der Anforderungen, Zeitersparnis), ist das kein Problem.

So sieht eigentlich jede IHK-Doku aus! Also dürfte das passen.

Was war denn der Grund für die Neuentwicklung? Beispiele: Undurchsichtiger Code -> Zeitersparnis bei der Weiterentwicklung -> Kostenersparnis -> Amortisation Neue/zusätzliche Plattform -> Mehr Kunden erreichen -> Mehr Umsatz -> Amortisation Performanceoptimierung -> Zeitersparnis -> Kostenersparnis -> Amortisation

Das ist der springende Punkt! Projekte verlaufen nicht immer wie geplant. Wenn du deine Entscheidung verständlich darlegst und sauber begründest, sollte das kein Problem sein.

Oh sorry, ich war gedanklich bei der Präsentation und nicht bei der Dokumentation! Da solltest du natürlich eine vernünftige Kopf-/Fußzeile verwenden. In den meisten IHK-Dokus, die ich gelesen habe, aber auch in Haus- oder Bachelorarbeiten wird das Unternehmens- bzw. Hochschullogo in der Kopfzeile verwendet. Meiner Meinung nach ist das völlig in Ordnung und vielfach sogar gewünscht.

Grundsätzlich finde ich die Beschreibung gut. Ich würde das allerdings nicht als einen "Namen" bezeichnen, sondern als Bezeichnung oder Titel. Ich würde mir auf jeden Fall noch einen Kurznamen dazu ausdenken. Das ist deutlich einfacher bei der Kommunikation und auch für die Projektdoku/-präsi. Ein knackiger Name wäre gut, zur Not ein Akronym. Beispiele: ERP2SQL ERP-Online ERP-Shop ERP-Export