# Projektorganisation Übung 01

## Projektbeschreibung, Projektziele

*Geben Sie eine Einführung in das Projekt, in der Sie auch auf die gesetzten Ziele des
Projekts eingehen. Handelt es sich um ein sachzielorientiertes oder prozessorientiertes
Projekt? Welche Ergebnisse/Leistungen sollen durch das Projekt erbracht werden?*

In unserem Projekt geht es um eine Software, die dazu beitragen soll, unsere Meere von Schadstoffen frei zu halten. Der Auftraggeber will mit der Software Ausschreibungen für Satellitenbilder von gewissen Bereichen des Meeres stellen. Provider von Satellitenbildern sollen dann Angebote einreichen können, und nach Annahme eines Angebotes auch die Bilder uploaden können. Die Bilder sollen dann automatisch ausgewertet werden und, im Fall von Verunreinigungen (z.B. Öl), sollen die verantwortlichen Behörden benachrichtigt werden.
Die Implementierung der Software wird in 3 Sub-Projekte unterteilt. Die Sub-Projekte sind Web-Plattformen für das Anfragen von Bildern, die Auswertung dieser Bilder und das Benachrichtigen der korrekten Behörden. Im weiteren behandeln wir das 2. Sub-Projekt, also das Auswerten der Bilder, genauer. Wenn es sinnvoll ist, erwähnen wir das gesamte System, bzw. die anderen beiden Sub-Projekte.
Das Projekt umfasst Entwicklung, Hosting und Wartung einer Web-Plattform, daher handelt es sich um ein sachzielorientiertes Projekt.

## Projektumfeld, Rahmenbedingungen

*Beschreiben Sie das Projektumfeld samt den Rahmenbedingungen für das Projekt.
Handelt es sich um ein internes oder externes Projekt? Gehen Sie auf das Unternehmen,
das das Projekt durchführt (Auftragnehmer), als auch auf das Unternehmen, für das das
Projekt durchgeführt wird (Auftraggeber/Kunde) bzw. die Unternehmen, die
Anwender/Nutzer des Projektergebnisses sind, ein. Welchen Zusammenhang hat das
Projekt mit der Unternehmensstrategie und den Unternehmenszielen? Welche internen
oder externen Faktoren sind im Projekt zu beachten? Gibt es zeitliche oder örtliche
Rahmenbedingungen? Welche technischen Rahmenbedingungen (bspw. Hardware, auf
der die zu entwickelnde Software laufen soll) sind zu beachten? Hat das Projekt
Einfluss auf Chancen und Risiken von anderen Projekten im Unternehmen? Gibt es
einen Abstimmungsbedarf mit anderen Projekten?*

Es handelt sich um ein externes Projekt, der Auftragnehmer ist die (fiktive) Softwareentwicklungsfirma Wolkenflug GmbH. Der Auftraggeber/Kunde ist die (fiktive) European Maritime Safety Agency (EMSA), eine EU-Organisation, die unter anderem für die Überwachung der Schadstoffbelastung der an Europa angrenzenden Meere verantwortlich ist. Die EMSA ist gleichzeitig der Auftraggeber und der Anwender der resultierenden Software.

Die Wolkenflug GmbH entwickelt Individualsoftware für Unternehmenskunden und Kunden im öffentlichen Sektor (z.B. EMSA). Ein Teil der Unternehmensstrategie ist es, ein EU-weit bekannter Anbieter für Individualsoftware im öffentlichen Sektor zu werden, und die erfolgreiche Abwicklung des EMSA-Projektes wäre ein Teil davon.

Zwischen den Sub-Projekten gibt es natürlich einen hohen Abstimmungsbedarf (z.B. API), besondere Zusammenhänge mit anderen Projekten gibt es nicht. Das Projekt hat, abgesehen von einem gewissen Bedarf an Personal- und Hardwareressourcen, auch keinen Einfluss auf die Chancen und Risiken von anderen Projekten im Unternehmen.

Weil die 3 Sub-Projekte von unterschiedlichen, multifunktionalen Teams durchgeführt werden, sind die Zusammenarbeit und Kommunikationswege zwischen diesen Teams wichtige interne Faktoren. Zusätzlich müssen auch persönliche Faktoren innerhalb der Teams beachtet werden.

Nachdem es sich um ein Projekt im öffentlichen Sektor handelt, ist ein externer Faktor die politische Lage der EU. Ein weiterer externer Faktor sind die langen Kommunikationswege innerhalb der EMSA, wodurch Entscheidungsprozesse verlangsamt werden.

Es gibt keine fixe Deadline für die Fertigstellung des Projekts, es wird allerdings jährlich ein neuer Vertrag (für das gesamte System, nicht für Sub-Projekte) verhandelt, der vom nachweisbaren Fortschritt des Projektes abhängt. Örtliche Rahmenbedingungen gibt es keine, alle Meetings werden online abgehalten.

Ab dem ersten Release der Software werden zusätzliche Server-Ressourcen für ein Production Environment benötigt, da es Teil des Projektes ist, die Software zu hosten. Bis dahin wird nur ein interner Test-Server betrieben.

