Hallo zusammen,

 

würde mich über eine kurze Einschätzung freuen, ob das eurer Meinung nach als Abschlussprojekt geeignet klingt.

In unserer Produktion werden Schleifscheiben vor dem Versand per Schablone bedruckt. Die Schablonen erstellt ein Plotter, der über einen PC mit einer Java-Anwendung gesteuert wird.
Alle für den Druck benötigten Kennzeichnungsdaten sind im ERP-System Microsoft Dynamics NAV 2017 hinterlegt. Diese liegen aktuell jedoch unstrukturiert vor und müssen je nach Kunde für den Druck unterschiedlich aufbereitet werden – sowohl inhaltlich (zusätzliche Angaben, spezielle Texte) als auch im Layout (Platzierung der Elemente auf der Scheibe).
Im Moment übertragen die Produktionsmitarbeiter diese Daten manuell aus NAV in die Plotter-Software, was Zeit kostet und fehleranfällig ist.
Die Projektidee ist, eine automatisierte Schnittstelle zu entwickeln, die nach Eingabe oder Scan der Fertigungsauftragsnummer alle relevanten Daten direkt aus NAV holt, entsprechend den kundenspezifischen Vorgaben aufbereitet und an die Plotter-Software übergibt.
Dazu müsste ich in NAV einen Webservice (SOAP) bereitstellen und in der Java-Anwendung einen passenden Client entwickeln, der die Daten verarbeitet.
Ziel wäre, dass die manuelle Eingabe komplett entfällt und die Schablonendaten – inhaltlich und layouttechnisch korrekt – automatisch bereitstehen.

Im Antrag würde ich das ganze auch noch "allgemeiner" formulieren, hier habe ich schon einige Lösungsansätze vorrausgedacht.

Vielen Dank und LG

 

 

Hey @Meitekinn😊

deine Projektidee klingt auf jeden Fall sehr sinnvoll wie ich finde, sie eignet sich gut als Abschlussprojekt. Du hast ein ganz konkretes Problem aus dem Produktionsalltag identifiziert: die manuelle und fehleranfällige Datenübertragung aus NAV in die Plotter-Software. Dass du hier eine automatisierte Schnittstelle entwickeln willst, die die Daten direkt aus NAV zieht, kundenspezifisch aufbereitet und dann an die Java-Anwendung übergibt, ist technisch anspruchsvoll und gleichzeitig mit echtem Mehrwert für den Betrieb verbunden.

Besonders gut ist, dass du sowohl die technische Umsetzung (SOAP-Webservice, Java-Client) als auch die fachliche Komplexität (unstrukturierte Daten, kundenspezifische Layouts und Inhalte) berücksichtigst. 

Wenn du das Ganze im Antrag noch etwas allgemeiner formulierst also z. B. mit Fokus auf Prozessoptimierung, Schnittstellenentwicklung und Automatisierung in der Produktion dann hast du ein rundes, gut begründetes Projekt, das sowohl inhaltlich als auch methodisch überzeugend ist.

Du kannst deinen Projektantrag gerne auch anonymisiert hier einstellen, sodass die Prüfer hier im Forum auch mal drüberschauen könnten wie z.B. @charmanta.

Liebe Grüße Audrey 😉

 

Bearbeitet 18. August18. Aug von CtrlAltAudrey

Welche Fachrichtung denn ?

vor 10 Minuten schrieb t1nk4bell:

Welche Fachrichtung denn ?

Steht im Titel, Anwendungsentwicklung FIAE. Oder verstehe ich das falsch

 

vor 49 Minuten schrieb Meitekinn:

Dazu müsste ich in NAV einen Webservice (SOAP) bereitstellen

technisch ok.
Aber für eine IHK Abschlußarbeite brauchst du zumindest mögliche angedachte Alternativen für eine Auswahl/Entscheidung

Selbst wenn es sinnlos erscheint, erwähne im Antrag auch REST oder direkten Zugriff auf SQL.
Bei der Erstellung der Doku schreibst du warum du dich gegen RESR etc, entschieden hast.

In Powershell sind alle drei Zugriffsarten keine 20 Zeilen lang.
Du musst also noch etwas "Füllmatrial" finden.

 

vor 28 Minuten schrieb CtrlAltAudrey:

Steht im Titel, Anwendungsentwicklung FIAE. Oder verstehe ich das falsch

Montagsmorgen Blindheit..... Danke dir 

Bearbeitet 18. August18. Aug von t1nk4bell

vor 39 Minuten schrieb hellerKopf:

Aber für eine IHK Abschlußarbeite brauchst du zumindest mögliche angedachte Alternativen für eine Auswahl/Entscheidung

Nicht zwingend für AE Projekte.

Bearbeitet 18. August18. Aug von Brapchu

