stefan.macke

Es würde sehr helfen, wenn du uns deinen Ausbildungsberuf verrätst, da GA1 für jeden Beruf unterschiedlich ist.

Die Programmiersprache ist völlig irrelevant bei der Bewertung des Projekts. Wichtig ist, dass du deine Auswahl sauber begründest und bei der Entwicklung professionell vorgehst. Also bitte nicht "mein Chef wollte das so" und "mal eben runterscripten". Beides verbinde ich aus dem Bauch heraus mit der PowerShell. Du kannst mit der PowerShell genau so sauber oder dreckig entwickeln wie in jeder anderen Sprache und dank .NET als Basis wirst du vielleicht sogar Objektorientierung einsetzen können. Strukturiere deine Arbeit mit den üblichen Methoden (z.B. UML), teste deine Anwendung vernünftig (z.B. mit Pester), dokumentiere deine Lösung (z.B. mit doc-comments) und wende auch sonst einfach die üblichen Verfahren der professionellen Softwareentwicklung an. Dann sollte deinem Projekt nichts im Wege stehen. Für die Auswahl der Sprache könntest du dann z.B. noch eine Nutzwertanalyse (PS vs. Go vs. C#) erstellen, um alle Zweifel an deiner Entscheidung auszuräumen. Dabei könntest du dann z.B. "eigene Erfahrung" als Kriterium hoch gewichten.

Nein, falsch verstanden. Die Kardinalitäten sind semantisch natürlich unterschiedlich! Aber die technische Umsetzung von 1:1 und 1:n ist gleich: Fremdschlüssel in einer Tabelle verweisen auf die zugehörigen Datensätze der anderen Tabelle. Bei m:n wird dafür eine Zwischentabelle benötigt. Beispiel 1:1: Benutzer / Login. Ob du die LoginID in die Benutzer-Tabelle oder die Benutzer-ID in die Login-Tabelle packst, ist egal und kann frei entschieden werden, da es jeweils nur eine zugeordnete ID geben kann und keine multiplen Werte auftreten können. Beispiel 1:n: Artikel / Artikelgruppe. Die Artikelgruppe-ID muss hier in die Artikel-Tabelle eingetragen werden, da es ansonsten multiple Werte für die Artikel-ID in der Artikelgruppe-Tabelle gäbe, was gegen die 1. Normalform verstößt. Beispiel m:n: Artikel / Bestellung. Es ist eine neue Tabelle mit Artikel-ID und Bestellung-ID nötig, in die mehrere Kombinationen eingetragen werden können, da es ansonsten auf beiden Seiten multiple Werte geben könnte.

Ich frage mich die ganze Zeit, was denn wohl ein "logisches" Datenbankmodell sein soll. Meinst du vielleicht ein relationales Modell? Falls ja: Selbstverständlich darfst du 1:1-Beziehungen in einem relationalen Datenbankmodell benutzen. Sie werden exakt so modelliert wie 1:N-Beziehungen, nur dass die Platzierung des Fremdschlüssels frei wählbar ist, während er bei 1:N-Beziehungen immer in der N-Tabelle abgelegt werden muss.

Die "Alternative" wäre in dem Fall einfach, alles beim alten zu belassen, also z.B. den Prozess weiterhin auf Papier durchzuführen. Es gibt ja durchaus Projekte, die auf den ersten Blick total sinnvoll scheinen, weil sie "alte" Prozesse digitalisieren. Aber wenn der Prozess nur einmal im Jahr läuft und die Entwicklung sich erst nach 10 Jahren amortisiert, lässt man das Projekt wohl besser bleiben. Genau so eine Analyse würde ich in der Dokumentation erwarten, wenn es um ein Produkt geht, das für Endkunden gebaut wird. Und das habe ich auch schon mehrfach genau so gelesen. Ob diese Analyse in der Realität auch vom Entwickler gemacht würde, sei dahingestellt. Im Rahmen des Abschlussprojekts würde ich das zu den kaufmännischen Skills zählen, die demonstriert werden sollten. Das stimmt. In der Realität ist es aber meist schwieriger, da die Azubis z.B. Erweiterungen für bestehende Anwendungen bauen und kein Standalone-Programm. Und da muss man dann schon recht gut argumentieren und rechnen und vor allem nochmal darüber nachdenken, ob das Projekt wirklich sinnvoll ist. Alternativ kommt dann meist eine Betrachtung der nicht-monetären Faktoren ins Spiel, weil einzelne Features sich nur schwer in zusätzliche Verkäufe umrechnen lassen. Wir achten in unserem Ausschuss immer auf die Wirtschaftlichkeit und häufig ergeben sich auch Fragen für das Fachgespräch daraus, weil sie von vielen Entwicklern vernachlässigt wird.

Projekte von Informatikkaufleuten sollten nicht allzu programmierlastig sein. Du hast nur 35h zur Verfügung und dein Beruf hat halt auch einen anderen Schwerpunkt. Es sollte eher um die kaufmännischen Anteile gehen, also z.B. die Bewertung und Auswahl von zu beschaffender Software/Hardware, Angebots-/Preiskalkulation, Amortisationsrechnung usw. Genaueres können wir aber nur sagen, wenn du mal einen Antrag schreibst und ihn hier einstellst. Der Antrag sollte so umfangreich sein, dass ein unbeteiligter Dritter mit ausreichend IT-Knowhow dein Projekt und insb. deine Eigenleistung verstehen kann. Die Prüfer müssen auf Basis des Antrags bewerten können, ob die fachliche Tiefe ausreichend für ein Abschlussprojekt ist und du alle geforderten Kenntnisse deines Berufs zeigen kannst.

Das kommt auf deine IHK an. Ich würde allerdings vermuten, dass es hier keine Vorgaben gibt. Du musst als Prüfling die Wahl treffen, welche Artefakte deine Arbeit am besten darstellen. Wenn du nur 15 Seiten Anhang hast und 7 davon für ein Pflichtenheft "verbrätst", kannst du halt viele andere wichtige Inhalte nicht zeigen. Und ich würde das durchaus so nennen, wenn du Inhaltsverzeichnis, Deckblatt usw. des Pflichtenhefts auch mit anhängst. Die bieten dem Prüfer nämlich genau 0 Mehrwert. Also würde ich immer nur einen Auszug zeigen, nämlich die eigentlichen interessanten Inhalte, die deine Arbeit zeigen! Weil du dein Projekt vernünftig umsetzen sollst. Die Projektdokumentation ist ein Prüfungsartefakt, für das andere Anforderungen gelten. Hier gilt es, auf einer vorgegebenen Seitenzahl dein gesamtes Projekt bestmöglich darzustellen. Das stimmt so nicht ganz. Ein Pflichtenheft kann anstatt eines Projekts zur Abschlussprüfung erstellt werden. Wenn man sich aber für ein implementiertes Projekt entscheidet, kann das Pflichtenheft zu diesem Projekt Teil der Projektdokumentation werden. Sollte man sein Projekt allerdings z.B. agil umsetzen, passt ein Pflichtenheft evtl. nicht dazu. Daher ist ein Pflichten- und auch ein Lastenheft nicht zwingend erforderlich. Und selbst wenn man ein Pflichtenheft schreibt, gibt es keine Pflicht, dieses komplett der Dokumentation anzuhängen. Außer natürlich, die konkrete IHK fordert das so. Die Verordnung gibt 30 Minuten für die gesamte mündliche Prüfung vor (Präsentation und Fachgespräch). Wie die Prüfungsausschüsse die Zeit aufteilen ist ihnen überlassen. Die meisten teilen aber 50/50, also jeweils 15 Minuten für beide Teile. Das wäre z.B. ein wichtiges Artefakt, das du in der Dokumentation darstellen solltest. Einige IHKen haben in ihren Bewertungsschemas extra den Punkt Kunden-/Entwicklerdokumentation aufgeführt.