Abschlussprojekt: Rails Seite - Themengebiet ausreichend?

[steel_touch]

Hallo,

ich habe jetzt im Winter meine Abschlussprüfung und muss dafür nun das Projekt beantragen. (Fachinformatiker Anwendungsentwicklung)

Ich habe echte Schwierigkeiten ein Projekt zu finden, welches zeitlich in 70 Stunden passt. Der einzige Vorschlag, welcher einigermaßen passt wäre ein Ruby on Rails Projekt.

Worum es genau geht ist erst mal Nebensächlich, Inhalt des Projektes wäre aber eine Webseite zu erstellen (LAMP wird von der internen-It bereit gestellt).

Es handelt sich um mehrere miteinander verknüpfte html-Seiten, in die Daten eingepflegt werden und auch abgerufen werden können. Die einzige nicht ganz triviale Programmieraufgabe, welche mir einfällt wäre der Export von (per Webseite) gefilterten Daten in eine .cvs Datei.

Im Groben ist der Inhalt des Projektes also:

- Kundengespräch (Anforderungermittlung)

- Seitenaufbau (Hirarchie) erstellen

- Datenbankdesign erstellen

- Logik für Datenabfrage und -eingabe schreiben

- Export schreiben

- Dokumentation

Was meint ihr? reicht das um als Projekt für Anwendungsentwickler herhalten zu können?

Vielen Dank im Vorraus

[SilentDemise]

2 Std. Kundengespräch

2 Std Seitenaufbau

2 Std. Datenbankdesign

2 Std. Abfragen

1 Std. Export

8 Std. Dokumentation

also da fehlt noch einiges ;-)

[Pixie]

also da fehlt noch einiges ;-)

Ein Projekzt besteht aber aus noch mehr...

2 Stunden Ist-Analyse

3 Stunden Soll-Konzept

1 Stunden Angebot schreiben

4 Stunden Pflichtenheft schreiben

4 Stunden Testen/Qualitätsmanagement

1 Stunde Übergabe

1 Stunde Kundenschulung

...to be cobtinued

[steel_touch]

Nene es ist schon kein ganz kleines Projekt mit 3 Seiten mal eben oder so.

Mein Ausbilder hat auch eher Sorge, dass ich länger brauche. Mir gefällt es nicht so, weil der Programmierteil halt nicht wirklich Anspruchsvoll ist.

Rails erledigt so viel für einen. Es handelt sich hier also vorraussichtlich um ein paar getter und setter, ein bisschen plausabilitäts- bzw. vollständigkeitsprüfung und vermutlich javascript/Ajax. Viel mehr Code kommt da nicht.

[itazubi]

konzentriere dich dann auch auf die Testverfahren. Also Abbildungen von White- und Blackbox ausführlich in Dokumentation einbauen. Das visualisiert deine Arbeit gut. Es geht ja nicht darum das erste 100 k - Zeilen Programm zu realisieren, sondern ein Projekt vom Kunden zu realisieren. Wenn der Kunde eben ein anspruchsvolles, aber wenig programmierbares Tool haben will, dann ist das halt so. Du musst deine 70 Stunden einhalten und erfüllen. Programmierung wird dir nicht so schnell ausgehen. Du siehst sehr bald, dass der Posten "Test" ansteigen wird. Schließlich sind Fehler immer einzurechnen.

[steel_touch]

Das ist eine gute Idee

Test driven Development wird von Rails stark unterstützt, das kann man auf jeden Fall mit in den Fokus nehmen.

Werde jetzt erst mal den Projektantrag schreiben, vielleicht fällt mir dabei ja noch einiges ein.

Ich lege euch den Projektantrag dann mal vor, damit ihr euch ein genaueres Bild machen könnt.

Danke an alle bis hierhin

[steel_touch]

Hey,

Freitag war das Treffen mit den Verantwortlichen. Das Projekt ist dann doch (zum Glück) etwas anderes geworden.

Nichts desto trotz würde ich gern trotzdem Test Driven Development mit einbringen, befürchte aber, dass das dann viel zu viel wird. Deshalb habe ich erst mal alles was in die Richtung geht weg gelassen. Anbei mein erster Entwurf für den Projektantrag den ich am WE erstellt habe.

Wär jemand so nett und schreibt ein paar Takte dazu?

Danke schon mal im Vorraus!

Projektbezeichnung

Erstellung eines EDV-gestützten Workflows zur Unterstützung des Einkaufsprozesses von Bauteilen

Projektbeschreibung

Die xxxx Firma xxxxx ist ein Hersteller für xx irgendwie geartete elektronische Geräte(igeg) xx. Die xx igeg xx werden am Standort xxxx Stadt xxx samt der enthaltenen Elektronik entworfen und gebaut.

Die Beschaffung von erstmalig eingesetzten Bauteilen für diese xx igeg xx ist ein iterativer Prozess zwischen der Produktentwicklung und dem Einkauf. Zur Unterstützung dieses Prozesses soll ein EDV-gestützter Workflow erstellt werden.

Ist- Zustand

Werden Bauteile benötigt, welche noch nicht verbaut wurden, so trägt derzeit der zuständige Mitarbeiter aus der Produktentwicklung diese in eine Excel-Tabelle ein. Zu jedem Bauteil gibt er Wunschriterien an. Dabei handelt es sich z.B. um die gewünschte Stückzahl, gewünschte maximale Lieferfristen usw. Anschließend schickt er das Dokument per E-Mail an den Einkauf.

