stefan.macke

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.

Darf ich mal fragen, was du eigentlich vorhast? Bist du ITler (z.B. FISI) und möchtest gerne in die Anwendungsentwicklung? Oder worauf willst du dich bewerben? Deine Beiträge lassen eher darauf schließen, dass du von der gesamten Materie keine Ahnung hast (das ist nicht böse gemeint). Auf welche Stelle möchtest du dich mit den selbst erlernten Grundlagen bewerben und welche Hoffnungen machst du dir?

Wie kommst du von Datenbanken auf XML? Das hat erstmal nichts miteinander zu tun. Höchstens, dass beides Daten enthält. Für den Zugriff auf (relationale) Datenbanken brauchst du XML nicht. Es gibt allerdings dokumentenorientierte Datenbanken wie MongoDB, die Daten nicht in Tabellen, sondern in strukturiertem Text ablegen. Dann aber nicht in XML, sondern in JSON.

Das sehe ich anders. ACID würde ich kaum als Grundlage bezeichnen. Um ein paar SELECT-Abfragen in mein Programm einzubauen, muss ich kein Transaktionskonzept erläutern können und noch weniger die Eigenschaften eines solchen kennen. Auch den Vorgang der Normalisierung muss ich nicht beherreschen, um die Daten abfragen zu können. Sicherlich ist es sinnvoll, zu verstehen, warum Daten überhaupt normalisiert abgelegt werden, aber einen JOIN kann ich auch ohne das Hintergrundwissen bauen. Ich vergleiche das jetzt mal mit der Polymorphie der Objektorientierung. Sicherlich muss ich das - irgendwann einmal - lernen. Aber wenn ich anfange zu programmieren, werde ich vielleicht doch zunächst mal eine if-Abfrage schreiben. Ich würde eher versuchen, zunächst einmal etwas Praktisches zu machen und dann (natürlich zeitnah) in die Theorie dahinter einzusteigen.

Als Empfehlung für Doku/Präsi: Verwende nicht zuviel Platz/Zeit auf die Erklärung des Gesamtprojekts. Erwähne soviel wie nötig und so wenig wie möglich zum Verständnis deines Projekts. Viele Prüflinge lassen sich ewig über das Gesamtprojekt aus und vernachlässigen dabei ihren eigenen Anteil. Aber um genau den geht es letztlich bei der Bewertung.

Ich würde empfehlen mit SQL anzufangen. Und zwar noch konkreter: mit SELECT. Das ist der Bereich, den ein Entwickler zu 90% (subjektiver Wert) bei seiner Arbeit braucht: Wie bekomme ich vorhandene Daten aus der Datenbank? Danach würde ich mir die Gegenrichtung anschauen: Daten in die Datenbank schreiben: INSERT, UPDATE, DELETE. Damit solltest du eine gute Grundlage für das Tagesgeschäft haben. Wenn du darüber hinaus noch selbst Datenbanken modellieren möchtest, setze dich zuerst mit den Entity-Relationship-Modellen auseinander, die Daten recht abstrakt modellieren. Im Anschluss daran kommt dann der Schritt in die relationale Welt mit dem Tabellenmodell. Und zu guter letzt kannst du dir dann die entsprechenden SQL-Befehle anschauen: CREATE, ALTER usw. So mache ich es mit meinen Azubis und Studenten und lasse sie währenddessen auch schon immer gleich die passenden IHK-Aufgaben bearbeiten, damit sie gleich ein Gefühl für die Fragen bekommen und den Sinn hinter dem Lernen sehen.