Projektantrag - FiAE - IHK München

[Puppetmaster2006]

Anbei mein Projektantrag für die IHK München, der spätestens am 12.04.2006 fällig ist. Da mein Ausbildungsleiter nicht gerade der schnellste ist, was durchsichten etc. betrifft, wäre ich ziemlich glücklich darüber, ein wenig konstruktive Kritik und Verbesserungsansätze zu erfahren. Die Datei ist PDF und knappe 9KByte groß, sollte also für die meistens ohne Probs zu machen sein. :bimei

Eine Vorlage gab und gibt es nicht, steht explizit auf dem Informationszettel(n) meiner IHK.

Danke im Voraus für die Bemühungen! :uli

Konzept_Antrag_4_web.pdf

[Neo_Guevara]

Hey hallo auch !

also so vom Aufbau her finde ich deinen Projektantrag nicht schlecht. Hab nur minimale Verbessungsanregungen für dich:

1.2 Problembeschreibung

hier würde ich nicht von "Urlaube" sondern "Urlaubstagen" / Wochen sprechen weil Urlaube einfach seltsam klingt.

3.4 Dokumentation

Entwicklerdoku ???? du meinst wohl eher Administration oder ? :confused:

[Puppetmaster2006]

also so vom Aufbau her finde ich deinen Projektantrag nicht schlecht.

Danke

1.2 Problembeschreibung

hier würde ich nicht von "Urlaube" sondern "Urlaubstagen" / Wochen sprechen weil Urlaube einfach seltsam klingt.

Wo du Recht hast, hast du recht. Klingt wirklich seltsam und wurde auch sogleich geändert...

3.4 Dokumentation

Entwicklerdoku ???? du meinst wohl eher Administration oder ? :confused:

Naja, nö. Da ich in der Projektarbeit mit PHP arbeite und möglichst intensiv Objekt orientiert Programmieren möchte, plane ich den phpDocumentator zu verwenden, um anderen Entwicklern die Erweiterung bzw. Verbesserungen an dem Urlaubsplaner zu erleichtern. Sowas kommt doch sicherlich nicht schlecht, oder?

Im übrigen knall ich den Text jetzt doch lieber einfach mal so rein, ist wohl für die meisten angenehmer.

1.1. Projektbezeichnung:

Entwicklung und Integration eines Urlaubsplaners in das bestehende Firmen-Intranet.

1.2. Problembeschreibung (IST-Zustand)

Die Mitarbeiter der MVI SOLVE-IT nutzen für Urlaubs- und sonstige Abwesenheiten einen bereits vorhandenen Urlaubsplaner, welcher über PL/pgSQL, Java Servlets und JSP realisiert wurde. Dieser ist in der Vielfalt seiner Funktionen sehr stark eingegrenzt und dient lediglich einer abteilungsübergreifenden Überblicksdarstellung der genommenen Urlaube. Die

Abteilungsleiter haben die Möglichkeit, eingereichte Urlaube zu befürworten oder abzulehnen, die dafür vorgesehenen Email-Benachrichtigungsfunktionen sind allerdings unzureichend und sehr fehleranfällig. Die Feiertage werden umständlich über eine jährlich zu erneuernde Feiertagstabelle in der Datenbank gepflegt.

1.3. Ziel des Projektes (SOLL-Zustand)

Das Ziel ist es, einen Urlaubsplaner in das bestehende ORGA (Personalverwaltungstool, welches Mitarbeiter-spezifische Daten über eine Postgree-DB zur Verfügung stellt), welches bereits in das Firmen-Intranet integriert ist, einzubinden. Die Überblicks-Darstellung soll über eine Wochen-, Monats-, Quartals- und Jahresübersicht mit diversen Filteroptionen realisiert

werden. Jeder Mitarbeiter soll Urlaubsanträge möglichst komfortabel eintragen, nachträglich einreichen und übersichtlich verwalten können. Zudem ist eine Rechtevergabe gefordert, die es zum Beispiel Abteilungsleitern ermöglicht, Urlaube zeitschonend zu genehmigen oder abzulehnen.

Ein weiteres Kriterium für das geplante Projekt ist ein umfangreiches Informationssystem, welches Mitarbeiter und Abteilungsleiter per EMail über aktuelle Urlaubs-Zustände informieren soll.

