Template für Projektmanagement eingecheckt
This commit is contained in:
parent
dd71e467a4
commit
4270c085c0
255
example/90-Projektplan.md
Normal file
255
example/90-Projektplan.md
Normal file
@ -0,0 +1,255 @@
|
|||||||
|
# Projekthandbuch
|
||||||
|
\textauthor{Schueler XY}
|
||||||
|
|
||||||
|
## Entwicklungsplan
|
||||||
|
|
||||||
|
### Projektauftrag
|
||||||
|
|
||||||
|
Hier beschreiben Sie die allgemeinen Informationen zu Ihrem Maturaprojekt. Hier beschreiben sie den Projektkontext, nämlich die Ausgangssituation und Problembeschreibung
|
||||||
|
|
||||||
|
|
||||||
|
#### Projektziele
|
||||||
|
|
||||||
|
Das Projektziel beschreibt den erwünschten Zustand (Sollzustand) nach dem erfolgreichen Abschluss des Projektes. Das Ziel wird wohlbedacht formuliert und durch aktives Handeln aller Projektbeteiligten erreicht. Projektziele sollten gemeinsam mit allen Projektbeteiligten erarbeitet werden.
|
||||||
|
|
||||||
|
#### Nicht-Ziele bzw. nicht Inhalte
|
||||||
|
|
||||||
|
Nicht-Ziele sind aus mehreren Gründen wichtig. Erstens helfen sie beim Erwartungsmanagement. Zweitens schaffen sie Klarheit darüber, was erledigt werden soll. Und drittens erhöhen Nicht-Ziele die Transparenz. Denn wenn man schon früh im Projekt explizit die Bereiche definiert, die das Projekt nicht bearbeiten soll, kann dadurch eine Diskussion über genau diese Randbereiche entstehen.
|
||||||
|
|
||||||
|
#### Projektnutzen
|
||||||
|
|
||||||
|
Wie soll ein Außenstehender ein Projekt genehmigen, wenn nicht klar formuliert ist, WARUM das Projekt überhaupt durchgeführt werden soll? Auch hier ist es wichtig, möglichst konkret zu werden. Einen Projektnutzen z.B. mit „neueste Technik“ zu bezeichnen, ist nicht ausreichend.
|
||||||
|
|
||||||
|
#### Projektauftraggeber/in
|
||||||
|
|
||||||
|
Hier beschreiben Sie wer der Projektauftraggeber ist. Falls es eine externe Firma ist können Sie hier eine kurze Beschreibung des Unternehmens (sofern Projektrelevant) einfügen.
|
||||||
|
|
||||||
|
#### Projekttermine
|
||||||
|
|
||||||
|
Welche Termine sind Fixtermine und was sollte an diesen Terminen stattfinden ? Beispiele hierfür sind z.B: Präsentationen, Projektende, Zwischenabgaben, fest eingeplante Besprechungen / Reviews (die auch Projektrelevant sind) die auf keinen Fall vergessen werden dürfen
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
| Termin | Inhalt |
|
||||||
|
|-----------:|:--------------------------------|
|
||||||
|
| 2020-12-24 | Weihnachten |
|
||||||
|
| 20XX-12-24 | Projektstart |
|
||||||
|
| 20XX-10-24 | Projektpräsentation |
|
||||||
|
| 20XX-10-24 | Erreichung Meilenstein I |
|
||||||
|
| 20XX-10-24 | Erste Zwischenpräsentation |
|
||||||
|
| 20XX-10-24 | Erreichung Meilenstein II |
|
||||||
|
| 20XX-10-24 | Erreichung Meilenstein III |
|
||||||
|
| 20XX-10-24 | Zweite Zwischenpräsentation |
|
||||||
|
| 20XX-10-24 | Abgabe Endversion an Betreuer |
|
||||||
|
| 20XX-10-24 | Abgabe Gebundene Version |
|
||||||
|
| 20XX-10-24 | ... |
|
||||||
|
|
||||||
|
: Projektterminübersicht
|
||||||
|
|
||||||
|
|
||||||
|
#### Projektkosten
|
||||||
|
|
||||||
|
Hier dokumentieren Sie welche Kosten fallen Für Ihr Projekt an und wer kommt für diese Kosten auf ?
|
||||||
|
|
||||||
|
| Meilenstein | Kostenart | Menge | Preis | Gesamtkosten | Deckung durch |
|
||||||
|
|:-------------|:---------:|:------:|--------:|-------------:|---------------|
|
||||||
|
| Prototyp | Personal | 10.00 | 15.00 | 150.00 | Schüler |
|
||||||
|
| Prototyp | Hardware | 1 | 254.00 | 254.00 | Projektpartner|
|
||||||
|
| DA-Schreiben | Druck | 3 | 26.00 | 53.00 | Schüler |
|
||||||
|
|
||||||
|
: Geplante Projektkosten
|
||||||
|
|
||||||
|
Am ende sollten Sie eine Projektkostensumme ermitteln und hier angeben damit man sagen kann
|
||||||
|
__Das Projekt kostet in Summe so und so viel Euro__.
|
||||||
|
|
||||||
|
|
||||||
|
Am Ende der Diplomarbeit fügen Sie hier noch eine Liste der tatsächlich angefallenen Kosten ein.
|
||||||
|
|
||||||
|
#### Projektrisiken
|
||||||
|
|
||||||
|
Hier geben Sie an welche Risiken auf Ohr Projekt zutreffen können, und auch wie wahrscheinlich es ist das dieses Risiko eintritt.
|
||||||
|
Eine Übersicht über Risiken finden sie hier: https://projekte-leicht-gemacht.de/blog/pm-in-der-praxis/130-projektrisiken-beispiele/
|
||||||
|
|
||||||
|
Hier ein Beispiel:
|
||||||
|
|
||||||
|
| Risiko | EW | Auswirkungen | Maßnahmen |
|
||||||
|
|:--------------:|:---:| :----------------|:--------------|
|
||||||
|
| Überziehen der Kosten | 15% | Erhöhte Kosten für Schüler | Budgetierung |
|
||||||
|
| Ungenaue Schätzungen | 30% | Ungenaue Schätzungen führen zu Problem bezüglich Terminen und Budget. | Schätzungen mit Fachkollegen absprechen|
|
||||||
|
| Verzögerungen beim Aufbau von Hard- und Software | 10% | Prototyp wird nicht rechtzeitig zur Endpräsentation fertig | Früh genug anfangen |
|
||||||
|
|
||||||
|
: Projektrisiken
|
||||||
|
|
||||||
|
### Projektorganisation
|
||||||
|
|
||||||
|
#### Projektbeteiligte
|
||||||
|
Hier wird definiert wer (welche Personen) an diesem Projekt beteiligt im Prinzip beteiligt ist.
|
||||||
|
|
||||||
|
| Vorname | Nachname | Organisation | Kontaktinfos |
|
||||||
|
|:------------|:-------------|:-------------|:------------------|
|
||||||
|
| Joltawan | Barodscheff | HTL Leoben | jb@htl-leoben.at |
|
||||||
|
| Frank | Borland | Firma XY | frank@borla.nd |
|
||||||
|
| ... | ... | ... | ... |
|
||||||
|
|
||||||
|
: Projektbeteiligte
|
||||||
|
|
||||||
|
Unter Kontaktinfos können neben der Emailadresse natürlich auch noch andere Informationen wie Telefonnunmmer, Postanschrift, usw. stehen. ... Im Prinzip alles was notwendig ist um die Person zu erreichen wenn es notwendig ist.
|
||||||
|
|
||||||
|
#### Projektrollen
|
||||||
|
|
||||||
|
Hier werden den Kontakten von oben konkrete Rollen zuewiesen.
|
||||||
|
|
||||||
|
| Projektrolle | Rollenbeschreibung | Name |
|
||||||
|
|------------------------|------------------------|-------------------|
|
||||||
|
| Projektleiter | Verantwortlicher für Einhaltung des Projektrahmens | Joltawan Barodscheff |
|
||||||
|
| Auftraggeber | Auftraggeber der internen Diplomarbeit | Frank Borland |
|
||||||
|
| Betreuer | Schulischer Betreuer | G. Hutter |
|
||||||
|
| Betreuer | Schulischer Betreuer | A. Poetscher |
|
||||||
|
|
||||||
|
: Projektrollen
|
||||||
|
|
||||||
|
Gerne können Sie hier auch noch zusätzlich eine Grafik oder ein Organisationsdiagramm einbauen.
|
||||||
|
|
||||||
|
![Projektorganisationsdiagramm](img/projektorganisation.png){width=50%}
|
||||||
|
|
||||||
|
### Vorgehen bei Änderungen
|
||||||
|
|
||||||
|
Hier dokumentieren sie betreffend des Meilensteinplans oder der Anwendungsfälle:
|
||||||
|
|
||||||
|
* Wer wird informiert,
|
||||||
|
* wer muss zustimmen,
|
||||||
|
* wo werden die Änderungen wie vermerkt?
|
||||||
|
|
||||||
|
Das dient in erster Linie dazu um ein einheitliches Vorgehen definiert zu haben.
|
||||||
|
|
||||||
|
## Meilensteine
|
||||||
|
|
||||||
|
Der Begriff taucht im Projektmanagement sehr häufig auf. Meilensteine sind wichtige Punkte im Projektverlauf. Oft werden sie auch als Prüfpunkte bezeichnet.
|
||||||
|
|
||||||
|
Generell kann ein Meilenstein ein Ereignis sein, an dem
|
||||||
|
|
||||||
|
* etwas abgeschlossen ist,
|
||||||
|
* etwas begonnen wird oder
|
||||||
|
* über die weitere Vorgehensweise entschieden wird
|
||||||
|
|
||||||
|
Meilensteine werden meist am Ende von Projektphasen definiert. Auch innerhalb von Phasen kann es zusätzliche Meilensteine geben.
|
||||||
|
|
||||||
|
Meilensteine verlaufen nie über eine Zeitdauer. Nie. Sie sind lediglich Entscheidungspunkte
|
||||||
|
|
||||||
|
Hier ein Beispiel wie die Meilensteine im Fall einer aussehen können
|
||||||
|
|
||||||
|
### 2020-09-15: Projektmanagement abgeschlossen
|
||||||
|
|
||||||
|
- Projekthandbuch ist fertig
|
||||||
|
- Serverinfrastruktur ist hergestellt
|
||||||
|
- Bestellungen sind abgessendet
|
||||||
|
|
||||||
|
### 2020-11-01: Genehmigung der DA
|
||||||
|
|
||||||
|
- Einreichen des Antrags durch die Schüler/innen
|
||||||
|
- DA Dokumentation wurde ausgefüllt und unterschrieben
|
||||||
|
|
||||||
|
### 2020-11-26: Literaturrecherche abgeschlossen
|
||||||
|
|
||||||
|
- Literatur zum Thema XY gesucht und in bibtex vermerkt
|
||||||
|
- Aktellen Stand der Forschung erhoben
|
||||||
|
- Verschriftlichung des Literaturteils begonnen
|
||||||
|
|
||||||
|
### 2020-12-17: Prototyp ist funktionell
|
||||||
|
|
||||||
|
- DB mit Tabelle für Benutzer.
|
||||||
|
- DB Kommunikation zur Anwendung (inkl. Dokumentation)
|
||||||
|
- Es gibt in der Anwendung einen /Admin/ Benutzer. Dieser Benutzer kann weitere Benutzer in den Rollen /Lehrende/ und bzw. oder /Studierende/ anlegen.
|
||||||
|
|
||||||
|
### 2021-01-10: Applikation fertiggestellt
|
||||||
|
|
||||||
|
- Lehrende sind dazu in der Lage Tests anzulegen.
|
||||||
|
- Studenten können einen ihnen zugewiesenen Test absolvieren.
|
||||||
|
|
||||||
|
### 2021-01-10: Review und Überarbeitung fertig
|
||||||
|
|
||||||
|
- Der Quellcode ist gemeinsam mit den Projektpartnern reviewt
|
||||||
|
- Quellcodedokumentation abgeschlossen (Javadoc)
|
||||||
|
- Projekt baut auf eigenem Buildserver (Continous Integration)
|
||||||
|
|
||||||
|
### 2021-02-03: Diploarbeit fertig verschriftlicht
|
||||||
|
|
||||||
|
- Stilfehler sind behoben
|
||||||
|
- DA Dokumentationsblatt ist unterschrieben, eingescannt und im Hauptdokument enthalten
|
||||||
|
- Praxisteil ist ebgeschlossen und verschriftlicht
|
||||||
|
- Informationen sind im DA Portal eingegeben
|
||||||
|
- Unterschriebene DA Betreuungsprotokolle sind in der DA enthalten
|
||||||
|
- DA liegt dem Betreuer in ausgedruckter Form vor
|
||||||
|
|
||||||
|
|
||||||
|
## Anwendungsfälle
|
||||||
|
|
||||||
|
Hier beschreiben Sie die Anwendungsfälle (=UseCases) Ihrer Anwendung / Diplomarbeit. Dabei sollte die Beschreibung auf hohem Niveau (also ohne implementierungsspezifische Details) erfolgen und typischerweise so benannt sein, wie die Ziele aus Sicht der Akteure heißen: Mitglied anmelden, Geld abheben, Auto zurückgeben.
|
||||||
|
|
||||||
|
Jeder Anwendungsfall wird im selben Muster beschrieben. In den folgenden Absätzen ist zuerst eine allgemeine Beschreibung eines solchen Anwendungsfalls zu finden und dann ein Beispiel dazu.
|
||||||
|
|
||||||
|
Damit man auch versteht wer mit welchem Anwendungsfall agiert bietet es sich an hier eine Übersichtsgrafik zu erstellen:
|
||||||
|
|
||||||
|
![Übersicht Anwendungsfälle](img/anwendungsfalldiagramm.png){width=60%}
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
### Anwendungsfallname
|
||||||
|
Anwendungsfälle haben einen eindeutigen Namen aus dem man auf den Inhalt des Anwendungsfalls schließen kann. Wenn Sie agil arbeiten dann stellt ein Anwendungsfall eine UserStory dar welche im Backlog liegt und im Laufe des Projekts (in einem Sprint) abgearbeitet wird.
|
||||||
|
|
||||||
|
#### Kurzbeschreibung
|
||||||
|
Hier erfolgt eine kurze Beschreibung, was im Anwendungsfall passiert. Kurz bedeutet, dass es zwei oder drei Zeilen sind, selten mehr.
|
||||||
|
|
||||||
|
#### Trigger
|
||||||
|
Der fachliche Grund bzw. die Gründe dafür, dass dieser Anwendungsfall ausgeführt
|
||||||
|
|
||||||
|
#### Vorbedingung
|
||||||
|
Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt werden kann. Gibt es keine Vorbedingungen, so steht hier "keine".
|
||||||
|
|
||||||
|
#### Nachbedingung
|
||||||
|
Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet wird.
|
||||||
|
|
||||||
|
#### Akteure
|
||||||
|
Akteure sind beteiligte Personen oder Systeme außerhalb (!) des beschriebenen Systems. Z. B. Anwender, angemeldeter Anwender, Kunde, System, Abrechnungsprozess.
|
||||||
|
|
||||||
|
#### Standardablauf
|
||||||
|
Hier wird das typische Szenario dargestellt, das leicht zu verstehen oder der am häufigsten vorkommende Fall ist. An seinem Ende steht die Zielerreichung des Primärakteurs. Die Ablaufschritte werden nummeriert und meist in strukturierter Sprache beschrieben. Ablaufpläne können jedoch ebenfalls benutzt werden, wenn es angebracht erscheint. Mittels der UML können diese Ablaufschritte in Aktivitätsdiagrammen oder Anwendungsfall-orientierten Sequenzdiagrammen dargestellt werden.
|
||||||
|
|
||||||
|
#### Fehlersituationen
|
||||||
|
Dies sind Szenarien, die sich außerhalb des Standardablaufs auch bei der (versuchten) Zielerreichung des Anwendungsfalls ereignen können. Sie werden meistens als konditionale Verzweigungen der normalen Ablaufschritte dargestellt. An ihrem Ende steht ein Misserfolg, die Zielerreichung des Primärakteurs oder eine Rückkehr zum Standardablauf.
|
||||||
|
|
||||||
|
#### Systemzustand im Fehlerfall
|
||||||
|
Der Zustand, der nach einem erfolglosen Durchlauf des Anwendungsfalls erwartet wird.
|
||||||
|
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
### Benutzer Anlegen
|
||||||
|
|
||||||
|
#### Kurzbeschreibung
|
||||||
|
Der Benutzer "Admin" kann auf Anfrage einen neuen Benutzer als "Lehrende" und bzw. oder "Studierende" anlegen
|
||||||
|
|
||||||
|
#### Trigger
|
||||||
|
Admin legt auf Anfrage eines Benutzers einen neuen Account an
|
||||||
|
|
||||||
|
#### Vorbedingung
|
||||||
|
Benutzer als "Admin" angemeldet
|
||||||
|
|
||||||
|
#### Nachbedingung
|
||||||
|
Es existiert ein Eintrag in der DB Benutzer Tabelle für den neu erstellten Benutzer. (Dieser kann sich anschließend in der Anwendung anmelden)
|
||||||
|
|
||||||
|
#### Akteure
|
||||||
|
* Admin
|
||||||
|
|
||||||
|
#### Fehlersituationen
|
||||||
|
Admin bricht die Aktion ab
|
||||||
|
|
||||||
|
#### Systemzustand im Fehlerfall
|
||||||
|
Benutzer wird nicht angelegt und wird verworfen
|
||||||
|
|
||||||
|
#### Standardablauf:
|
||||||
|
|
||||||
|
1. Admin drückt Button, um einen neuen Benutzer anzulegen
|
||||||
|
2. Es öffnet sich ein Formular, indem die nötigen Benutzer-Informationen eingegeben werden (Name, Adresse, Telephonnummer, E-Mail, Geburtsdatum, Passwort-Hash, Rolle). Der neue Benutzer muss mindestens einer der Rollen "Lehrende" und "Studierende" angehören
|
||||||
|
|
||||||
|
#### Alternativabläufe:
|
||||||
|
|
||||||
|
* Admin drückt den Button, um die Aktion abzubrechen
|
52
example/95-Projektdokumentation.md
Normal file
52
example/95-Projektdokumentation.md
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
\newpage
|
||||||
|
## Dokumentation
|
||||||
|
|
||||||
|
Im Abschnitt Projektdokumentation können Sie mit Hilfe eines Projektmanagementwerkzeuges Ihrer Wahl die Projektumsetzung dokumentieren. (Also ein fortlaufender Projektfortschrittsbericht)
|
||||||
|
|
||||||
|
Normalerweise werden Sie die UserStories in mehrere SubTasks zerreissen und dann in einem agilen verfahen (Scrum, Kanban, was auch immer ihnen am geeignetsten erscheint) abarbeiten. Dazu können Sie natürlich eine Softwahre Ihrer Wahl verwenden.
|
||||||
|
|
||||||
|
Am Ende sollten sie aber für jeden Projektabschnitt (Das ist die Zeit zwischen den Meilensteinen) eine Dokumentation entstehen aus der ersichtlich ist
|
||||||
|
|
||||||
|
* Berichtszeitraum
|
||||||
|
* Durchgeführte Arbeiten im Berichtszeitraum sowie die Aufwände der einzelnen Personen
|
||||||
|
* Projektstatus (Im Plan, Schwierigkeiten, Risiko)
|
||||||
|
* Gesamtstatus sowie die möglicherweise notwendigen Maßnahmen für
|
||||||
|
- Leistungsziele
|
||||||
|
- Terminziele
|
||||||
|
- Kostenziele
|
||||||
|
- Teamarbeit
|
||||||
|
* Nächste Schritte und notwendige Entscheidungen
|
||||||
|
|
||||||
|
Im folgenden Abschnitt ist ein solcher Fortschritt illustriert.
|
||||||
|
|
||||||
|
### Projektfortschritt 01. Juni bis 05. August 2020
|
||||||
|
|
||||||
|
#### Gesamtstatus
|
||||||
|
|
||||||
|
* Das Projekt befindet sich derzeit im Plan.
|
||||||
|
* Es wurden alle Teile bestellt und die Hardware dimensioniert
|
||||||
|
* Bei den Lieferungen hat es leichte Verspätungen gegeben
|
||||||
|
|
||||||
|
|
||||||
|
| Dimension | Status | Maßnahmen |
|
||||||
|
|:--------------------|:------------------|:-----------------------|
|
||||||
|
| Leistungsziele | In Ordnung | keine |
|
||||||
|
| Terminziele | Verzug durch Lieferprobleme | Bei restlichen Teilen Expresslieferung|
|
||||||
|
| Kostenziele | Teile im Budget, Batterie sehr teuer | Günstigere Teile bei der restlichen Hardware verwenden |
|
||||||
|
| Teamarbeit | optimal | keine |
|
||||||
|
|
||||||
|
:Projektstatus am 2020-08-05
|
||||||
|
|
||||||
|
#### Notwendige Entscheidungen
|
||||||
|
|
||||||
|
* Die Zusammenbauphase muss etwas verschoben werden und startet nun um 14 Tage später. Das hat keinen Einfluss auf den Endtermin.
|
||||||
|
|
||||||
|
#### Nächste Schritte
|
||||||
|
|
||||||
|
* Abklären ob die Expressbestellungen im Budget sind
|
||||||
|
* Start dder Implementierungsphase
|
||||||
|
|
||||||
|
: Projektstatus Stand 05. August 2020
|
||||||
|
|
||||||
|
|
||||||
|
|
25
example/99-Projektabschlussbericht.md
Normal file
25
example/99-Projektabschlussbericht.md
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
\newpage
|
||||||
|
## Projektabschlussbericht
|
||||||
|
|
||||||
|
### Erfolgsmessung
|
||||||
|
|
||||||
|
#### Erreichung Leistungs-/Qualitätsziele
|
||||||
|
Hier beschreibe sie ob Sie das ursprünglich vereinbarte Ziel erreicht haben oder nicht. Falls es zu irgendwelchen Abweichungen gekommen ist dann beschreiben Sie warum das so war und was Sie dagegen unternommen haben.
|
||||||
|
|
||||||
|
#### Erreichung Terminziele
|
||||||
|
Hier dokumentieren Sie ob Sie Ihre gesteckten Termine für die Meilensteine einhalten konnten. Falls es zu verzügen gekommen ist argumentieren sie hier warum das so war.
|
||||||
|
|
||||||
|
#### Erreichung Kosten-/Aufwandsziele
|
||||||
|
Hier dokumentieren Sie ob Sie Ihr eingangs geplantes Budget einhalten konnten oder nicht. Wenn nicht geben Sie hier bitte eine Begümdung dafür an.
|
||||||
|
|
||||||
|
### Refelxion / Lessons Learned
|
||||||
|
|
||||||
|
#### Teamarbeit
|
||||||
|
Hier dokumentieren sie Ihre Erkenntnisse bezüglich der Teamarbeit in Ihrem Projekt. Was ist gut gelaufen und was schlecht ?
|
||||||
|
|
||||||
|
#### Projektmanagement
|
||||||
|
Hier dokumentieren sie Ihre Erkenntnisse bezüglich des Projektmanagements.
|
||||||
|
|
||||||
|
#### Sonstige Lernerfahrungen
|
||||||
|
Hier dokuentieren was sie im Bezug auf das Projekt sonst noch so gelernt haben
|
||||||
|
|
BIN
example/img/anwendungsfalldiagramm.png
Normal file
BIN
example/img/anwendungsfalldiagramm.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 42 KiB |
BIN
example/img/projektorganisation.png
Normal file
BIN
example/img/projektorganisation.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 62 KiB |
Loading…
Reference in New Issue
Block a user