## Projektmerkmale

*Charakterisieren Sie das Projekt anhand der im Skript behandelten Projektmerkmale.
Darüber hinaus können Sie natürlich je nach Projektsituation noch weitere Merkmale
heranziehen*

- Umfang
- Das behandelte Sub-Projekt ist eine Web-Plattform für die Auswertung von Satellitenbildern mittels Machine Learning. Der Arbeitsaufwand wird in etwa 800-1200 Issues (= Einzelaufgaben) aufgeteilt.
- Jedes Sub-Projekt wird von einem Team aus ca. 5-10 Personen durchgeführt.
- Der Auftragswert des gesamten Projekts beläuft sich auf ca. 6 Mio. € pro Jahr.
- Die Sub-Projekte sind ähnlich viel Aufwand, daher werden jedem Sub-Projekt 2 Mio. € pro Jahr zugewiesen.
- Das Projekt wird quartalsweise von EMSA bezahlt.
- Dauer
- Projektbeginn ist 01.01.2024.
- Bis zum ersten "stable release" werden ca. 4 Jahre geschätzt.
- Besonderheit
- Es ist ein überdurchschnittlich großes Projekt für die Firma Wolkenflug, aber es werden hauptsächlich Technologien verwendet, mit denen die Firma schon mehrere Jahre Erfahrung hat.
- Komplexität
- Alle 3 Sub-Projekte werden gleichzeitig entwickelt. Da sie stark voneinander abhängen ist die Komplexität vor allem am Anfang als sehr hoch einzuschätzen.
- Schwierigkeit
- Wolkenflug hat mit den zu verwendenden Technologien und mit Projekten im öffentlichen Sektor schon mehrere Jahre Erfahrung.
- Wirtschaftlich und personell ist das Projekt nicht außergewöhnlich schwierig im Vergleich zu anderen Projekten des Unternehmens.
- Organisatorisch ist das Projekt durch die große Anzahl an Aufgaben und Koordination der 3 Teams überdurchschnittlich schwierig.
- Es gibt keine harte Deadline, Verträge werden jedes Jahr neu verhandelt.
- Eine Schwierigkeit sind die langen Kommunikationswege auf Seiten des Kunden, diese müssen beachtet werden, wenn zusätzliche Bestätigungen/Einwilligungen benötigt werden.
- Bedeutung
- Damit Wolkenflug ein bedeutender Softwareanbieter in Europa werden kann, ist ein großer Kunde wie die EMSA von großer Bedeutung.
- Der Projektumsatz verglichen mit dem Gesamtumsatz ist überdurchschnittlich, aber nicht extrem hoch (6 Mio. / 120 Mio. = 5%).
- Durch erfolgreiche Abwicklung des Projekts wird ein langfristiger Partner und dadurch auch kontinuierlicher "cashflow" gewonnen, außerdem könnten sich später noch weitere Projekte der EMSA für Wolkenflug ergeben.
- Risiko
- Hauptrisiko besteht bei Vertragserneuerung, gefährdet durch z.B. Unzufriedenheit des Kunden oder Konkurrenz.
- Technisches Realisierungsrisiko: Technisch sollte es keine Komplikationen geben.
- Verwertbarkeitsrisiko: Das Projekt wird individuell für den Kunden entwickelt, somit ist die Verwertbarkeit ganz auf seiner Seite.
- Zeitrisiko: Da es keine bestimmte Deadline gibt, ist das Zeitrisiko gering, aber es muss trotzdem erwartungsgerecht viel Leistung erbracht werden.
- Aufwandsrisiko: Insgesamt ist das Aufwandsrisiko für Wolkenflug gering, da der Vertrag jährlich erneuert werden muss.
- Zielsetzungsrisiko: Es ist alle 3 Wochen ein "Sprint Retrospective" Meeting mit Aufsicht der EMSA geplant, daher werden Abweichungen von der Zielsetzung schnell erkannt.
- Kosten
- Pro Jahr werden 6 Mio. € verrechnet.
- Bei 4 Jahren Entwicklungszeit ergibt sich ein Auftragswert von 24 Mio. € für den ersten Release.
- Kontinuität
- Hier 1 Sub-Projekt-Team, andere Teams sind ähnlich zusammengesetzt
- Sporadisch: 2 (Technical Architect, UI/UX-Designer)
- Häufig: 1 (Site Reliability Engineer)
- Kontinuierlich: 4-5 (Projektleiter, Requirements Engineer, ML Engineer, 2 Softwareentwickler)
- Intensität
- Mit dem geschätzten Aufwand und der Teamgröße sollten die meisten Teammitglieder vollständig ausgelastet sein.
- Einige spezialisierte Aufgaben sind nur in der Anfangsphase des Projekts nötig, hier sind die spezialisierten Mitarbeiter/innen aber auch vollständig ausgelastet, jedoch nicht bis zum Ende des Projekts.
- Falls im Laufe des Entwicklung Bedarf für ein größeres Team entsteht, können Mitarbeiter aus anderen Projekten verschoben werden, um eine Überlastung zu verhindern. Die anderen Projekte verwenden die gleichen Technologien, daher ist ein solcher Wechsel billiger, als neue Mitarbeiter einzustellen.
- Anzahl
- Insgesamt werden ca. 60 Projekte parallel abgewickelt.
- Ausschließlich Projekttätigkeit, keine übermäßige Belastung.
- Organisations- und Führungsverständnis
- Wolkenflug zeichnet sich durch hohe Flexibilität aus.
- Mitarbeiter können ohne Probleme zwischen Projekten wechseln.
- Konfliktlösungsfähigkeit ist sehr ausgeprägt und die Kooperationsbereitschaft ist durch ein gutes Arbeitsklima auch vorhanden.

