stefan.macke

Der Antrag fängt völlig aus dem Zusammenhang gerissen an. Es gibt keine verständliche Einleitung. Das Datenmodell ist trivial. Welche Artefakte werden erzeugt (z.B. ERM, Use-Cases, Pflichtenheft)? Wie wird ein methodisches Vorgehen bei der Softwareentwicklung sichergestellt? Die Dokumentationsphase ist viel zu lang! Benutzer- und/oder Entwicklerdokumentation werden nicht eingeplant. Keinerlei Wirtschaftlichkeitsbetrachtung enthalten. Make-or-buy-Entscheidung wäre aufgrund der sehr allgemeinen Domäne (Netzwerkmonitoring) sinnvoll.

Das freut mich! Herzlichen Glückwunsch! Was hast du denn für eine Anwendung gebaut?

Wow! Tolles Ergebnis! Freut mich für dich. Herzlichen Glückwunsch. Bei welcher IHK bist du denn?

Naja, es ist schon ziemlich eindeutig, dass hier keine vernünftige Planung vorliegt: "Ich programmiere 32 Stunden lang irgendwas." Alle anderen Phasen sind super geplant (max. 7h lang), aber ausgerechnet der zentrale Part mit fast 50% der Projektzeit ist eine große Unbekannte...

Meine Frage wäre noch: Warum? Was erhoffst du dir von einem "coolen" Projekt? Willst du Eindruck beim Prüfungsausschuss machen (das wird schwierig)? Willst du deine technische Kompetenz demonstrieren (dann übernimm dich besser nicht)? Willst du einfach nur mehr Spaß bei der Arbeit haben (dann bring doch innovative Konzepte in alte Strukturen)? Ich habe häufig Prüflinge, die etwas "Cooles" machen wollen. Aber oft endet das dann in halbfertigen Projekten, deren Implementierung sie selbst nicht verstehen (das merkt man dann im Fachgespräch). Also gut überlegen, ob das Projekt (wirtschaftlich und technisch) sinnvoll ist und auch die notwendigen Fähigkeiten zur Umsetzung vorhanden sind. Als Ergänzung habe ich hier nochmal ausführlich über die Vor- und Nachteile von außergewöhnlichen Projektthemen geschrieben: Ausgefallene oder anspruchsvolle Themen beim Abschlussprojekt.

Nein, die Lösungen werden nicht offiziell vertrieben. Nur zum WiSo-Teil gibt es die Lösungen dazu, wenn du sie beim U-Form-Verlag kaufst.

Besser! Planst du irgendwelche Methodiken ein? ERM, UML, PAP, Mockups?

Mh, der Antrag wäre für mich so in Ordnung. DB, Logik, Frontend - alles drin. Artefakte genannt, Wirtschaftlichkeit betrachtet. Lediglich die 12h Dokumentation erscheinen mir recht lang (untergliedern, Kunden-/Entwicklerdoku?). Den Prüfern ist wohl nicht klar geworden, was du genau tun musst, um dein Ziel zu erreichen. Ich vermute, die Komplexität wird nicht deutlich. Kannst du die Problemstellung noch ausführlicher beschreiben, sodass man einen besseren Eindruck der tatsächlich zu implementierenden Module bekommt? Es könnte der Eindruck entstanden sein, dass du kaum etwas selbst programmieren musst und das System dir alles abnimmt.

Das hier fällt mir direkt auf: Es wird nicht deutlich, was DU eigentlich machst. Wirtschaftlichkeitsbetrachtung (z.B. Amortisation) fehlt. Dokumentationsphase (18h) ist viel zu lang. Ich empfehle max. 10h. 5h für einen PAP? Das muss ja ein Riesending sein. Entwicklungsphase (12h) weiter aufteilen. Es fehlt eine Kunden-/Entwicklerdokumentation. 10% Puffer sind viel zu viel. Ich empfehle ihn komplett zu streichen. Welche Programmiersprache/Plattform setzt du ein? Welchen Entwicklungsprozess verfolgst du? Insgesamt wird der Umfang deiner Leistung einfach nicht deutlich.

Liest sich grundsätzlich schonmal gut. Zwei Sachen fallen mir auf: Die längeren Implementierungsphasen (16 und 15 Stunden) würde ich weiter runterbrechen. Wie dokumentierst du ein methodisches Vorgehen bei der Softwareentwicklung? Du nennst keine Artefakte (ERM, UML usw.)

- Dokumentationsphase ist zu lang (Empfehlung ca. 10h) und nicht runtergebrochen (Kunden-/Entwicklerdoku?). - Entwicklungsphase Front-End ist nicht runtergebrochen. - Wirtschaftlichkeitsbetrachtung fehlt. - Es ist kein methodisches Vorgehen bei der Entwicklung erkennbar (keine Artefakte wie Pflichtenheft, ERM, UML).

+1 von mir! In unserem Prüfungssystem gibt es z.B. explizit diesen Ablehnungsgrund:

Danke für den Tipp! http://www.epublizisten.de/2012/06/ann-katrin-siedenburg-das-kleine-einmaleins-der-typografie/ http://daswebdesignblog.de/ein-bisschen-was-ueber-schriften/949.html http://edoc.hu-berlin.de/e_rzm/18/bynum/7.pdf

Vielleicht unter den Prüfern, aber sicherlich nicht unter den Typographen Meine Aussage bezog sich auch auf Schriften im Allgemeinen. Bei der IHK-Prüfung hat die IHK das Sagen. Wenn die (fälschlicherweise) Arial will, soll sie Arial bekommen.

