Projektantrag

[abby]

Es wäre nett wenn sich das jemand durchlesen und mir sagen könnte, was ich noch zu verbessern habe

Vielen Dank

Thema:

Planung und Entwicklung einer Software zum Herunterladen und Drucken von alten Rechnungen und Bestätigungen auf Basis eines Java Servlets für die Firma #### in ####.

Projektbeschreibung:

Der Auftraggeber ist das eigene Unternehmen.

Es soll eine neue Software entwickelt werden, die zur Qualitätssicherung und Abfrage von gedruckten Rechnungen und Reisebestätigungen dient und die Arbeitsabläufe in Hinsicht auf Dauer und Komplexität optimiert.

Zum Zeitpunkt des Projektantrags liegen die Reisebestätigungen, Rechnungen und sonstigen, den Reisen zugeordneten, PDFs ungeordnet in Verzeichnissen und müssen bei Änderungen oder erneutem Druck von Hand gesucht, geöffnet und verschickt werden.

Dieser Prozess dauert einige Zeit und verursacht somit Kosten, die durch eine Optimierung des Prozesses vermieden werden können.

Ziel der Software ist es, die PDFs in einer Datenbank zu erfassen und geordnet auszugeben, um so den Aufwand für Überprüfungen und Änderungen zu minimieren.

Mithilfe der Software können diese PDFs gefiltert aus der Datenbank geholt und gedruckt oder heruntergeladen werden.

So werden die Vorgänge beschleunigt, es wird Arbeitszeit gespart und dadurch werden Kosten gesenkt.

Das vereinfachte auffinden der gesuchten PDFs stellt sicher, dass Änderungen direkt getätigt und dem Kunden die geänderten, oder nach Wunsch schon gedruckten PDFs zur Verfügung gestellt werden können.

Qualitätsmanagement und nachhaltiges Wirtschaften sind auch Teil der Unternehmenspolitik, wodurch die Software für das Unternehmen noch attraktiver wird.

Meine Aufgabe in diesem Projekt ist es, eine Ist-Analyse zu erstellen und ein geeignetes Soll-Konzept zu konzipieren. Danach wird die Software gemäß dem Soll-Konzept entworfen und programmiert.

Zuerst wird ein Programm geschrieben um die bestehenden Daten in eine Oracle Datenbank zu schreiben.

Danach werden diese Daten mithilfe von Parametern, die der Mitarbeiter in einer Weboberfläche eingeben kann, ausgelesen und weiter verarbeitet.

Der Mitarbeiter soll dann die Möglichkeit haben die PDFs anzusehen und auch auf seinen PC herunterzuladen.

Projektumfeld

Das Projekt bearbeitet einen Auftrag der eigenen Abteilung. Es wird mithilfe von Java und JSP durchgeführt. Bei der Entwicklung wird nach dem MVC Modell vorgegangen.

Projektphasen

1. Planungsphase 4h

a. Abstimmung des Auftrags 1h

b. Durchführung Ist-Analyse 1h

c. Durchführung Soll-Analyse 2h

2. Realisierung/Programmierung 40h

a. Entwicklung der Datenbanklogik 4h

b. Entwicklung der Datenbankabfragen 6h

c. Entwicklung der Programmlogik 30h

3. Tests und Abnahme 18h

a. Test mit betroffenen Mitarbeitern 10h

b. Puffer für Nachbesserungen 8h

4. Erstellung der Dokumentation 8h

Zeitaufwand 70h

Geplanter Zeitraum

Beginn: 05.08.2015

Ende: 05.10.2015

Dokumentation

- Deckblatt

- Inhaltsverzeichnis

- Projektbeschreibung

- Zeit und Kostenplanung

- Pflichtenheft

Bearbeitet 13. Juli 2015 von Chief Wiggum
anonymisiert

[Der Hans]

Stell den Antrag bitte anonymisiert ein, also ohne reale Firmennamen und sonstige Daten, die Rückschlüsse erlauben.

[abby]

Kann den Beitrag leider nicht mehr bearbeiten oder löschen :/

Mods?

[stefan.macke]

Was mir direkt auffällt:

• Wirtschaftlichkeitsbetrachtung fehlt
  
• 30h für Programmlogik nicht weiter runtergebrochen
  
• Soll-Analyse müsste wohl Soll-Konzept heißen
  
• Es fehlt jeglicher Entwurf (Use-Cases, Architektur, Prozess, Komponenten usw.)
  
• "Puffer" geht gar nicht (und erst recht nicht über 10% der Projektzeit)
  

[abby]

Vielen Dank für die Rückmeldung.

Ein paar Fragen hierzu:

