forked from Hg/htlle-da-vorlage
256 lines
12 KiB
Markdown
256 lines
12 KiB
Markdown
# 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.
|
|
|
|
{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:
|
|
|
|
{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
|