# Projektorganisation Übung 02
Damit unser Projekt den Angaben entspricht, werden wir hier nur das Sub-Projekt über Auswertung der Satellitenbilder genauer betrachten. Hierbei geht es darum, die von anderen Komponenten des Systems erhaltenen Bilder mittels Machine Learning auszuwerten.
Das Sub-Projekt trägt den Namen "sea pollution evaluation system" (SPES).

## Projektorganisationsform (Organigramm)
*Beschreiben Sie die für das Projekt gewählte Projektorganisationsform (kann auch eine
Mischform sein bzw. können für unterschiedliche Phasen/Projektabschnitte
unterschiedliche Formen zum Einsatz kommen) und geben Sie ein entsprechendes
Organigramm an. Motivieren Sie, warum Sie diese Form gewählt haben und geben Sie
Vor- und Nachteile in Bezug auf Ihre Projektsituation an.*

Dieses Projekt ist als ein Matrix-Projekt organisiert. Diese Organisationsform eignet sich für das Projekt, weil es eines von mehreren Sub-Projekten ist und sich das Projekt sehr nach Kunden richtet. Einer der Vorteile im Vergleich zu anderen Organisationsformen, wie zum Beispiel einer Task Force, ist, dass dieses relativ große Projekt nicht dauerhaft Mitarbeiter beansprucht, die vielleicht woanders gebraucht werden könnten. Jedoch könnte die Mehrfachunterstellung des Personals zu erhöhtem Stress führen und kann zu organisatorischen Schwierigkeiten beim Vereinbaren von Meetings etc. führen.

Im folgenden Organigramm sind die Mitarbeiter in der Reihenfolge, in der sie im Abschnitt "Projektmitarbeiter" aufgelistet sind, nummeriert.


## Projektleiter, Team
*Beschreiben Sie den Projektleiter und die Projektmitarbeiter. Für das Projekt sollten
zumindest 3 Mitarbeiter und maximal ca. 5 Mitarbeiter eingesetzt werden. Was sind die
wichtigsten Fähigkeiten, die der Projektleiter speziell für dieses Projekt aufweisen soll?
Ist der Projektleiter mit speziellen Kompetenzen oder Anordnungsbefugnissen
ausgestattet? Aus welchen Abteilungen stammen die Projektmitarbeiter, welche
Fähigkeiten und Kenntnisse bringen Sie ins Projekt mit?
Mit welchen anderen Abteilungen, Firmen, externen Beratern etc. ist eine
Zusammenarbeit erforderlich?*

### Projektleiter
Der/Die Leiter/in dieses Projekts ist fachliche/r Experte/in. Er/Sie bringt etwas Management-Erfahrung mit sich, z.B. aus der Leitung von früheren Projekten.
Er/Sie arbeitet neben seinen/ihren PL-Aufgaben selbst an der Systemarchitektur des Projekts (kein Technical Architect im Projektteam).
Weiters unterstützt er/sie seine/ihre Teammitglieder, speziell den/die Junior-Softwareentwickler/in.
Die wichtigsten Fähigkeiten sind:
- Erfahrung in den zu bewältigenden Hauptaufgaben (Kommunikation und Koordination mit ...):
- Projektleiter/innen der anderen Sub-Projekte
- Funktionalen Vorgesetzten seiner Teammitglieder
- Kunden (Sprachkenntnisse - Englisch)
- Lenkungsausschuss
- Erfahrung mit der Leitung eines multifunktionalen Teams, Konfliktlösungsfähigkeit
- Kenntnisse über die Fähigkeiten der Teammitglieder (z.B. durch frühere Zusammenarbeit), Effektive Delegation der Einzelaufgaben
- Verhandlungsgeschick (Verträge müssen, zusammen mit Projektleiter/innen der anderen Sub-Projekte, jährlich neu verhandelt werden)