Was genau meinst du mit Wirtschaftlichkeitsbetrachtung?

Das heißt man darf generell keinen Puffer in die Zeitplanung einbauen? o.O Oder is der bei mir einfach nur zu groß?

[Albi]

Was mir direkt auffällt:

• "Puffer" geht gar nicht (und erst recht nicht über 10% der Projektzeit)
  

Vielen Dank für die Rückmeldung.

Ein paar Fragen hierzu:

Was genau meinst du mit Wirtschaftlichkeitsbetrachtung?

Das heißt man darf generell keinen Puffer in die Zeitplanung einbauen? o.O Oder is der bei mir einfach nur zu groß?

Hatte ich auch drin wurde Anstandslos akzeptiert. Hab halt reingeschrieben bei der Kontroll- & Testphase das ich 8 Stunden Puffer (von 70 Stunden FIAE waren also nur ca. 5,6 %) einplane für mögliche Nachbesserungen usw. Das kam mir auch zugute denn die hab ich am Ende in die eigentliche Realisierung rüberschieben können.

[Asura]

Puffer ist immer schlecht, egal wie groß.

[Albi]

Puffer ist immer schlecht, egal wie groß.

Im Gegenteil so hab ich es in der Ausbildung gelernt, immer ein wenig Puffer mit einplanen da gerade bei neuen Funktionalitäten usw. unvorhergesehne Probleme oder Nachbesserungen auftreten können für die dann noch Zeit sein sollte um nachzubessern, wenn man ihn nicht braucht ist das super und Freut den Kunden weils Billiger wird, wenn man ihn doch Braucht weis der Kunde einfach bescheid das da etwas Spielraum mit eingeplant ist.

Natürlich sollten sie nicht zu groß sein, aber bei uns ist das ganz legitim und wird sogar positiv gesehen wenn man mitdenkt und weiß das ja noch Probleme auftreten könnten die man dann kompensieren muss bzw. wenn die User die Funktionalität testen und ihnen doch ein paar Änderungen einfallen die ihnen Besser gefallen, ohne Puffer hätte ich keine Zeit drauf zu reagieren.

Bearbeitet 13. Juli 2015 von Albireo20

[daZza]

Vielen Dank für die Rückmeldung.

Ein paar Fragen hierzu:

Was genau meinst du mit Wirtschaftlichkeitsbetrachtung?

Das heißt man darf generell keinen Puffer in die Zeitplanung einbauen? o.O Oder is der bei mir einfach nur zu groß?

Ich schätze, dass er auf so etwas wie eine Kosten-Nutzen-Analyse, Amortisationsrechnung, Personalkostenplanung, etc. hinaus will.

Ggf. hast du das in 1b und 1c schon vor. Ansonsten würde ich auch sagen, dass irgendetwas in diese Richtung einzubauen ist. Das Mindeste ist m.E. die Berechnung der voraussichtlichen Projektkosten (Personal, Hardware, Software, Lizenzen, ...) und die Ermittlung des voraussichtlichen Nutzens.

Eine Gegenüberstellung beider Werte gibt dann Aufschluss, ob das Projekt überhaupt durchgeführt werden sollte.

Bzgl. Puffer: Finde ich auch unschön (v.A. in der Höhe). Ich würde die dafür angesetzten Stunden lieber als "impliziten Puffer" auf andere Bereiche aufschlagen. Du solltest ja ein Gefühl dafür haben, was potentiell länger dauern könnte.

[Albi]

Bzgl. Puffer: Finde ich auch unschön (v.A. in der Höhe). Ich würde die dafür angesetzten Stunden lieber als "impliziten Puffer" auf andere Bereiche aufschlagen. Du solltest ja ein Gefühl dafür haben, was potentiell länger dauern könnte.

Da haben wir halt dann andere Ansichten, ich habs in der Ausbildung so beigebracht bekommen und auch in unserer Firma wird es so praktiziert bei neuen Funktionalitäten wird immer noch etwas Puffer mit eingerechnet worauf der Kunde auch hingewiesen wird einfach um sicher zu gehen.

[abby]

Das mit dem Puffer muss ich mir also nochmal überlegen.

also in die Zeitplanung schonmal die Kosten-Nutzen Rechnung etc mit rein?

Oder etwa in die Beschreibung (was ich jetzt persönlich as quatsch erachten würde, aber ich lasse mich gerne eines besseren belehren)

[stefan.macke]

Zum Puffer: 8 von 70 Stunden sind über 10% deiner Projektzeit, für die du anscheinend keine Ahnung hast, was du machen sollst. Das geht nicht. Jedenfalls bei so einem kurzen Projekt nicht. Bei uns würde das abgelehnt. Es kann natürlich wieder sein, dass andere IHKen das anders sehen.

