Projektantrag bewerten

[yamukud]

Über eure Meinungen freue ich mich:

1. Projektbezeichnung:

Entwicklung einer Applikation zur Visualisierung der Zustände und Stati von Aufträgen in der Produktion („Betriebsdatenerfassung“)

2. Projektbeschreibung, u.a. Projektanlass, Projektziele, Werkzeuge (Software, Hardware)

Ist-Analyse:

Das heutige Kerngeschäft der XXXX GmbH & Co. KG ist die Massendigitalisierung von Schriftstücken – im Jahr durchlaufen ca. 40 Millionen Blatt diverser Kunden den Betrieb. Neben relativ einfachen und eindimensionalen Anwendungen werden auch komplexe Anwendungsszenarien abgebildet.

Die vom Auftraggeber zur Verfügung gestellten Dokumente werden in Verarbeitungseinheiten („Lose“) aufgeteilt und durchlaufen, je nach Auftrag, verschiedene Stationen der Verarbeitung. Neben der Aufbereitung, Vorbereitung und dem Scannen sind z.B. Qualitätskontrolle, Erfassung (Capturing) und/oder Text-/Formerkennung möglich.

Die Nachverfolgung von Arbeitspaketen wird bis dato händisch per Laufkarten realisiert. Rein elektronische Verarbeitungsschritte melden Aktionen bzw. das Verarbeitungsende durch eine Reihe von Status-E-Mails.

Der Nachteil dieser Verarbeitungsweise ist die sequentielle Verarbeitung, die punktuell eine große Menge an Ressourcen bindet (z.B. Maschine bei der OCR-Analyse oder Datenkonvertierungen, Personalbedarf bei der Datenprüfung, Konfektionierung).

Aus diesem Grund ist eine permanente Verarbeitungsweise (harmonischer Produktionsdurchlauf) vorzuziehen. Allerdings benötigt diese eine verbesserte Übersicht über die verteilten Verarbeitungseinheiten und –prozesse im Unternehmen. Diese Aufgabe soll das zu entwickelnde Programm zur Überwachung der Verarbeitungsprozesse im Bereich „Scan-Service“ übernehmen.

Anforderungsanalyse:

Ziel des Projektes ist der Entwurf eines Steuerelements für Windows Forms, welches für jeden Auftrag („Job“) verschiedene Ansichten der Nachverfolgung zulässt. Neben der Anzeige der einzelnen Arbeitspakete jedes Jobs soll auch der Gesamtstand visualisiert werden. Darüber hinaus muss der Stand wie auch Zustand jedes Arbeitspakets abrufbar sein; kritische Situationen und Zustände müssen dargestellt werden.

Die Erschließung der notwendigen Informationen ist so zu gestalten, dass eine sekundengenaue Visualisierung aller beteiligten Verarbeitungsschritte möglich ist. Die Implementierung erfolgt aufgrund betrieblicher Vorgaben in der Programmiersprache C#.

Soll-Konzept:

Eine zentrale, elektronische und sekundengenaue Anzeige der Stati von Arbeitspaketen und Aufträgen kann dargestellt werden. Die entstandene Applikation und die Schnittstelle zur Übergabe der benötigten Informationen sind unabhängig von den bestehenden Arbeitsprozessen und garantieren somit die langfristige, flexible Weiterverwendbarkeit. Das Ergebnis ist nicht abschließend und ist als erste Version zu sehen.

Werkzeuge:

Visual Studio 2008 Professional, C#, UML-Tool, Datenbank

3. Projektphasen mit Zeitplanung in Stunden

1. Initialisierungsphase (zusammen 6h)

1.1 Analyse des Ist-Zustands (1h)

1.2 Kundengespräch Anforderungsanalyse (2h)

1.3 Erstellung des Soll-Konzepts (3h)

2. Designphase (zusammen 10h)

2.1 Wirtschaftlichkeitsanalyse (1h)

2.2 Erstellung der UML-Diagramme (3h)

