pantrag_fiae Projektantrag: Programmierung einer Projektliste

[Ivo_]

Hallo, es wird mich sehr freuen feedback über den Antrag zu bekommen :).

Vielen Dank im Voraus

 

 

Projektantrag: Programmierung einer Projektliste
Author: IM

#
Thema (300 chars):
-
Programmierung einer elektronischen Projektliste zur Unterstützung einer Bauingenieurfirma.
#

#
Termin (Ihr möglicher Bearbeitungszeitraum: 02.03.2017 - 10.05.2017):
-
15.3 - 1.4
#

#
Projektbeschreibung (8000 chars):
-
Bei der Ingenieurbüro für Baustatik und Bauphysik gibt es pro Jahr über 500 Projekte. Die Projekten werden insgesamt von 7 Bauingenieuren, 7 Bauzeichner und zwei Asistenten bearbeitet.

Ausgangssituation:
Die Projektliste besteht aus Papier und wird manuell von einer der Assistenten vervollständigt, wenn ein neues Projekt kommt. Dann Trägt sich einen Ingenieur oder Bauzeichner als bearbeiter ein. Weil es die Liste nur einmal am Schreibtisch vom Assistenten gibt, entstehen keine Doppelt Bearbeitungen. Was aber passieren kann dass ein Projekt unbemerkt eingetragen wird und es keiner bearbeitet, bis rückfragen kommen. Es ist auch schon passiert dass die Liste aus der Papiertonne geholt werden musste, weil sie aus versehen entsorgt wurde. Auf Druck von meiner Seite wurde dann die Liste in eine Excel Tabelle umgewandelt. Jetzt war es möglich einen Backup zu haben und direkt vom Arbeitsplatz die Liste anzusehen. Das hat die Anzahl von unbemerkte Projekte reduziert, weil es jeden direkt Auffällt wenn eine leere Zelle in einer Zeile gibt.

Zielsetzung:
Um noch besser den Überblick über die Projekte zu behalten soll jetzt eine Anwendung geschrieben werden, die die Verwaltung übernimmt.

Die Anwendung soll folgende Aufgaben übernehmen:
1: Alle Mitarbeiter sollen sich registrieren und anmelden können. Es gibt keine Berechtigungen, alle können immer genau das gleiche. 
2: Erstaufnahme von neuen Projekten so dass diese für alle Mitarbeiter sichtbar sind. Bei der Erstaufnahme soll ein Erinnerungsdatum eingetragen werden, wenn der Projekt bis dahin nicht in Bearbeitung ist, wird eine Erinnerung an alle Mitarbeiter geschickt.
3: Ein Mitarbeiter kann einen Projekt wählen und Stunden drauf verbuchen, damit wird ein Projekt in Bearbeitung gesetzt. Diese Buchungen sind immer für alle sichtbar und dienen der Zeiterfassung.
4: Ein Mitarbeiter kann einen Projekt abschließen.

Ich übernehme alleine die Projektausführung. Das bedeutet ich übersetze alle Anforderungen in einem Softwaresystem die sie alle ausfüllt.

Strukturplan:
Der Projekt wird agil entwickelt werden. Weil die Zeit für die Bearbeitung fest ist wird für die Durchführung Scrum benutzt. Ich erstelle in der Planungsphase alle User Stories und pflege die in den Backlog ein. Die Stories bilden den Software ab und werden mit dem Stakeholder (der Ingenieurfirma) abgesprochen. Wenn keine offene Fragen mehr sind wird mit der Abarbeitung des Projekts angefangen. 
Die Sprintlänge soll so gewählt werden dass es ein paar potenzial Lieferbare Stücke gibt die dann immer verbessert werden bis. Bei sieben volle Arbeitstage stehen insgesamt 56 Stunden zur Verfügung. Deswegen denke ich dass eine Sinnvolle Sprintlänge zwei Tage wäre, dann hätte man drei volle Sprints und einen Tag um Abschlussarbeiten zu erledigen und den Projekt abzugeben. Ein weiterer Vorteil vom Agilen vorgehen ist dass man die Arbeit tatsächlich nach Use Cases trennt und nach Sprintende ein funktionsfähigen Software Stück hat, was tatsächlich den gewünschten Mehrwert bietet.

#

#
Projektumfeld (3000 chars):

Das Projekt wird zur interne Nutzung in der Firma Entwickelt. Die Entwicklung wird unter stendiger Kommunikation mit den Stakeholdern entwickelt.
#

#
Projektphasen (3000 chars):
-
Analyse und Planung: 10h
Kundenanforderungen aufnehmen (Epic): 2h
Prüfung der unterschiedlichen Varianten und Entscheidungsfindung: 1h
Wirtschaftlichkeitsanalyse: 1h
Epic in User Stories aufteilen: 3h
Mockups für die Einzelne User Stories deffinieren: 2h
Stories und Mockups Vorstellung und Freigabe abholen: 1h
-
Implementierung: 52h
Aus Use Stories Interne APIs deffinieren: 1h
Aus Use Stories Public API deffinieren: 1h
Interne API Configuration Managment: 1h
Unit Tests Configuration Managment: 1h
Interne API Datenbank: 2h
Unit Tests Datenbank: 1h
Interne API Logik: 25h
Unit Tests Logik: 5h
GUI: 10h
Integration Tests: 5h
-
Dokumentation: 6h
Projektdoumentation: 5h
Kundendokumentation: 1h
-
Präsentation und Übergabe: 1h
Inbetriebnahme: 1h
Gesamtsumme: 70 h
#

#
Dokumentation (3000 chars):

- Backlog
- Bearbeitungsübersicht
- Mockups
- Screenshots der Anwendung
- Testergebnisse
- Benutzerdokumentation
#

#
Anlagen (PDF 200MB):
keine
#

#
Präsentationsmittel (250 chars):
keine zusätzliche.
#

[mapr]

Grob überflogen, aber schau bitte mal auf die Rechtscheibung.

[Thanks-and-Goodbye]

Für den FiAE stehen zwar 70 Stunden (also rund 2 Wochen) zur Verfügung. Allerdings sollte der Ausführungszeitraum grösser sein - es kann ja sein, dass man auf Zuarbeit von Personen an Projektschnittstellen warten muss.

[Ivo_]

OK guter Hinweis, ist bei mein Projekt konkret nicht der Fall, aber ich werde der Zeitraum vergrössern.

Bearbeitet 22. Februar 2017 von Ivo_

[etreu]

Um Himmels willen lass die Verweise auf Scrum raus.

• ein 2 Tage Sprint macht überhaupt keinen Sinn
• kein Grooming, keine Retrospektive, ...
• Scrum für eine Person? Es gibt empfohlene Mindestgrößen für Teams, und die liegt deutlich über 1

Programmiersprache, Zielumgebung, bestehende Systeme, ...?

Was ist mit manuellem Testen?

Bearbeitet 24. Februar 2017 von etreu