Mir fehlt auch völlig der Entwurf. Das methodische Vorgehen bei der Entwicklung. Du machst 2h Soll-Konzept und dann wird 40h entwickelt. Was gehört denn zu deinem Soll-Konzept? Use-Cases, Architektur, MockUps, Klassendiagramme, ERM, Prozessvisualisierung, Deployment usw.? Ist in zwei Stunden nicht machbar.

Die Wirtschaftlichkeit ist zentraler Bestandteil eines Abschlussprojekts. Der Fachinformatiker ist ein kaufmännischer Beruf. Ich erwarte also Kostenaufstellung, Amortisationsrechnung und ggfs. eine Nutzwertanalyse.

Und 30h lang zu "entwickeln" ist zu grob. Das muss runtergebrochen werden. Daumenregel: längste Phase ein Arbeitstag (7-8h). Du kannst hier z.B. die Komponenten auflisten, die du (hoffentlich im Entwurf) konzipiert hast.

[abby]

meine neue Zeitplanung, hab das ganze noch ein bisschen mehr runtergebrochen.

Projektphasen

1. Planungsphase 4h

a. Abstimmung des Auftrags 1h

b. Durchführung Ist-Analyse 1h

c. Erstellung der Zeit und Kostenplanung 2h

2. Entwurf/Soll Konzept 11h

a. Entwurf der Programmarchitekturen/UML 6h

b. Entwurf der Datenbanklogik 5h

3. Realisierung/Programmierung 35h

a. Entwicklung der Datenbanklogik 4h

b. Konzeptionieren der Datenbankabfragen 4h

c. Entwicklung des Einlese Programms 8h

d. Entwicklung des Backends der Webapp 15h

e. Entwicklung der Benutzeroberfläche 4h

4. Tests und Abnahme 12h

a. Test mit betroffenen Mitarbeitern 8h

b. Puffer für Nachbesserungen 4h

5. Erstellung der Dokumentation 8h

Zeitaufwand 70h

Eine Frage, an die Prüfer. Ich werde mein Projekt wohl relativ gestückelt durchdühren, d.h wirklich innerhalb kompletten von der IHK zur Verfügung gestellten Zeitraums. Kann ich das so angeben?

Viele meiner BS Kollegen geben genau die 70std am Stück an, die sie dran arbeiten werden, was bei mir wohl nicht möglich sein wird.

[stefan.macke]

Das Projekt muss im Rahmen der normalen Arbeitstätigkeiten umgesetzt werden. Wenn du nebenbei noch andere Aufgaben hast (was nicht unüblich ist), kannst du deine Projektzeit auf jeden Fall "stückeln". Das wird dir auch niemand negativ anrechnen.

Viele Azubis schreiben explizit in die Dokumentation, in welchem Zeitraum das Projekt umgesetzt wurde und mit welcher täglichen Arbeitszeit. Einige hängen sogar ein Gantt-Chart inkl. Urlaubszeiten usw. an. Kann man machen, aber mir persönlich würde die Aufteilung der 70h reichen.

Was interessiert mich der Tag und die Uhrzeit der Projektarbeit? Das ist höchstens interessant, wenn es sich um zeitkritische Projekte mit Deadline handelt. Dann muss man natürlich erkennen können, dass der Prüfling seine Zeitplanung entsprechend sinnvoll durchgeführt hat.

[abby]

ok, vielen Dank für die Antwort.

Ist die Zeitplanung so o.K?

[Asura]

Im Gegenteil so hab ich es in der Ausbildung gelernt, immer ein wenig Puffer mit einplanen da gerade bei neuen Funktionalitäten usw. unvorhergesehne Probleme oder Nachbesserungen auftreten können für die dann noch Zeit sein sollte um nachzubessern, wenn man ihn nicht braucht ist das super und Freut den Kunden weils Billiger wird, wenn man ihn doch Braucht weis der Kunde einfach bescheid das da etwas Spielraum mit eingeplant ist.

Natürlich sollten sie nicht zu groß sein, aber bei uns ist das ganz legitim und wird sogar positiv gesehen wenn man mitdenkt und weiß das ja noch Probleme auftreten könnten die man dann kompensieren muss bzw. wenn die User die Funktionalität testen und ihnen doch ein paar Änderungen einfallen die ihnen Besser gefallen, ohne Puffer hätte ich keine Zeit drauf zu reagieren.

Ich höre auf das was mir von den Prüfern gesagt wurde. Einen Puffer zu haben ist in einem Projekt eigentlich immer der Fall. Die meinten bei der IHK allerdings, Puffer sind schlecht.

IHK - Nürnberg.