### Projektmitarbeiter
Unser Projektteam stellt sich aus folgenden 5 spezialisierten Mitarbeitern zusammen:
- Requirements Engineer
- Der/Die Requirements Engineer ist vor allem in den Anfangsphasen des Projekts essenziell. Er/Sie erstellt Tasks und Issues, wobei er/sie die Anforderungen des Kunden in implementierbare Aufgaben für das Team übersetzt.
- Er/Sie arbeitet in der Anfangsphase nur an diesem Projekt, wird sich aber im Laufe des Projektes lösen und auch an anderen Projekten arbeiten.
- Site Reliability Engineer
- Der/Die SRE kümmert sich in der Anfangsphase um das Aufsetzen der Version Control und um Deployment des Projektes. Bei/nach dem Release kümmert er/sie sich darum, dass der Server inklusive aller Container eine mit dem Kunden geregelte minimum up-time erfüllt.
- Er/Sie ist entweder selbst für DevOps aller 3 Sub-Projekte verantwortlich, oder koordiniert sich mit anderen SREs aus seiner/ihrer Abteilung.
- Senior Machine Learning Engineer
- Der/Die ML Engineer arbeitet gemeinsam mit den Fullstack-Softwareentwickler/innen an der Entwicklung der Kernkomponente des Systems: Einem ML-Model zur Auswertung der Satellitenbilder.
- Er/Sie muss tiefes fachliches Wissen und Erfahrung mitbringen, da dieses Modell kritisch für den Projekterfolg ist.
- Er/Sie ist Mitarbeiter/in der Abteilung für AI / Machine Learning, und ist, zumindest für einige Monate nach der Anfangsphase des Projektes, vollständig ausgelastet.
- Senior Fullstack-Software Developer
- Der/Die Senior Softwareentwickler/in bringt Vorerfahrung mit den verwendeten Technologien aus anderen Projekten mit sich.
- Er/Sie ist in allen Phasen des Projektes vollständig ausgelastet, entweder mit der Abarbeitung der komplexesten Einzelaufgaben, oder damit, die weniger erfahrenen Teammitglieder zu unterstützen.
- Junior Fullstack-Software Developer
- Junior Developer sind meist noch nicht so erfahrene Programmierer. Dies ist aber nicht zu unterschätzen, da diese meistens noch als "unbeschriebens Blatt" oft kreative neue Lösungen finden.
- Er/Sie ist in allen Phasen des Projektes vollständig ausgelastet, hauptsächlich mit der Abarbeitung der weniger komplexen Einzelaufgaben.
- Einführung/Unterstützung bekommt er/sie von Senior-Entwickler/in, funktionalem Vorgesetzten, und PL.

All diese Mitarbeiter haben schon Erfahrung mit anderen Software-Projekten, außer der/dem Junior Fullstack-Software Developer, er/sie kann auch neu angestellt sein.
Speziell UI/UX-Designer/in und SRE müssen eng mit anderen Mitarbeiter/innen, die dieselbe Rolle in anderen Sub-Projekten ausführen, zusammenarbeiten. Hier kommen die Vorteile der Matrix-Organisationsform zum Tragen.
Auch bei der/dem ML Engineer ist die Doppelunterstellung sehr sinnvoll, weil dadurch kein PL mit Expertise in ML benötigt wird.

# Projektorganisation Übung 03

## Aufgabenplanung, Zeitplanung
*Achten Sie im Rahmen der Aufgabenplanung auf eine sinnvolle Strukturierung der Vorgänge (Aufgabengliederung). Auf oberster Ebene bietet sich bei Softwareprojekten eine Phasengliederung an, die in vielen Fällen Phasen wie Erarbeiten der Anforderungen an das zu entwickelnde Produkt, Analyse der bestehenden Situation, Entwurf der neuen Softwarelösung, Implementierung, Test, Einführung und Wartung umfasst. Welche Phasen relevant sind, ist von der konkreten Projektsituation abhängig.*

Da unser Projekt ein reines Software Projekt ist, ist eine Phasengliederung für uns in diesen Fall das beste. EMSA besitzt bereits ein Lastenheft, dieses muss von Requirement Engineers zu Tasks/Issues verarbeitet werden werden (für zum Beispiel GitHub, GitLab oder Jira). Des Weiteren müssen Unklarheiten mit dem Projektleiter und Kunden besprochen werden. Dies ist die "**Requirements Specification**" Phase.
Nach der Erstellung der Basis Aufgaben kann bereits die nächste Phase parallel gestartet werden ("**Implementation**" Phase). In dieser Phase wird das ML-Modell trainiert, APIs implementiert, etc.
Sobald das Projekt Teile des Projekts in einem funktionierendem Stand sind kann die "**Implementation Test**" Phase parallel gestartet werden. Software Entwickler müssen während des Implementierens ihren Code immer bereits mit Unit- und Integration-Tests testen. Sobald aber die Test Phase beginnt müssen ebenfalls End-to-End (E2E) Tests programmiert werden.
Falls das Projekt für den ersten "Stable-Release" bereit ist, wird die "**Deployment**" Phase begonnen. Hier ist es wichtig, dass SREs "on-call-duty" haben, was bedeutet, dass auch Ausfälle außerhalb der regulären Arbeitszeiten so schnell wie möglich behoben werden müssen, um eine minimum "up-time" garantieren zu können. Des Weiteren wird in dieser Phase der Fokus darauf gelegt, gröbere "Bugs" zu beheben, die während der ersten Wochen auftreten.
Da unsere Software für den End-User nicht sichtbar ist muss keine Einführung gegeben werden, es sollte aber eine Dokumentation verfasst werden. Dies kann aber problemlos in der letzten Phase "**Maintenance**" erledigt werden. Weiters werden hier Bugs behoben, die erst nach längerer Laufzeit gefunden werden.