2.3 Entwurf der dynamischen Schnittstelle (1,5h)

2.4 Entwurf des Datenbankdesigns (0,5h)

2.5 Entwurf der GUI (2h)

2.6 Erstellung des Konzepts der Kommunikation zwischen Stationen und Datenbank (2h)

3. Realisierungsphase (zusammen 25h)

3.1 GUI erstellen (1h)

3.2 Verwaltungsklassen erstellen (2h)

3.2 Klassen zur Realisierung der Kommunikation erstellen (2,5h)

3.3 Schnittstelle erstellen (1h)

3.4 Klassen zur Verarbeitung der ankommenden Informationen erstellen (7h)

3.5 Programmierung der GUI (4,5h)

3.6 Datenbank erstellen und einbinden (2h)

3.7 Implementierung der weiteren Anforderungen (5h)

4. Testphase (zusammen 10h)

4.1 Testverfahren erstellen (4h)

4.2 Tests durchführen (3h)

4.3 Fehlerbehebung (3 h)

5. Abnahme (zusammen 4h)

5.1 Abnahme der Software vom Auftraggeber (1h)

5.2 Installation der Software und Datenbank beim Kunden (1h)

5.3 Vertiefte Einweisung eines leitenden Mitarbeiters (2h)

6. Projektübergreifend (zusammen 15h)

6.1 Projektdokumentation (11,5h)

6.2 Puffer für Fehlerbehebung etc. (2,5h)

6.3 Ist-Soll-Vergleich (1h)

Gesamtes Projekt 70h

Alle hier aufgeführten Arbeitspakete werden in Eigenleistung erstellt.

Geplante Dokumente der Projektdokumentation:

Pflichtenheft (x)

Ist-Analyse

Soll-Konzept

Wirtschaftlichkeitsbetrachtung

Klassendiagramm

Datenbankschema

Codeauszüge

Testprotokoll

Die mit „x“ gekennzeichneten Dokumente werden nicht vom Antragssteller verfasst.

Vielen Dank,

yamukud

[Akku]

So was vorbildliches sieht man selten. Werde ich wieder hier als Referenz nehmen. Großes Lob. Bei mir geht der Antrag anstandslos durch.

[yamukud]

Hallo Akku,

danke für die Blumen Du schreibst:

"Kundendoku bzw. Systemdoku (in deinem Fall Entwicklerdoku), Pflichtenheft, Lastenheft. Alles was du an Dokus deiner Projektdoku beipacken möchtest. Das erstere ist bei uns im übrigen Pflicht."

Somit müsste ich das auch noch einfügen?

Danke

[Akku]

Kunden- bzw. Systemdoku gehören bei uns zwingend zur Projektdoku und müssen deshalb nicht explizit aufgeführt werden.

[hbspike]

Ich muss gestehen das der Antrag auf jedenfall gut ist.

Jedoch: Du machst nur ein einziges Diagramm?

3.2 Klassen zur Realisierung der Kommunikation erstellen (2,5h)

wie kommunizieren sie? Aktivitäts- / Sequenzdiagramm um den Objektfluß besser darzustellen.

Zumindest hat mir das meine BF-Lehrerinn gesagt. Use Case Diagramm wäre sicherlich auch nicht schlecht damit du zumindest ne abstrakte Übersicht zeigen kannst.

[Akku]

2.2 Erstellung der UML-Diagramme (3h)

Schreibt er doch.

[yamukud]

Hi,

da das Ganze sowieso sehr zeitkritisch wird möchte ich nur eins der Diagramme neben dem Klassendiagramm anfertigen. Welches das sein wird bespreche ich heute. Dementsprechend tauchen diese noch nicht bei den Anlagen der Präsentation auf.

@Akku: Hättest du eine Einschätzung hierzu?

Danke,

yamukud

[Akku]