Wenn er keine Alternativen erwähnt/untersucht sehe ich keinen Unterschied zu einem reinen Arbeitsauftrag.
Ist das denn so in der Prüfungsordnung hinterlegt? -> keine Entscheidung notwendig.

Bearbeitet 18. August18. Aug von hellerKopf

Hm, ich möchte es mal so sagen. Die Idee mag interessant klingen, aber mir fallen doch direkt ein paar Kritikpunkte ein.

a) Es handelt sich ja um ein Signierssystem, wenn ich es richtig verstanden habe. Das Problem was ich hier sehe ist, dass es im Industriebereich eine Reihe von Anwendungen schon fertig entwickelt gibt, die man an jedes ERP System direkt anbinden kann. Vermutlich würden Prüfer auch fragen, warum so etwas noch extra über so einen Umweg in Eigenentwicklung programmiert werden muss.

b) Auch ein ERP System besitzt normalerweise von Haus aus zahlreiche Anbindungsmöglichkeiten, um Fremdsysteme anzubinden (z.B. für Etikettendrucker). Ich wüsste jetzt nicht, was an dem Signiersystem derartig besonders sein soll, dass man es nicht direkt aus dem ERP System ansteuern kann.

c) Die Sache mit dem Arbeitsaufwand.- klingt nicht wirklich glaubwürdig. Ich habe auch Signiersysteme in der Produktion betreut, die nicht direkt am ERP System hingen. Okay, da ist man morgens mit dem USB Stick hingegangen, hat die Daten eingelesen, noch mal geschaut, ob das System in der Bahn läuft und danach lief die Produktion automatisch bis zum Ende weiter. (Hat normalerweise keine 20 Minuten gedauert).

Aber vielleicht ist das mit den Schleifscheiben ja was besonderes, vielleicht kannst Du uns noch mal genau erklären, warum das so umständlich gemacht werden muss und warum. man das Signiersystem nicht direkt an Eure ERP anbinden kann.

Ansonsten würde ich sagen, arbeite doch mal einen Projektantrag komplett aus und stelle den hier anonymisiert rein. Vielleicht klären sich dadurch auch schon ein paar Fragen und man kann einfacher nachvollziehen, worum es überhaupt geht. Ich muss zugeben, dass ich hier im Moment Verständnisprobleme habe.

Wichtig wäre dann auch mal zu wissen, wie sich der Arbeitsaufwand verteilt.

Den Punkt mit den Alternativen finde ich auch nicht gerade unwichtig. (s. Fragen oben).

vor 1 Stunde schrieb hellerKopf:

Wenn er keine Alternativen erwähnt/untersucht sehe ich keinen Unterschied zu einem reinen Arbeitsauftrag.

Bei AE Projekten ist einfach manchmal keine Betrachtung von Obskuren Alternativen möglich.

Du sollst halt eine Softwarelösung entwickeln.

Ich hab damals eine REST-API unseres Ticketsystems in eine Library angebunden und mit Unit Tests und ner simplen Test UI garniert.

Da war nix mit "Alternativen" und die waren bei all unseren Azubiprojekten im Betrieb für AE bis jetzt nicht nötig.

 

Hallo zusammen,

schon mal vielen Dank für all euer Feedback. Ich habe jetzt mal eine erste Version des Antrags verfasst, damit man sich ein besseres Bild machen kann. Ich würde mich sehr über weiteres Feedback freuen! Danke.

Projektantrag

1 Projektbezeichnung

Automatisierte Übertragung und Aufbereitung von Produktionsdaten zur Plottersteuerung.

 

1.1 Kurzform der Aufgabenstellung

Im Rahmen des Projekts soll ein automatisierter Prozess entwickelt werden, der Produktions- und Layoutdaten aus einer zentralen Datenquelle abruft, aufbereitet und ohne manuelle Eingaben in der Plotter-Software bereitstellt.
Nach Eingabe der Fertigungsauftragsnummer werden die relevanten Kennzeichnungsdaten aus der zentralen Datenquelle ermittelt, gefiltert und in ein strukturiertes Austauschformat (z. B. XML oder JSON) überführt. Dabei werden grundlegende Plausibilitätsprüfungen durchgeführt (z. B. Vollständigkeit von Pflichtfeldern). Anschließend werden die Daten an die bestehende Plotter-Software übergeben, die auf Basis der enthaltenen Layoutvorgaben die konkrete Platzierung der Elemente übernimmt.
Die bisher manuelle Datenerfassung durch Produktionsmitarbeitende entfällt vollständig.

 

1.2 Ist-Analyse