*Überlegen Sie, ob spezielle Meetings (interne Meetings, z.B. Präsentationen von Zwischenergebnissen, als auch externe Meetings, z.B. mit Geschäftspartnern, bspw. Meilensteinpräsentationen), Schulungen, Erstellen einer Dokumentation und spezielle Tests (die fortlaufend durchzuführenden Tests müssen dabei nicht berücksichtigt werden) für Ihr Projekt relevant sind. Benötigen Sie Software (externe Komponenten) oder Hardware für Ihre Lösung oder ist eine Zusammenarbeit mit externen Projektpartner vorgesehen? Welche Vorgänge lassen sich daraus ableiten? Zeitaufwände für Fahrtzeiten, Koordinations- und Kommunikationszeiten sowie für fortlaufende Projektmanagementaufgaben müssen nicht explizit berücksichtigt werden.*

Die Implementierung erfolgt agil in 3-wöchigen Sprints. Am Anfang eines solchen Sprints wird ein internes Sprint-Planning Meeting mit dem gesamten Team abgehalten. Am Ende jedes Sprints gibt es eine Sprint Retrospective, bei der Projektfortschritt, aufgetretene Probleme, etc. im Team und mit dem Kunden besprochen werden.

Jedes Quartal oder nach Erreichen eines Meilensteins werden dem Kunden die Zwischenergebnisse präsentiert. Dieses Meeting wird mit PL, Requirements Engineer, einem der Softwareentwickler, und dem Kunden abgehalten.

Da EMSA einen Testplan erstellt, der von unserem Requirements Engineer und Entwicklern ausgearbeitet wird, müssen zur Abklärung von Unklarheiten eventuell auch Meetings stattfinden.

Schulung könnte vor allem für den Junior Fullstack-Software Developer relevant sein.

Dokumentation wird vor allem in der Deployment- und Maintenance-Phase geschrieben, da man während der Entwicklung nicht weiß, was und wieviel sich vielleicht noch ändert. Des Weiteren ist es sehr üblich noch bevor Stable-Release das Projekt nochmal ein "refactoring" zu geben, was ebenfalls Auswirkungen auf die Dokumentation hat.

Folgende Softwaresysteme werden benötigt:
* Issue Tracking System (z.B. Jira)
* Version Control System (z.B. GitLab)
* CI/CD (z.B. GitLab + TeamCity)
* E2E Testing System (z.B. Cypress)
* DBMS (z.B. Oracle)
* ML-Framework (z.B. TensorFlow)

Folgende Hardware wird benötigt:
* Server für staging environment
* Server für production environment

Diese Software- und Hardwaresysteme müssen natürlich aufgesetzt werden, diese Aufgaben übernimmt der/die SRE.

Externe Projektpartner gibt es keine, aber da unser Projekt mit 2 anderen Projekten koordiniert werden muss, sollte es zusätzlich Meetings der 3 Projektleiter/innen geben.

*Die Aufgabenplanung sollte mindestens 50 Aufgaben (das ist das Minimum) auf unterschiedlichem Detaillierungsniveau (unterschiedliche Ebenen im PSP) ergeben.*

*Dokumentieren sie die Aufgabengliederung in Form eines Projektstrukturplans (PSP). Definieren Sie entsprechende Meilensteine und dokumentieren Sie diese in einer Meilensteinliste.*


| Meilenstein | Ereignis | Soll-Termin | Ist-Termin |
|:-----------:|:----------------------------------------------------:|:-----------------:|:----------:|
| 1 | Start des Projekts | 01.01.2024 | |
| 2 | Abschluss Requirements Specification (Ohne Tests) | 01.10.2024 | |
| 3 | Abschluss Requirements Specification (Tests) | 01.03.2025 | |
| 4 | Stable API Implementation | 01.12.2025 | |
| 5 | Stable ML-Modell | 01.06.2026 | |
| 6 | Alpha Release | 01.03.2027 | |
| 7 | Abschluss Implementation Test | 01.10.2027 | |
| 8 | First Stable Release | 01.01.2028 | |

# Projektorganisation Übung 04

## Stakeholderanalyse