Ich sehe im Moment nicht die Komplexität aus Benutzersicht, sonst hätte ich dir ein Use-Case Diagramm empfohlen, da damit deine Kompetenz aus zwei Richtungen darstellen könntest. Ich würde in deinem Fall jedoch ein Sequenzediagramm bevorzugen, da du ziemlich nahe am MVC-Konzept bist oder sogar benutzt.

[yamukud]

Hallo Akku,

danke, dann deckt sich deine Einschätzung mit der meinen.

Gerade habe ich gehört, dass 12 Stunden Doku Pflicht sind, sonst wird der Antrag abgelehnt? Dann wäre ich ja schon raus Werde das eben ändern. Gibt es eurer Erfahrung nach ähnliche weitere Vorgaben?

Danke,

yamukud

[hbspike]

Ah. Ok. Dann vergiss genau das aber auch nicht im POP.

Sowas mögen die Prüfer gerne. Begründen begründen begründen

o-ton des Prüfers

edit:

Die Wirtschaftlichkeitsanalyse.

Mir wurde angeraten 2 zu machen. eine in der Planung und eine am Ende. Sodass du nen wunderschönen vergleich ziehen kannst zu geplant und tatsächlich.

Bearbeitet 26. Oktober 2011 von hbspike

[Akku]

Versuche irgendwie auf die 14 bis 15 Stunden zu kommen. Manche PA nehmen das sehr genau. Letztendlich ist die Doku vom Zeitverbrauch, nicht zu unterschätzen. Der Soll-/Ist-Vergleich in 6.3 sollte in die Doku rein, somit bist du schon mal bei 12,5 Stunden.

Mir wurde angeraten 2 zu machen.

Hat er doch. Bitte erst gründlich lesen.

2.1 Wirtschaftlichkeitsanalyse (1h)

6.3 Ist-Soll-Vergleich (1h)

[hbspike]

Mhh. Ich habs losgelöst vom Ist-Soll (auch wenn ich da auch eine Gegenüberstellung im wirschaftlichen Sinn mache, jedoch liegt der Hauptaugenmerk auf den Funktionen, was gewollt und was umgesetzt wurde). Machs wie du es meinst. War nur eine Idee

[yamukud]

Für Ideen bin ich immer zu haben, danke für deine Erfahrungen.

Da meine Wirtschaftlichkeitsbetrachtung auf mögliche Risikominimierungen und zusätzliche Aufträge abzielt werde ich nur eine erstellen (ansonsten hat das Tool erstmal keinen direkten wirtschaftlichen Nutzen neben der möglichen Umstellung, die aber wiederum erstmal keinen wirtschaftlichen Vorteil bringt). Der Soll-Ist-Vergleich wird somit vor allem auf das Soll-Ist des Programms abzielen, die Implementierung in unsere Prozesse wird bis nächsten Sommer brauchen.

@hbspike: Was meinst du mit POP?

@Akku: Werde ich umsetzen

Danke,

yamukud

PS: Meine Doku wird wahrscheinlich fast nur aus "Begründen" bestehen

[Akku]

PS: Meine Doku wird wahrscheinlich fast nur aus "Begründen" bestehen

So ist es richtig. Diskutiere wo immer es geht. Das macht eine exzellente Doku aus.

[hbspike]

Es gibt ja monetären und nichtmonetären Nutzen.

Wenns keinen wirtschaftlichen Vorteil hat, wird es aber mit Sicherheit einen anderen haben. Oder? Den solltest du dann zumindest beschreiben, weil sonst gäbe es ja eigentlich keinen Grund das Projekt durchzuführen. Gelle ^^

POP = Prozessorientierter Projektbericht

Dat 15 Seiten Teil was du am Ende abgibst

[yamukud]

Nach der heutigen finalen Überarbeitung der neue Stand, ist leider doch recht umfangreich geworden.

1.1. Projektbezeichnung

Produktionsüberwachung im Bereich „Scan-Service“

1.2. Problembeschreibung inkl. Projektumfeld