In der Produktion von Schleifscheiben werden vor der Auslieferung produkt- und kundenspezifische Kennzeichnungen auf die Scheiben aufgebracht.
Hierfür werden Schablonen mit einem Plotter erstellt, der über einen PC mit einer Java-Anwendung gesteuert wird.
Alle für den Druck erforderlichen Informationen, wie technische Produktdaten, Normhinweise, Textelemente und Layoutvorgaben, sind bereits in einer zentralen Datenbank hinterlegt.
Aktuell werden diese Daten jedoch manuell ausgedruckten Fertigungspapieren entnommen und von den Mitarbeitenden in die Eingabemaske der Java-Anwendung übertragen.
Je nach Kunde müssen zusätzliche Angaben ergänzt oder die Position einzelner Elemente angepasst werden.
Dieser Vorgang ist zeitaufwändig, fehleranfällig und birgt das Risiko fehlerhafter oder unvollständiger Kennzeichnungen.
Eine direkte technische Anbindung zwischen Datenbank und Plotter-Software existiert bislang nicht.

 

2 Zielsetzung / Sollkonzept

2.1 Ziel des Projekts

Ziel des Projekts ist die Entwicklung einer Lösung, die Produktions- und Layoutdaten nach Eingabe einer Fertigungsauftragsnummer automatisiert aus einer zentralen Datenquelle abruft, die relevanten Informationen aufbereitet und in einem für die bestehende Plotter-Software geeigneten Format bereitstellt. Die positionsgenaue Anwendung der Layoutvorgaben erfolgt anschließend innerhalb der vorhandenen Java-Anwendung.

Damit wird der bisherige Übertragungsprozess vollständig abgelöst und durch eine Lösung ersetzt, die eine schnellere Bearbeitung, eine geringere Fehlerquote und eine einheitliche Datenbasis sicherstellt. Die Umsetzung erfolgt unter Beachtung der internen Coding-Richtlinien und in modularer Struktur, sodass einzelne Komponenten bei Bedarf unabhängig voneinander erweitert oder angepasst werden können. Die im nächsten Abschnitt beschriebenen Anforderungen bilden dafür den umzusetzen­den Funktionsumfang.

 

2.2 Welche Anforderungen müssen erfüllt sein?

·         Automatischer Abruf aller kennzeichnungsrelevanten Daten anhand einer Fertigungsauftragsnummer; Zu Projektbeginn werden die möglichen Anbindungswege bewertet: Webservice (SOAP/REST), direkter Datenbankzugriff, Datei-Export.

·         Aufbereitung der Daten gemäß hinterlegter Layout- und Inhaltsvorgaben (z. B. Position, Reihenfolge, Schriftinformationen)

·         Übergabe der Daten an die Plotter-Software; unter Umständen in einem definierten, strukturierten Format (z. B. XML oder JSON)

·         Grundlegende Validierung der Daten auf Vollständigkeit und Plausibilität

·         Fehlermanagement mit technischen Fehlercodes und verständlichen Meldungen für Produktionsmitarbeitende

·         Umsetzung unter Berücksichtigung der innerbetrieblichen Coding-Richtlinien

·         Zugriffsbeschränkung für autorisierte Clients (Authentifizierung, gesicherte Verbindung)

 

2.3 Welche Einschränkungen müssen berücksichtigt werden?

Die bestehende Java-Software ist zwingend weiterzuverwenden, da sie eine spezifische Anbindung an die proprietäre Plotter-Steuersoftware beinhaltet. Aufgrund der hohen Komplexität wäre eine Neu- oder Ersatzentwicklung dieser Schnittstelle im vorgesehenen Projektzeitraum nicht realistisch.

Die Zugriffskontrolle erfolgt über dedizierte Service-Accounts mit eingeschränkten Berechtigungen.

Eine weitere Einschränkung ergibt sich daraus, dass Informationen zu Sonderwünschen und speziellen Layouts nicht standardisiert vorliegen, sondern in Freitextfeldern erfasst werden. Teilweise enthalten diese Angaben Verweise wie „siehe Zeichnung“, die sich nicht automatisiert interpretieren lassen. Diese Sonderfälle müssen auch künftig manuell geprüft werden.

2.4 Abgrenzung der Eigenleistung

Die bestehende Java-Anwendung zur Steuerung des Plotters ist bereits im Einsatz und wird nicht neu entwickelt. Ihre grundlegende Funktionalität zur Erzeugung der Schablonen bleibt unverändert.

Die Eigenleistung des Projekts besteht in der Konzeption und Implementierung einer Lösung, die Produktions- und Layoutdaten automatisiert aus der zentralen Datenquelle abruft, aufbereitet und in der vorhandenen Java-Anwendung verfügbar macht.

Nicht Teil der Eigenleistung ist die Weiterentwicklung der bestehenden Java-Plotter-Software oder die Implementierung der Kommunikation zwischen Java-Anwendung und Plotter, da diese bereits vorhanden ist. 

3 Projektstrukturplan erstellen