| Stakeholder | Entscheidungspotential | Einstellung | Rolle im Projekt |
|--------------------------------------|--------------------------------------|-------------------------|--------------------------------------------------------------------------------------------------------------|
| EMSA | Hoch (Finanziell, Politisch) | Befürworter | Kunde und Endbenutzer des SPES; legt Anforderungen fest und erwartet präzise Ölfleckdetektion in Bildern. |
| Wolkenflug GmbH | Hoch (Finanziell, Technisch) | Befürworter | Projektinhaber und Umsetzer; verantwortlich für Design, Entwicklung, Test und Wartung des Systems. |
| Geschäftsführung | Hoch (Finanziell, Strategisch) | Befürworter | Verantwortlich für die strategische Ausrichtung des Unternehmens; unterstützt das Projekt finanziell. | Innen |
| Betriebsrat | Mittel (Rechtlich) | Neutral bis Befürworter | Interessenvertretung der Mitarbeiter; achtet auf Einhaltung von Mitarbeiterrechten im Projekt. |
| Konkurrenzunternehmen | Mittel (Finanziell, Technisch) | Konkurrenz | Konkurrenzunternehmen im Softwareentwicklungsbereich; könnten den Kunden abwerben (jährliche Vertragserneuerung) |
| Satellitenbildanbieter | Mittel (Technisch) | Neutral bis Befürworter | Liefern entscheidende Bilder für die Analyse; Kooperation für kontinuierlichen Datenfluss erforderlich. |
| Verantwortliche Behörden für die jeweilige Meeresregion | Mittel (Politisch, Technisch) | Neutral bis Befürworter | Empfänger von Warnmeldungen; müssen auf Ölkatastrophen in ihrer Zuständigkeitsregion reagieren.
| Regulierungsbehörden | Mittel (Politisch, Rechtlich) | Neutral bis Befürworter | Setzen Richtlinien und Regulierungen; Überwachen die Einhaltung von Umwelt- und Datenschutzstandards. |
| Umwelt-NGOs und Aktivisten | Niedrig bis Mittel (Gesellschaftlich)| Befürworter | Interesse an Effektivität des SPES; könnten Transparenz und Einhaltung von Umweltstandards fordern. |
| Öffentlichkeit | Niedrig bis Mittel (Gesellschaftlich)| Neutral bis Befürworter | Interesse an Umweltschutz; öffentliche Wahrnehmung und Unterstützung könnten den Projekterfolg beeinflussen.|
| Ölunternehmen und Politiker mit Verbindung zu Ölunternehmen | Mittel (Politisch) | Neutral bis Gegner | Potenzielles Interesse an Minimierung von Ölkatastrophen, aber könnten das Projekt aus wirtschaftlichen Gründen ablehnen.|
| Projektleiter | Hoch (Technisch, Personell) | Befürworter | Leitet das Team, bringt technische und Managementerfahrung ein. Schlüsselrolle. |
| Requirements Engineer | Hoch (Technisch) | Befürworter | Verantwortlich für Erfassung und Dokumentation der Anforderungen; stellt sicher, dass das System den Bedürfnissen entspricht.|
| Site Reliability Engineer | Hoch (Technisch) | Befürworter | Gewährleistet die Zuverlässigkeit und Verfügbarkeit des Systems; |
| Machine Learning Engineer | Hoch (Technisch) | Befürworter | Entwickelt das ML-Modell zur genauen Ölfleckdetektion; Schlüsselrolle. |
| Senior Full-Stack Developer | Hoch (Technisch) | Befürworter | Verantwortlich für die Entwicklung von Front- und Backend-Komponenten; bringt umfassende Entwicklungskenntnisse ein. |
| Junior Full-Stack Developer | Mittel (Technisch) | Neutral bis Befürworter | Unterstützt die Entwicklung von Front- und Backend-Komponenten; lernt und trägt zum Erfolg des Projekts bei. |
| Abteilungen und funktionale Vorgesetzte der Teammitglieder| Mittel bis Hoch (Management) | Befürworter | Unterstützen die Arbeit der Teammitglieder und fördern die Zusammenarbeit im Projekt.|


# Projektorganisation Übung 05

## Planung mit ProjectLibre - Bemerkungen

### Zeitliche Aspekte bei Vorgängen

Vorgänge mit fixer Dauer beinhalten meistens Meetings mit anderen Projektteams oder dem Kunden, z.B. SPES-API planen.

Ein weiterer Sonderfall ist "Uptime sicherstellen (on-call)". Die fixe Dauer ist im Vertrag geregelt (5 Jahre ab v1.0 Release).

Vorgänge mit Termineinschränkungen gibt es nicht, abgesehen vom fixen Projekt-Starttermin am 01.01.2024.

### Annahmen bzgl. Vorgängerbeziehungen

Einige Vorgänge können sich überlappen oder parallel stattfinden:
+ Sammelvorgang Implementation wird gestartet, während der Testplan noch fertiggestellt wird
+ Sammelvorgang Implementation Test läuft parallel zu Implementation, wird gestartet, sobald der Testplan fertig ist
+ Eng verbundene Vorgänge, z.B. Frontend components impl. und Frontend services impl. werden parallel von den selben Mitarbeitern abgearbeitet

### Arbeitsfreie Zeiten/Tage

Es wurde angenommen, dass die Mitarbeiter jedes Jahr ihre gesamten Urlaubstage (25) konsumieren. Diese werden bevorzugt als Brückentage, um Weihnachten, und im Sommer verwendet. Die genauen Tage sind in den ProjectLibre Ressourcenkalendern eingetragen.

Betriebsurlaube, Betriebsausflüge oder dienstfreie Tage sind nicht geplant.

### Ressourcenzuordnung

#### Vorgänge, an denen der Projektleiter arbeitet:


