stefan.macke

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

Wenn du die anderen Inhalte (und meine Liste waren nur Beispiele! ) drauf hast, dann kannst du natürlich noch versuchen, die Programmieraufgaben vorzubereiten. Es stimmt, dass man (zumindest in den letzten Prüfungen) nicht mehr um sie herumkommt, da immer zwei Aufgaben drankamen. Ich kann mich @Blechdach nur anschließen: Such dir einen Online-Kurs und versuch es damit. Oder einfach ein gutes Buch. Einen "Geheimtipp" habe ich leider nicht Am besten wäre natürlich ein individuelles Feedback zu deinen Programmen. Aber ich lese heraus, dass du keine/n Ausbilder/in hast, der/die dir helfen kann!? Denn dafür ist er/sie ja da...

Kann ich leider nur bestätigen. Oftmals sind die Umschüler bei uns die schlechtesten Prüflinge. Und das hat weniger mit den Prüflingen, sondern mit den Betrieben zu tun.

Wenn dir ein Ausschuss Punkte abzieht, nur weil du das Logo "falsch" platziert hast, würde ich seine Kompetenz in Frage stellen. Es sollte vor allem um deinen Inhalt gehen und weniger um das Firmenlogo. Ich glaube, der Hintergrund ist vielmehr die grundsätzliche Foliengestaltung und ob du zusätzlich zum Logo noch Kopf- und Fußzeile mit unnötigem Inhalt nutzt und Platz für die wichtigen Dinge verschenkst. Ich persönlich würde niemals eine Kopf-/Fußzeile verwenden. Aber es gibt auch Prüfer, die gerade das gut finden (warum kann ich nicht nachvollziehen). Aber auch in letzterem Fall werden sie dir sicherlich nicht nur aufgrund des fehlenden Logos eine schlechtere Note gegeben. Entscheide dich einfach für einen Stil, der dir selbst gut gefällt und mit dem du sicher präsentieren kannst. Dann ist die Platzierung des Logos irrelevant. Und wenn du Pech hast und dein Stil gefällt dem Ausschuss nicht, dann ist das halt so. Man kann es nicht allen Leuten rechtmachen.

Das sehe ich etwas anders. Eine Programmiersprache kannst du in kurzer Zeit lernen, zu programmieren nicht. Genau das ist die Aufgabe der dreijährigen Ausbildung. Die richtige Denk- und Herangehensweise für die Problemlösung ist die zentrale Fähigkeit eines Anwendungsentwicklers. Die Sprache ist nur ein Mittel zu Zweck. Das hilft dir allerdings jetzt auch nicht weiter. Daher schlage ich vor, du versuchst so viele Probleme wie möglich für die Prüfung zu lösen. Und zwar nicht auf dem Papier, sondern in einer echten Sprache. Meiner Meinung nach kann man sich nicht durch stumpfes Lernen auf die Algorithmus-Aufgaben vorbereiten. Denn es geht hier nicht um Auswendiglernen, sondern um die Anwendung des Wissens. Allerdings halte ich es für unmöglich, das in einem Monat hinzubekommen. Daher ist eine alternative Empfehlung: Streich die Programmieraufgaben (die ohnehin sehr viel Zeit kosten) gedanklich und fokussiere dich auf die Dinge, die du tatsächlich auswendig lernen kannst. Es gibt noch so viele andere Themen, die du können musst (z.B. UML, Datenbanken, SQL, Projektmanagement). Die solltest du nicht zugunsten der Programmierung vernachlässigen!

Dass die Formulierungen vielleicht nicht zum "Standard" bei Berufsanfängern gehören, da stimme ich dir zu. Aber wer will denn eine Standardbewerbung schreiben? Und ich glaube, dass es auch einige Azubis gibt, die schon während der Ausbildung tolle Sachen für ihr Unternehmen umsetzen und das auch entsprechend "belegen" können. Wir stellen doch gerade junge Menschen ein, um frischen Wind und neue Ideen in die Betriebe zu bringen. Vielleicht wurde ja ein neues Framework eingeführt oder ein Tool etabliert. Das sind doch wichtige Leistungen, die auch "Anfänger" zum Unternehmenserfolg beitragen können. Unser automatisches Buildsystem hat z.B. ein Azubi umgesetzt. Ich würde daher empfehlen, die Leistungen mit aufzunehmen. Wenn es keine gibt, dann lässt man sie halt weg.