3.1 Vorgehensweise zur Umsetzung

Die Umsetzung des Projekts orientiert sich grundsätzlich am Wasserfall-Modell, da die Anforderungen größtenteils klar definiert sind. Einzelne Elemente, insbesondere die Aufbereitung und Darstellung der Layoutdaten, werden jedoch in enger Abstimmung mit den Produktionsmitarbeitenden iterativ überprüft und angepasst.

Zur Qualitätssicherung werden zentrale Funktionen nach der Implementierung mit Unit-Tests überprüft. Ergänzend erfolgen manuelle Prüfungen mit realistischen Testfällen im Fachbereich.

Für die Versionsverwaltung des Quellcodes kommt Git zum Einsatz. Sollte die Schnittstelle über einen Webservice aus NAV realisiert werden, wird zusätzlich das interne NAV-Projektverwaltungssystem genutzt, da Entwicklungen im ERP-System nicht über Git versioniert werden. Der Projektfortschritt und zentrale Entscheidungen werden parallel dokumentiert, um eine transparente Nachvollziehbarkeit zu gewährleisten.

 

3.2 Aufgaben auflisten

• Analyse

  • Durchführen der Ist-Analyse

  • Ermitteln von Use-Cases und Erstellen eines Anwendungsfall-Diagramms

  • Durchführen der Wirtschaftlichkeitsanalyse inkl. Amortisationsrechnung

  • Unterstützung des Fachbereiches beim Erstellen des Lastenheftes

• Entwurf

  • Abbilden der bestehenden Datenbankstruktur inkl. Erstellung eines ER-Diagramms

  • Planung der Architektur inkl. Erstellung eines Komponentendiagramms

  • Modellierung des Datenflusses und der Prozesslogik mittels Aktivitätsdiagramm

  • Entwerfen und Ergänzen eines Klassendiagramms für bestehende und zu ergänzende Klassen

  • Erstellen des Pflichtenheftes

• Implementierung inkl. Tests und Feedback vom Fachbereich

  • Aufsetzen des Projekts in der Entwicklungsumgebung

  • Implementieren der Schnittstelle zur Datenquelle inkl. Tests

  • Implementieren der Authentifizierung/Zugriffslogik inkl. Tests

  • Implementieren der Datenübergabe an das Java-Programm inkl. Tests

  • Implementieren der Aufbereitung der Standard-Daten inkl. Tests

  • Implementieren der Aufbereitung von gesonderten Daten und Layoutanforderungen inkl. Tests

  • Implementieren von Fehlermanagement und Nutzerhinweisen inkl. Tests

  • Vollumfängliche Tests mit den Produktionsmitarbeitenden

• Abnahme und Einführung

  • Code-Review mit dem Ausbilder

  • Abnahme durch den Fachbereich

  • Inbetriebnahme der Lösung

Dokumentation

• Erstellen der Entwicklerdokumentation

• Erstellen der Projektdokumentation

 

3.3 Grafische und tabellarische Darstellung

Phase	Zeit in Stunden
Analyse	10h
Entwurf	12h
Implementierung	45h
Abnahme und Einführung	5h
Dokumentation	8h

 

 

Grafische Darstellung der Phasen

 

 

 

Analyse	10h
Ist-Analyse	3h
Ermitteln von Use-Cases & Anwendungsfall-Diagramm	3h
Wirtschaftlichkeitsanalyse inkl. Amortisationsrechnung	2h
Unterstützung des Fachbereiches beim Lastenheft	2h
Entwurf	12h
Abbilden der bestehenden DB-Struktur (ERD)	3h
Planung der Architektur inkl. Komponentendiagramm	3h
Modellierung des Datenflusses/Prozesslogik (Aktivitätsdiagramm)	2h
Klassendiagramme erstellen/erweitern	2h
Pflichtenheft erstellen	2h
Implementierung inkl. Tests	45h
Aufsetzen des Projekts in der Entwicklungsumgebung	2h
Implementieren der Schnittstelle inkl. Tests	5h
Implementieren der Authentifizierung/Zugriffslogik inkl. Tests	2h
Implementieren der Datenübergabe an das Java-Programm inkl. Tests	6h
Implementieren der der Aufbereitung der Standard-Daten inkl. Tests	10h
Implementieren der Aufbereitung von gesonderten Daten und Layoutanforderungen inkl. Tests	12h
Implementieren von Fehlermanagement und Nutzerhinweisen inkl. Tests	4h
Vollumfängliche Tests mit den Produktionsmitarbeitenden	4h
Abnahme und Einführung	5h
Code-Review mit dem Ausbilder	2h
Abnahme durch Fachbereich	1h
Inbetriebnahme	2h
Dokumentation	8h
Erstellen der Entwicklerdokumentation	2h
Erstellen der Projektdokumentation	6h