Der Projektleiter nimmt an allen Vorgängen teil, die Meetings mit Kunden oder anderen Projektteams inkludieren.
Weiters ist er bei allen High-Level Planungsaufgaben beteiligt, z.B. Auswahl von Technologien und Systemarchitektur.
Am Vorgang "Hotfixes" sind alle Mitarbeiter beteiligt, auch der Projektleiter. Es gilt, bei Release auftretende Probleme so schnell wie möglich zu beheben.
Der Projektleiter hat weniger fix zugeteilte Vorgänge als andere Mitarbeiter, dass er das Projektteam flexibel bei anderen Vorgängen unterstützen kann.

#### Vorgänge, an denen der Requirements Engineer arbeitet:


Weil kein UI/UX-Designer im Projektteam ist, werden die UI mockups vom RE erstellt.

#### Vorgänge, an denen der Site Reliability Engineer arbeitet:


#### Vorgänge, an denen der Senior Machine Learning Engineer arbeitet:


#### Vorgänge, an denen der Senior Software Engineer arbeitet:


#### Vorgänge, an denen der Junior Software Engineer arbeitet:


#### Projekt-Statistik

Projektanfang ist der 01.01.2024, -ende der 15.01.2032. Das liegt an dem sehr langen Vorgang "Uptime sicherstellen", wenn dieser nicht inkludiert wird, liegt das Ende am 26.08.2027. Ohne vorher erwähnten Vorgang beläuft sich die Projektdauer auf 3 Jahre, 7 Monate und 26 Tage.

Der gesamte Arbeitsaufwand beträgt 12,163 Personenstunden, die Kosten 1.337.310 Euro.

# Projektorganisation Übung 06

### Risikoidentifikation
*Identifizieren Sie zumindest 10 Risiken des Projekts und
beschreiben Sie diese anhand der in den Folien genannten Merkmale.*

1. Name: Falsche oder unvollständige Trainingsdaten
* **Kurzbeschreibung:** Falls in den Trainingsdaten die erhoben werden Fehler sind oder unvollständig sind wirkt sich das auf die AI aus wenn dies nicht berücksichtig wird
* **Verantwortlicher:** Wolkenflug oder EMSA (je nach Erhebungsart)
* **Risikoart:** Intern (bzw. Extern je nach Erhebungsart) - Operativ
* **Risikokategorie:** Methodisches Risiko
2. Name: Gesetzesänderung bezüglich sensitive Satelliten Daten
* **Kurzbeschreibung:** Würden sich die Gesetze ändern bezüglich sensitive Satelitenbilder könnte dies eine Auswirkung auf die Verarbeitungsmethode unserer Software haben.
* **Verantwortlicher:** EMSA und Wolkenflug
* **Risikoart:** Intern und Extern - Operativ
* **Risikokategorie:** Politisches undn Rechtlisches Risiko
3. Name: Kündigung einer Person im Projekt
* **Kurzbeschreibung:** Falls eine Person in diesem Projekt Kündigt kann das ausschlagebend sein für die Bearbeitungsdauer dieses Projekts. Vorallem falls dies eine Person von hoher Wichtigkeit ist.
* **Verantwortlicher:** Wolkenflug
* **Risikoart:** Intern - Strategisch
* **Risikokategorie:** Wirtschaftliches und Personelles Risiko
4. Name: Falsche Entscheidungen in der Archtitekturwahl
* **Kurzbeschreibung:** Wenn bei der Wahl der Architketuren und der Software-Struktur die falsche Wahl getroffen wird und sich dies erst später durch unnötig komplizierten Code herausstellt kann dies zu Refactoring arbeiten führen.
* **Verantwortlicher:** Wolkenflug
* **Risikoart:** Intern - Operativ
* **Risikokategorie:** Methodisches und Technologisches Risiko
5. Name: Over-/Underfitting der AI
* **Kurzbeschreibung:** Bei "polishing" Arbeiten bezüglich der AI kann es vorkommen das diese Overfitted wird und somit für die Testdaten gut funktioniert aber für die Realewelt nicht. Falls sie am Anfang underfitted wird kann es regelmäßig zu falschen Ergebnissen kommen
* **Verantwortlicher:** Wolkenflug
* **Risikoart:** Intern - Operativ
* **Risikokategorie:** Methodisches und Technologisches Risiko
6. Name: Unzufriedenheit mit der Qualität oder Geschwindigkeit
* **Kurzbeschreibung:** Falls EMSA unzufrieden ist mit der Qualität des Codes oder der Geschwindigkeit des Feature-Releases sind könnten sie überlegen zu einem Konkurrenten zu wechseln
* **Verantwortlicher:** Wolkenflug
* **Risikoart:** Intern - Strategisch
* **Risikokategorie:** Wettbewerbs Risiko
7. Name: Mangelhafte Kommunikation
* **Kurzbeschreibung:** Vorallem Anfangs wo sich EMSA und Wolkenflug noch öfters über die Anforderungen unterhalten muss können zu lange Antwortzeiten oder Ungenaue Angaben zu Probleme und Verzögerungen führen
* **Verantwortlicher:** EMSA und Wolkenflug
* **Risikoart:** Intern und Extern - Operativ
* **Risikokategorie:** Personelles Risiko
8. Name: Unrealistische Terminvorgaben
* **Kurzbeschreibung:** Falls die Abschätzung der Release Zeit die bereits Anfangs getroffen wurde unrealisitsch ist könnte dies EMSA unzufrieden Stellen und das Projekt und zukünftige Projekte unserem Konkurrenten geben.
* **Verantwortlicher:** Wolkenflug
* **Risikoart:** Intern - Operativ (und evtl strategisch)
* **Risikokategorie:** Methodisch und Wettwerbs Risiko
9. Name: Schnittstellenprobleme
* **Kurzbeschreibung:** Falls bei der Besprechung von den APIs etwas unklar ausgedrückt wird oder später man doch etwas ändern muss könnte dies zu Qualitätsproblemen oder Zeitverzögerungen führen
* **Verantwortlicher:** Wolkenflug
* **Risikoart:** Intern - Operativ
* **Risikokategorie:** Methodisch und Technologisches Risiko
10. Name: Unzureichende Tests
* **Kurzbeschreibung:** Falls der angegebene Testplan unvollständig ist und dies Wolkenflug nicht bemerkt könnten Bugs im Code auftreten. Falls diese erst spät auftretten kann dies zu riesigen Problemen führen.
* **Verantwortlicher:** EMSA und Wolkenflug
* **Risikoart:** Intern / Extern - Operativ
* **Risikokategorie:** Methodisches Risiko

