Hallo Leute,

ich plane für mein Abschlußprojekt die Implementierung eines Verwaltungssystems für Source Code mit zusätzlicher Integration eines bug-tracking-Systems und wollte mal von euch hören, ob das für den Projektantrag ausreichen würde? Überlegungen wie z.b. welches System, Abwägung, Vor- und Nachteile muss ja in die Doku. Ich bin mir jetzt gerade aber nicht sicher, ob Projektumfeld und Nutzen auch mit in den Projektantrag muss.

ich sehe leider keinen Projektantrag?

Projektbezeichnung: Implementierung eines source code Verwaltungssystems inclusive Bug Tracker

kurze Projektbeschreibung:

Das Projekt umfasst eine für unsere Situation am Besten passende Lösung für ein source code Verwaltungssystem zu finden und zu realisieren. Zusätzlich dazu soll noch ein bug-tracking System implementiert werden.

Ich sehe immer noch keinen Projektantrag

Ich sehe immer noch keinen Projektantrag

okay ich arbeite den eben mal aus, dann stell ich ihn hoch

So ich habe das jetzt mal ausgearbeitet:

Projektbezeichnung: Implementierung eines source code Verwaltungssystems inclusive Bug Tracker

kurze Projektbeschreibung:

Das Projekt umfasst eine für unsere Situation am Besten passende Lösung für ein source code Verwaltungssystem zu finden, zu planen und zu realisieren. Zusätzlich dazu soll noch ein bug-tracking System implementiert werden.

Projektablauf:

Informationsbeschaffung, Anforderungsanalyse

Beschaffung der Hard- und Software

Planung der Arbeitsschritte

Durchführung des Projekts

Qualitätssicherung, Funktionsprüfung

Geplante Dokumentation zur Projektarbeit:

PLANUNGSPHASE

-Ausgangssituation

-Projektziele

-Projektumfeld

-Erfassung der Anforderungen an System und Hardware

-Berücksichtigung von Wünschen der Anwender

-Sammeln von Informationen

-Ressourcenplanung

-Ablaufplanung

REALISIERUNGSPHASE

-Dokumentation der Arbeitsschritte

-Erfassung von Problemen, Änderungen oder Abweichungen

FUNKTIONS- UND QUALITÄTSSICHERUNG

-Prozesse zur Gewährleistung der Qualität

Qualitätskontrolle

-Abläufe zur Sicherstellung der Funktionalität

Abnahmeprotokoll

Projektplanung einschließlich Zeitplanung:

Beschaffung von Informationen 2 Std.

Erfassung der Anforderungen 2 Std.

Beschaffung der Ressourcen 1 Std.

Ablaufplanung 2 Std.

Installation 6 Std.

Konfiguration 6 Std.

Problembeseitigung 4 Std.

Qualitätskontrolle 1 Std.

Funktionsprüfung 2 Std.

Abnahme 1 Std.

Dokumentation 8 Std.

Ablehnungsgrund " Ziel und Projekt Unklar" ^^

Diene Projektbeschreibung ist so Dünn wie Butter in der Sonne.

Das die Lösung für euch die beste sein wird,ist wohl jedem klar.

Doch ich befürchte Schwer das kein Prüfer weiß wohin du willst.

Ablehnungsgrund " Ziel und Projekt Unklar" ^^

Diene Projektbeschreibung ist so Dünn wie Butter in der Sonne.

Das die Lösung für euch die beste sein wird,ist wohl jedem klar.

Doch ich befürchte Schwer das kein Prüfer weiß wohin du willst.

Okay also fehlt indemfall bei der kurzen Projektbeschreibung noch WARUM so ein System im Produktivbetrieb bei uns in Frage käme und WELCHEN Vorteil sich daraus für unser Unternehmen ergeben würde?

Genau, man kann auch ein IST > SOLL vergleich als Projektbeschreibung nehmen, so habe ich es gemacht.

Du sollst ja darlegen wieso du von A nach B willst und welche Vorteile sich eben ergeben oder das der Ablauf besser wird etc. pp.

Genau, man kann auch ein IST > SOLL vergleich als Projektbeschreibung nehmen, so habe ich es gemacht.

Du sollst ja darlegen wieso du von A nach B willst und welche Vorteile sich eben ergeben oder das der Ablauf besser wird etc. pp.

Okay danke erstmal für deine Rückmeldung. Was sagst du/ihr denn zu dem Rest (Projektablauf, Geplante Dokumentation und Zeitplanung)? Ist das so in Ordnung und schätzt ihr das Projekt vom Umfang her als ausreichend ein, um angenommen zu werden?

Welcher Beruf? FISI?

Welcher Beruf? FISI?

Es gibt seit geraumer Zeit Tags vor dem Beitrag. Da steht das eigentlich drin.

Siehe "[FISI] Projektantrag in Ordnung?"

Gruß, Goulasz

Ich habe jetzt die Projektbeschreibung auch nochmal geändert:

Kurze Projektbeschreibung:

Das Projekt umfasst die Planung und die anschließende Realisierung eines Verwaltungssystems für Source Code. Die momentane Lösung ist veraltet und wird auch vom Hersteller nicht mehr aktualisiert. Hinzu kommt, dass die momentane Lösung für den aktuellen und den kommenden Entwicklungsumfang nicht ausreicht. Mit einer besseren Lösung lässt sich der Zeitaufwand für die Verwaltung von Entwicklungsständen verkleinern, sowie die Auftragskapazität erhöhen und damit auch der Umsatz.

Ist das immer noch zu schwammig?

Dh. die Anbindung eines Bugtrackers ist jetzt nicht mehr Teil des Projekts?

Das hängt davon ab, wie viel Zeit übrig bleibt aber es wird wahrscheinlich auch noch gemacht. Allerdings für das Projekt ist das Tool unrelevant. Für mich gehört das mehr oder weniger eh zu einem Versionierungssystem dazu aber zur eigentlichen Projektbeschreibung gehört das meiner Meinung nach eben nicht.

Warum soll ein Bugtracker zu einem Versionierungssystem standardmäßig dazugehören?

Naja ok hast Recht Standardmässig gehört das nicht dazu, aber es macht für mich halt Sinn, so etwas mit zu implementieren

Ich verstehe momentan nicht, wo der FISI-spezifische Aspekt des Projekts ist.

Die Anforderungsanalyse sehe ich eher bei einem FIAE, da er am besten versteht, was seine Entwicklerkollegen wollen.

Die Installation eines Bugtrackers bzw. CVS ist mMn kein FISI-Projekt.

Die Implementierung einer Software, die beides verbindet, ist wiederum FIAE-Thema.

Wieso soll das bitte ein FIAE Thema sein? Obs auf ner VM oder Hardware läuft, Linux oder Windows als Betriebssystem genommen wird und wie es in das Netzwerk integriert wird, ist für mich ein 100%iges FISI Thema!