Im Einkauf werden im einfachsten Fall für jedes Bauteil Angebote eingeholt, jeweils ein Angebotsvergleich anhand der Wunschkriterien der Produktentwicklung durchgeführt und die resultierenden Daten in das Excel-Blatt eingetragen. Im schlechtesten Fall gibt es das Bauteil nicht in der gewünschten Menge oder der gewünschten Lieferfrist. In diesem Fall wird der Sachverhalt im Excel-Dokument vermerkt. Nach Abschluss der Aktivitäten bekommt der Mitarbeiter in der Produktentwicklung das Dokument per E-Mail zurück.

Er prüft nun die vom Einkauf gemachten Angaben und sucht für die nicht lieferbaren oder von ihm nach anderen Kriterien ausgeschlossenen Bauteile Alternativen und trägt diese wiederum in das Excel-Dokument ein. Es beginnt ein iterativer Prozess, in dessen Verlauf mehrere Versionen des Excel-Dokuments hin und her geschickt werden. Am Ende steht ein Excel-Dokument mit einer Liste von Bauteilen, welche dann vom Einkauf bestellt werden.

Kommen die Bauteile an muss dem zuständigen Mitarbeiter in der Produktentwicklung von der Warenannahme mitgeteilt werden, dass die Ware angekommen ist.

Soll Zustand

Vom Mitarbeiter in der Produktentwicklung soll für jedes Bauteil formularbasiert eine Angebotsanfrage mit den Wunschriterien erstellt werden können. Die Angebotsanfrage wird nach dem Speichern automatisch für den Einkauf freigeschaltet und der Einkauf per E-Mail darüber informiert, dass eine neue Anfrage vorliegt.

Ein Mitarbeiter des Einkaufs soll die Angebotsanfrage bearbeiten und bei Rückmeldung der Fremdhersteller entsprechende Daten eintragen können. Sind alle Daten vorhanden, gibt er die Anfrage wieder für die Produktentwicklung frei. Hier soll wiederum automatisch eine Informations-E-Mail an die Produktentwicklung verschickt werden.

Dort können nun die vom Einkauf hinterlegten Informationen eingesehen und entsprechend reagiert werden. Anschließend geht die Anfrage wieder an den Einkauf usw. Im Laufe des weiteren Prozesses wandelt der Mitarbeiter der Produktentwicklung die Angebotsanfrage irgendwann in eine Bestellung um, welche dann vom Einkauf ausgeführt wird.

Ist das Bauteil eingetroffen soll dies vom Wareneingang in die Bestellung eingetragen, vom System eine E-Mail an den Produktentwickler verschickt und der Prozess damit abgeschlossen werden.

Ziel des Projektes

Der Bestellprozess soll nicht mehr für Bauteillisten durchlaufen werden, sondern geteilt werden auf Bestellprozesse für einzelne Bauteile. Alle beteiligten Mitarbeiter sollen nur auf einen Datenbestand zugreifen, und nicht jeder für sich evtl. mehrere Excel-Blätter pflegen. Die Zuordnung welcher Mitarbeiter zu welchem Zeitpunkt zuständig ist, soll klarer werden.

Die xxxx Firma xxxxx erhofft sich durch das Projekt einen übersichtlicheren, flexibleren, einfacheren und transparenteren Prozess zur Bestellung von neuen Bauteilen.

Projektumfeld

Die resultierende Funktionalität wird entweder auf Basis einer existierenden, webbasierten und hausinternen Anwendung zur Bauteilverwaltung oder auf Basis eines existierenden, webbasierten Workflowsystems implementiert. Welches von beiden zur Grundlage genommen wird, muss noch abschließend geklärt werden.

Beide Systeme laufen im Intranet der xxxx Firma xxxxx und können von weitgehend frei Programmiert werden. Ein Webserver und eine Datenbank muss also nicht zusätzlich installiert werden. Beide Systeme bieten außerdem bereits eine Benutzerautentifizierung.

Projektphasen

Planungsphase (Summe 5 Stunden)

• IST-Analyse (1 Stunde)
  
• Detailiertes SOLL-Konzept samt Anwendungsfalldiagramm (3 Stunden)
  
• evaluierung des Zielsystems (1 Stunde)
  

Definitionsphase (Summe 10 Stunden)

• Entwurf des Programmablaufes (Aktivitätsdiagramm) (3 Stunden)
  
• Entwurf der grafischen Oberfläche (5 Stunden)
  
• Entwurf der „Datenbank“ (2 Stunden)
  

Durchführungsphase (Summe 29 Stunden)

• Erstellung der Oberfläche (Html) (7 Stunden)
  
• Implementierung der Tabellen der Datenbank (1 Stunden)
  
• Implementierung der Funktionalität (21 Stunden)
  

Abschlussphase (9 Stunden)

• Testdaten erzeugen (1 Stunde)
  
• Testen der Anwendung und Beheben von gefundenen Fehlern (8 Stunden)
  

Dokumentation (Summe 17 Stunden)

• Projektdokumentation (17 Stunden)

Gesamt 70 Stunden

Vorraussichtliche Gestaltung der Projektdokumentation

Die Projektdokumentation wird sich vornehmlich auf die Durchführung des Projektes beziehen. Deshalb wird hier ein starker Fokus auf die Projektphasen gelegt. Dementsprechend wird die Projektdokumentation im Wesentlichen dem oben beschriebenen Projektphasen entsprechen.

1. Projektbeschreibung

1.1 xx beschreibung der Firma xx

1.2. IST-Analyse

1.3. Projektziele

2. Planungsphase

2.1. evaluierung des Projektumfelds

2.2. Projektumfeld (Hard- und Software)

2.3. Schnittstellen

2.4. SOLL-Konzept

2.5. Kosten-, Qualitäts- und Ablaufplanung

3. Definitions- und Durchführungsphase

3.1. Die GUI

3.2. Die Datenbank

3.3. Der Programmablauf

4. Tests und Freigabe

4.1. Testdurchführung

4.2. Freigabe

5. Abschluß des Projektes