Da muss ich leider vehement widersprechen! Serifenschriften sind für Fließtext Pflichtprogramm. Sie belasten das Auge nicht, sondern unterstützen es! https://de.wikipedia.org/wiki/Schriftart

Coole Sache. Kannte ich bislang noch nicht. Wurde mit SQL:2003 eingeführt. Aber leider haben viele Datenbanken das wohl noch nicht implementiert. Allerdings ist das vielleicht (!) auch nur eine Nischenproblematik und es ist daher nicht ganz so schlimm, wenn das Feature fehlt Aber falls eine Datenbank damit wirbt, den Standard einzuhalten, muss sie das natürlich anbieten.

+1 von mir! Das Teil habe ich zuhause. Ist eine tolle Alternative, wenn man keinen höhenverstellbaren Schreibtisch hat oder haben möchte.

Hast du vielleicht mal ein Beispiel, was du genau machen möchtest bzw. von den Datenbanken erwartest?

So ist es. Und nur darauf würde ich mich verlassen. Aber ungefähre Termine kann man z.B. hier sehen: http://www.hannover.ihk.de/fileadmin/data/Dokumente/Themen/Aus-_und_Weiterbildung/Ausbildung/Fachinformatiker_Anwendungsentwicklung.pdf

Um es kurz zu machen: Wenn du kurz vor deinem Projekt das erste Mal "richtig" programmierst, wird es sehr schwer für dich. Warum hast du denn bislang nicht Eigeninitiative gezeigt und selbstständig programmieren gelernt? Oder dachtest du, Anwendungsentwickler müssen nicht zwangsläufig entwickeln? Und warum hilft dir die Schule nicht? Dafür ist sie doch da. Nun ja, wie bekommst du die Kuh vom Eis? Gute Frage. Du kannst anstatt eines Programmierprojekts auch ein Pflichtenheft erstellen (siehe §15, Abs. 2, 1b): Dann musst du wenigstens nicht programmieren (wenn du das tatsächlich nicht kannst). Aber methodisches Vorgehen wird trotzdem verlangt. Heißt: Anforderungen aufnehmen und formulieren, Software/Datenbank/Oberfläche modellieren, Kalkulation und Amortisationsrechnung usw. (siehe verschiedene Threads in diesem Forum). Alternativ verlängerst du deine Ausbildungszeit und lernst auf eigene Faust programmieren - z.B. mit zahlreichen Online-Kursen oder einfach klassischer harter Arbeit. Das Projekt muss übrigens ein "echtes" Projekt aus dem Betrieb sein. Das Forum nach Projektideen zu fragen ist daher nicht sehr sinnvoll. Du kannst dir natürlich Anregungen holen, aber um eine Umsetzung in der Praxis wirst du nicht herumkommen.

Liest sich erstmal gut! Folgendes fällt mir auf: Mir fehlt die Amortisationsbetrachtung. Dass du (wahrscheinlich) mit PHP arbeitest, wird nur deutlich, wenn man TYPO3 kennt. Puffer würde ich komplett rausnehmen. Gibt es keine Kundendokumentation?

Ich habe ein Beispiel für ein Projekt mit fehlender fachlicher Tiefe: Die Entwicklung eines HTML-Formulars mit 10 Zeilen JavaScript (kein Witz, habe ich schon gesehen). 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 (meiner Meinung nach) eine Betrachtung der Kosten und Amortisation, der Einsatz von Modellierungs- oder Dokumentationsmethoden (z.B. ERM, UML, EPK, Mockups), das Erstellen sinnvoller Dokumentationen (z.B. Kunde, Betrieb, Entwickler), das planvolle Vorgehen bei der Projektumsetzung (z.B. Projektplan, Iterationsplanung, Gantt), eine gute Qualitätssicherung (z.B. Unit-Tests, Abnahmeprotokoll) usw. Als Daumenregel für Anwendungsentwickler führe ich immer ein "klassisches" Webprojekt an: kleine Datenbank (ca. 5 Tabellen), ein bisschen Logik, Frontend drüber. Da kann man das volle Spektrum der Entwicklungstätigkeiten zeigen.

Man muss allerdings genau schauen, um welche Dokumentation es geht. Ist die reine Projektdokumentation (also die Prüfungsleistung) gemeint oder sind auch die "echten" Dokumentationen (Kunde, Betrieb, Entwickler usw.) mit drin. In letzterem Fall würde ich 8 Stunden sogar als zu wenig ansehen. Für die Projektdokumentation halte ich 7-8 Stunden für realistisch.

Die Verordnung (§15, Abs. 2, 1) sagt: Warum es trotzdem nicht ratsam ist, weniger Zeit zu verplanen, habe ich hier schonmal detailliert aufgeschrieben: Muss die Projektbearbeitungszeit (70 Stunden) wirklich genau eingehalten werden?

Es stimmt schon, dass man in der Praxis vielleicht am ehesten mit Datenbanken etwas anfangen kann. Allein, dass mit Access sogar eine Datenbank in der Office-Suite enthalten ist, sollte das schon deutlich machen Das Schöne an SQL ist, dass man diesen Standard auf jede (relationale) Datenbank anwenden kann, sodass man nicht an eine spezielle Implementierung gebunden ist. Ich könnte mir durchaus vorstellen, dass du über die Datenbanken einen guten Einstieg in die IT hinbekommst. Und auch für dich persönlich bieten die Kenntnisse vielleicht Vorteile, weil du selbst deine eigenen Daten damit organisieren kannst.