Das heutige Kerngeschäft der XXX ist die Massendigitalisierung von Schriftstücken – im Jahr durchlaufen ca. 85 Millionen Blatt diverser Kunden den Betrieb. Neben relativ einfachen, eindimensionalen Anwendungen werden auch komplexe Anwen-dungsszenarien abgebildet, wobei letztere einen immer größeren Anteil einnehmen.

Im klassischen Produktionsablauf werden die vom Auftraggeber zur Verfügung gestellten Dokumente in Verarbeitungseinheiten („Lose“) aufgeteilt. Sie durchlaufen, je nach Auftrag, verschiedene Stationen der Verarbeitung. Neben der Aufbereitung, Vorbereitung und dem Scannen sind z.B. Qualitätskontrolle, Erfassung (Capturing) und/oder Text-/Formerkennung möglich. Am Ende der Prozesskette erfolgt ein Datenexport in die vom Kunden definierte Struktur sowie die Endkontrolle und Auslieferung.

Die Nachverfolgung von Arbeitspaketen und Produktionszahlen (Stunden, Stück, etc.) wird bis dato teilweise händisch -per Laufkarten- und teilweise elektronisch realisiert: rein elektronische Verarbeitungsschritte melden Aktionen bzw. das Verarbeitungsende durch eine Reihe von Programmmeldungen, Report-Dateien oder Status-E-Mails.

Der Nachteil dieser Verarbeitungsweise ist die sequentielle Verarbeitung, die punktuell eine große Menge an Ressourcen bindet (z.B. Maschine bei der OCR-Analyse oder Datenkon-vertierungen, Personalbedarf bei der Datenprüfung, Konfektionierung) sowie die dezentrale Informationshaltung der Prozessmeldungen.

Der Antragssteller ist Auszubildender zum Fachinformatiker der Fachrichtung Anwendungs-entwicklung bei oben genannter Firma und wird das Projekt in der Abteilung „EDV/IT“ durchführen. Projektverantwortlicher ist der Abteilungsleiter der „EDV/IT“, Herr XXX. Als Ansprechpartner stehen Herr XXX als Betriebsleiter sowie für fachliche Fragen neben Herrn XXX die Abteilungskollegen Herr XXX und Herr XXX zu Verfügung. Für netzwerkbetreffende Fragen steht zudem die Abteilung „Systemintegration“ unter Herrn XXX zu Verfügung. Daneben steht selbstverständlich der Ausbildungsleiter, Herr XXX, für Fragen bereit.

Die Planung, Analyse, Programmierung und das Testen des Verarbeitungs-Tools erfolgt am Arbeitsplatz, XXX. Somit bestehen kurze Wege zu den Ansprechpartnern und das Programm kann direkt in der dafür vorgesehenen Umgebung getestet werden.

1.3. Ziel des Projektes

Aus o.g. Gründen sind eine permanente Verarbeitungsweise (harmonischer Produktions-durchlauf) und eine zentrale Informationshaltung der Produktionszahlen erstrebenswert. Zuvor wird aber eine verbesserte Übersicht über die verteilten Verarbeitungseinheiten und –prozesse im Unternehmen benötigt. Diese Aufgabe soll das zu entwickelnde Programm zur Überwachung der Verarbeitungsprozesse im Bereich „Scan-Service“ übernehmen.

Ziel des Projektes ist somit der Entwurf eines mandantenfähigen Steuerelements für Windows Forms, welches für jeden Auftrag („Job“) verschiedene Ansichten der Nachverfolgung zulässt. Neben der Anzeige der einzelnen Arbeitspakete jedes Jobs soll auch der Gesamtstand visualisiert werden. Darüber hinaus muss der Stand wie auch Zustand jedes Arbeitspakets abrufbar sein; kritische Situationen und Zustände müssen dargestellt werden.

