stefan.macke

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.

Ich bin zufällig selbst Softwarearchitekt und bin für die Auswahl von Frameworks und Programmiersprachen zuständig, erarbeite Coding-Conventions und koordiniere die systemübergreifende Kommunikation. Also einfach alles, was über einzelne Projekte hinausgeht und das System als Ganzes betrifft. Oder anders gesagt: Alle Dinge, die später nur schwierig änderbar sind. Ich habe Software-Engineering studiert und programmiere auch noch täglich. Ich denke, das ist ein wichtiger Bestandteil meiner Aufgabe, da ich nur so die Vorgaben, die ich selbst mache, auch anwenden und damit für die Praxis erproben kann. Alles andere wäre Arbeit im "Elfenbeinturm". Ich würde einen Softwarearchitekten auch nicht "über" den Entwicklern sehen. Genau wie Projektleiter, die halt die organisatorischen Dinge in Projekten klären, aber meist auch keine Weisungsbefugnis haben, muss es eben auch technisch Informierte geben, die das Gesamtsystem im Blick haben und für eine geordnete Softwareentwicklung sorgen. Eine spezielle Weiterbildung habe ich nicht absolviert, aber es gibt einige Zertifizierungen für Softwarearchitekten, z.B. hier: http://www.isaqb.org/

Warum das denn? Webprojekte machen heutzutage gefühlt die Mehrzahl der Abschlussprojekte aus. Und man kann alles zeigen, was für den Beruf interessant ist: Datenbank, Oberfläche, Logik.

Aber warum solltest du das tun? Damit verschenkst du doch nur wertvolle Projektzeit. Falls es am Ende kein "sehr gut" wird, wirst du dich immer fragen, ob es vielleicht mit 70h geklappt hätte. Zwei Stunden bekommst du immer verteilt!