Funktionell soll der Urlaubsplaner minimal die festen Feiertage automatisch erkennen, eine Realisierung und Berechnung der beweglichen Feiertage wäre wünschenswert. Diese müssen aber mindestens gewährleistet sein, wenn nicht durch eine automatische Berechnung, dann durch eine direkte Administration.

1.4. Entwicklungsumgebung

Sehr wahrscheinlich wird die Entwicklungsumgebung aus einem Apache 2-Webserver bestehen, auf welchem die Programmiersprache PHP 4, sowie die Datenbank-Management-Systeme (DBMS) PostgreeSQL- und mySQL installiert sind.

2. Projektphasen und Zeitplanung in Stunden:

- Analyse (12 Stunden)

o Analyse des IST-Zustandes

o Definition des SOLL-Zustandes

o Vergleichsmatrix mit Altsystem

o Erstellen eines Pflichtenheftes

- Design (10 Stunden)

o Erstellen des Datenbankdesignes

o Erstellung eines Programmablaufplanes

- Realisierung (26 Stunden)

o Erstellung der Datenbank

o Erstellung der Anwendung

- Testphase und Abnahme (8 Stunden)

o Test der Anwendung unter realen Bedingungen

o Übergabe und Abnahme vom Kunden nach Qualitätskontrolle

- Dokumentation (14 Stunden)

o Ausarbeitung der Projektdokumentation

o Fazit

Gesamt-Zeitaufwand: 70 Stunden

3. Angaben zur geplanten 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. Benutzermodell

2.4. Testfälle

3. IV-Konzept

3.1. Technologien

3.2. Systementwurf

3.3. Datenbankmodell

4. Dokumentation

4.1. Benutzerdokumentation

4.2. Entwicklerdokumentation

Ich hätte zudem direkt eine Frage zum Punkt 1.3!

Das Ziel ist es, einen Urlaubsplaner in das bestehende ORGA (Personalverwaltungstool, welches Mitarbeiter-spezifische Daten über eine Postgree-DB zur Verfügung stellt), welches bereits in das Firmen-Intranet integriert ist, einzubinden.

Ich habe heute festgestellt, dass ich zwar die Benutzerdaten aus der Datenbank gut gebrauchen kann, eine direkte Integration in dieses Tool allerdings eine enorme Aufsplittung meiner Klassen bedeuten würde und in der IHK Informationsbroschüre steht, man solle möglichst auf diese verzichten. Wenn ich nun lediglich einen Link in diesem Tool setze, dieser den Urlaubsplaner neu öffnet und man jederzeit die Möglichkeit hat, wieder zu ORGA zurückzukehren, wäre das dann noch konform mit meiner Beschreibung. Kurzum, ich nutze nur die DB Daten (Benutzer und Passwort) und das Personalverwaltungstool als Einstiegsseite für den Planer.

[schalda]

Ich habe heute festgestellt, dass ich zwar die Benutzerdaten aus der Datenbank gut gebrauchen kann, eine direkte Integration in dieses Tool allerdings eine enorme Aufsplittung meiner Klassen bedeuten würde und in der IHK Informationsbroschüre steht, man solle möglichst auf diese verzichten. Wenn ich nun lediglich einen Link in diesem Tool setze, dieser den Urlaubsplaner neu öffnet und man jederzeit die Möglichkeit hat, wieder zu ORGA zurückzukehren, wäre das dann noch konform mit meiner Beschreibung. Kurzum, ich nutze nur die DB Daten (Benutzer und Passwort) und das Personalverwaltungstool als Einstiegsseite für den Planer.

Würde ich so machen, allerdings solltest du das in der Doku dann auch erwähnen und erklären können. Du hast die Möglichkeit andere projekt oder Tools bzw. Datenbanken auch zu nutzen, auch wenn du sie nicht selber geschrieben hast. Du solltest nur darauf in der Doku und auch in der Präsentation verweisen und gegebenenfalls begründen.

[allesweg]

Eigene Erfahrung: Brich die Zeiten auf die Unterpunkte runter. Blöcke im zweistelligen Bereich mag die IHK München nicht so sehr.

[IJK]

allesweg verdrängt wie der Name schon sagt manchmal die Vergangenheit

Die IHK München besteht aus mehr als 350 Prüfern. Da gibt es auch welche, die 3.11.47.128 gut finden *gröhl*

Nein, im Ernst: Die Stelle mit der Zeitplanung scheint verbesserungsbedürftig.

Kleiner Tipp von mir als Projektmanager (nicht als Prüfer): Das Verhältnis Planung / Realisierung / Test sollte 40 : 20 :40 sein...