### Risikoanalyse
*Analysieren und klassifizieren Sie die identifizierten Risiken, indem
Sie Ursachen, Auswirkungen, Eintrittswahrscheinlichkeit und
Schadensausmaß/Auswirkung überlegen und die Risiken quantifizieren
(Eintrittswahrscheinlichkeit * Schadensausmaß).*

| Name | Ursache | Auswirkungen | Wahrscheinlichkeit | Ausmaß | Risiko (Wahrscheinlichkeit * Ausmaß) |
| -------- | -------- | -------- | ------- | -------| -----|
| Falsche/Unvollständige Trainingsdaten | Viele potentielle Gründe, unter anderem Fehler in Messgeräten | Der AI werden falsche Dinge beigebracht | 4 | 4 | 16 |
| Gesetzesänderung | "Kollateralschaden" in neuem Datenschutzgesetz | Probleme mit Legalität der Verarbeitungsmethode | 1 | 3 | 3 |
| Kündigung | Unzufriedenes Personal | Personalmangel | 2 | 4 | 8 |
| Falsche Architektur | Mangelnde Voraussicht | Kompliziertes Refactoring | 3 | 4 | 12 |
| Over-/Underfitting | Nicht genung Trainingsdaten | AI lernt falsch | 2 | 4 | 8 |
| Unzufriedenheit | Feature-Release zu langsam oder nicht gut genug | Könnten Projekt an Konkurrenten verlieren | 2 | 5 | 10 |
| Mangelhafte Kommunikation | Zu lange Antwortzeiten, ungenaue Angaben | Verzögerungen und Missverständnisse, die zu falscher Funktionalität führen | 3 | 3 | 9|
| Unrealistische Terminvorgaben | Unterschätzung der Arbeitsmenge | Unzufriedenheit | 2 | 5 | 10 |
| Schnittstellenprobleme | Ungenaue Angaben | Qualitätsprobleme und Zeitverzögerungen | 2 | 3 | 6|
| Unzureichende Tests | Zum Beispiel Übersehen von wichtigen Sonderfällen | Bugs | 4 | 4 | 16 |


### Risikosteuerung

*Überlegen Sie, wie Sie mit den einzelnen Risiken umgehen
möchten (vermeiden, vermindern, ...) und welche Maßnahmen Sie dafür ergreifen.*

| Name | Umgang | Maßnahmen |
| ------- | -------| -----|
| Falsche/Unvollständige Trainingsdaten | Vermindern | Trainingsdaten überprüfen |
| Gesetzesänderung | Vermindern | Andere Datenquellen suchen |
| Kündigung | Vermindern | Personal motivieren und nicht überarbeiten |
| Falsche Architektur | Vermindern | Von Anfang an gut überlegen |
| Over-/Underfitting | Vermindern | Regelmäßige Backups und regelmäßiges Testen |
| Unzufriedenheit | Vermindern | Kommunikation mit Kunden |
| Mangelhafte Kommunikation | Vermindern | Bei Unklarheiten nachfragen |
| Unrealistische Terminvorgaben | Vermindern | Kommunikation mit Kunden |
| Schnittstellenprobleme | Vermindern | Kommunikation mit Kunden |
| Unzureichende Tests | Vermindern | Tests mehrmals überprüfen |

### Risikoüberwachung

*Überwachen Sie Ihre Risiken und Maßnahmen in Hinblick
auf Ihre Wirksamkeit bzw. Einfluss auf das quantifizierte Risiko.*

Um die Motivation der Mitarbeiter und die Zufriedenheit des Kunden zu überwachen werden wir aktiv Feedback ermutigen. Die anderen Risiken und Maßnahmen werden ausführliche Dokumentation erfordern, die dann überprüft werden kann. Jeden Monat wird ein Risiko-Statusbericht erstellt, in dem die Wirksamkeit unserer Maßnahmen bewertet wird.