Dazu muss eine zentrale, elektronische und sekundengenaue Anzeige der Stati von Arbeitspaketen und Aufträgen dargestellt werden können. Die entstandene Applikation und die Schnittstelle zur Übergabe der benötigten Informationen müssen unabhängig von den bestehenden Arbeitsprozessen sein und garantieren somit die langfristige, flexible Weiterverwendbarkeit. Die Erschließung und Vorhaltung der notwendigen Informationen ist so zu gestalten, dass eine sekundengenaue Visualisierung aller beteiligten Verarbeitungs-

schritte möglich ist.

Die Implementierung erfolgt aufgrund betrieblicher Vorgaben in der Programmiersprache C#. Das Ergebnis ist nicht abschließend und ist als erweiterter Prototyp zu sehen, wodurch der Umfang 70 Stunden nicht übersteigt.

1.4. Eigene Tätigkeiten

Die eigenen Tätigkeiten des Antragsstellers betreffen den Umfang des gesamten Konzepts inklusive Planung, Teile der Kalkulation, Realisation und Testen, exklusive der technischen Bereitstellung der Datenbank, der Erstellung des Pflichtenhefts und Teile der Dateneinholung für die Wirtschaftlichkeitsbetrachtung.

2. Projektphasen und Zeitplanung in Stunden:

1. Initialisierungsphase (zusammen 6h)

1.1 Analyse des Ist-Zustands (1h)

1.2 Kundengespräch Anforderungsanalyse (2h)

1.3 Erstellung des Soll-Konzepts (3h)

2. Designphase (zusammen 10h)

2.1 Wirtschaftlichkeitsanalyse (1h)

2.2 Erstellung der UML-Diagramme (3h)

2.3 Entwurf der dynamischen Schnittstelle (1,5h)

2.4 Entwurf des Datenbankdesigns (0,5h)

2.5 Entwurf der GUI (2h)

2.6 Erstellung des Konzepts der Kommunikation zwischen Stationen und Datenbank (2h)

3. Realisierungsphase (zusammen 25h)

3.1 GUI erstellen (1h)

3.2 Verwaltungsklassen erstellen (2h)

3.2 Klassen zur Realisierung der Kommunikation erstellen (2,5h)

3.3 Schnittstelle erstellen (1h)

3.4 Klassen zur Verarbeitung der ankommenden Informationen erstellen (7h)

3.5 Programmierung der GUI (4,5h)

3.6 Datenbank erstellen und einbinden (2h)

3.7 Implementierung der weiteren Anforderungen (5h)

4. Testphase (zusammen 10h)

4.1 Testverfahren erstellen (4h)

4.2 Tests durchführen (3h)

4.3 Fehlerbehebung (3 h)

5. Abnahme (zusammen 4h)

5.1 Abnahme der Software vom Auftraggeber (1h)

5.2 Installation der Software und Implementierung der Datenbank beim Auftraggeber (1h)

5.3 Vertiefte Einweisung eines leitenden Mitarbeiters (2h)

6. Projektübergreifend (zusammen 15h)

6.1 Projektdokumentation (12,5h)

6.2 Puffer für Fehlerbehebung etc. (2,5h)

Gesamtzeitaufwand: 70 Stunden

3. Angaben zur geplanten, prozessorientierten Projektdokumentation:

Titelblatt

Inhaltsverzeichnis:

1. Einführung

1.1. Firmenumfeld

1.2. Projektüberblick

2. Fachkonzept

2.1. IST-Analyse

2.2. SOLL-Konzept

2.3. Anforderungen

2.4. Projektziele

3. Projektverlauf

4. Ausblick

5. ggf. Fazit

6. Kosten-Nutzen-Analyse

7. Begriffserklärungen

Anlagen:

- Pflichtenheft

- Zeitplanung

- Klassendiagramm

- Sequenzdiagramm

- Datenbankschema

- Testprotokoll

- exemplarischer Programmcode

- ggf. Sitzungsprotokolle

- ggf. Abnahmeprotokoll

Unterstrichene Punkte werden nicht vom Antragssteller erstellt. Sie dienen dem Quellennachweis.