[horazius]

@IJK: Du meinst den Software Lifecycle, eigentlich sollte Planung aber 75% und Umsetzung 25% sein.

Ciao HoRaZ

[Puppetmaster2006]

So, die aktuellste Version...

1.1. Projektbezeichnung:

Entwicklung und Integration eines Urlaubsplaners in das bestehende Firmen-Intranet.

1.2. Problembeschreibung (IST-Zustand)

Die Mitarbeiter der MVI SOLVE-IT nutzen für Urlaubs- und sonstige Abwesenheiten einen bereits vorhandenen Urlaubsplaner, welcher über PL/pgSQL, Java Servlets und JSP reali-siert wurde. Dieser ist in der Vielfalt seiner Funktionen sehr stark eingegrenzt und dient ledig-lich einer abteilungsübergreifenden Überblicksdarstellung der genommenen Urlaubstage. Die Abteilungsleiter haben die Möglichkeit, eingereichte Urlaubstage zu befürworten oder abzulehnen, die dafür vorgesehenen Email-Benachrichtigungsfunktionen sind allerdings un-zureichend und sehr fehleranfällig. Die Feiertage werden umständlich über eine jährlich zu erneuernde Feiertagstabelle in der Datenbank gepflegt.

1.3. Ziel des Projektes (SOLL-Zustand)

Das Ziel ist es, einen Urlaubsplaner in das bestehende Intranet der MVI SOLVE-IT zu integ-rieren. Die Überblicks-Darstellung soll über eine Wochen-, Monats-, Quartals- und Jahres-übersicht mit diversen Filteroptionen realisiert werden. Jeder Mitarbeiter soll Urlaubsanträge möglichst komfortabel eintragen, nachträglich einreichen und übersichtlich verwalten können. Zudem ist eine Rechtevergabe gefordert, die es zum Beispiel Abteilungsleitern ermöglicht, Urlaubstage zeitschonend zu genehmigen oder abzulehnen.Ein weiteres Kriterium für das geplante Projekt ist ein umfangreiches Informationssystem, welches Mitarbeiter und Abteilungsleiter per EMail über aktuelle Urlaubsantrags-Zustände informieren soll.Funktionell soll der Urlaubsplaner minimal die festen Feiertage automatisch erkennen, eine Realisierung und Berechnung der beweglichen Feiertage wäre wünschenswert. Diese müs-sen aber mindestens gewährleistet sein, wenn nicht durch eine automatische Berechnung, dann durch eine direkte Administration.

1.4. Entwicklungsumgebung

Sehr wahrscheinlich wird die Entwicklungsumgebung aus einem Apache 2-Webserver be-stehen, auf welchem die Programmiersprache PHP 4, sowie die Datenbank-Management-Systeme (DBMS) PostgreeSQL- und mySQL installiert sind.

NEW

1.5. Projektumfeld

Die geplante Anwendung wird die bestehende Softwarelösung ersetzen und über das Intra-net für den Benutzer erreichbar sein. Das Design und die Umsetzung des Designs wird an die Corporate Identity (=Erscheinungsbild eines Unternehmens) der MVI-Group, einschließ-lich der MVI SOLVE-IT GmbH angepasst.

NEW

2. Projektphasen und Zeitplanung in Stunden:

- Analyse (13 Stunden)

o Analyse des IST-Zustandes

o Definition des SOLL-Zustandes

o Vergleichsmatrix mit Altsystem

o Erstellen eines Pflichtenheftes-

Design (12 Stunden)

o Erstellen des Datenbankdesignes

o Erstellung eines Programmablaufplaneso logische Abläufeo Schnittstellen- Realisierung (20 Stunden)

o Erstellung der Datenbank

o Erstellung der Anwendung-

Testphase und Abnahme (11 Stunden)

o Test der Anwendung unter realen Bedingungen

o Übergabe und Abnahme vom Kunden nach Qualitätskontrolle

o Integration der Anwendung in das produktive System

- Dokumentation (14 Stunden)

o Ausarbeitung der Projektdokumentation

o Fazit

Gesamt-Zeitaufwand: 70 Stunden

3. Angaben zur geplanten 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. Benutzermodell

2.4. Testfälle

3. IV-Konzept

3.1. Technologien

3.2. Systementwurf

3.3. Datenbankmodell

4. Dokumentation

4.1. Benutzerdokumentation

4.2. Entwicklerdokumentation