Professur für Satellitennavigation (LRT 9.2) Institut für ... · • Einschalten des...

T. Pany

Professur für Satellitennavigation (LRT 9.2)

Institut für Raumfahrttechnik und Weltraumnutzung

Projektmanagement, 2. Teil

Projektbeispiele, typische ProblemeRichtlinien der AP-GestaltungGrenzen des Projektmanagements, SCRUM

23/19/2019 Conference/Workshop/Event 2Projektmanagement

Galileo TestbedProjektplan, Schwierigkeiten, Lösungen, Verlauf→ Die unbekannte Physik und der unbekannte MarktVon TRL2 → TRL9


Ausgangslage

•Europäische Entscheidung einen Beitrag der Satellitennavigation zu leisten

•Kaum Erfahrungswerte/Know-How insbesondere für den Aufbau eines GNSS in Europa vorhanden

•Machbarkeit und Nutzen von GNSS (heute Galileo) in mehreren Papierstudien bereits diskutiert

Ende 90er

Jahre:

•Suche nach Möglichkeiten um schnell Erfahrungswerte für den Aufbau eines GNSS zu sammeln•Galileo-Payload auf GLONASS Satelliten•YUMA-Testbed der 70er Jahre für GPS

Anfang 0er

Jahre:


GATE Phase A/B (Machbarkeitsstudie)

Emulation von GNSS Satelliten durch terrestrische Sender

Kontrollsegment zur Steuerung der Sender

•Virtual Satellite Mode (VSM): Sendesignale werden so geregelt, dass sie von echten Satellitensignalen nicht zu unterscheiden sind (Doppler, Laufzeitverzögerung, …)

Im Testgebiet sollen echte Navigationsanwendungen mit Galileo getestet werden

Phase A/B 2002 erfolgreich am Papier abgeschlossen!Leitung: UniBw M


GATE Phase C/D

• GATE wurde als Auftragsarbeit für das DLR-RFM• Deutsches Konsortium (who is who der

Navigation): • KMU• Großindustrie• Forschungsinstitute (DLR-IKN), • UniBw M

• Einhaltung von Raumfahrtstandards bei der Projektdurchführung

• Phasenmodell, ECSS• Anforderungsmanagement (DOORS 7.0)• Externe Reviewer

DLR-RFM … DLR Raumfahrtmanagement (Mittelvergabe)DLR-IKN … DLR Institut für Kommunikation und Navigation


GATE Architektur

GATE Architektur zum PDRGATE Architektur zum PDRGATE Architektur

or GSM network

Galileo SatellitesGSTB-V2 Satelite

. GPS Satellites

GATE-Segmente:Field-Segment:

GTS, GMS

Control-Segment:GTF, CC (GPF, GADS, GMCF)

Support-Segment:GMSF, GSL,GURx/GUT

User-Segment:Kunden-Empfänger


Beispiel: Sendestation

NavigationSignal

GenerationUnit

(NGSU)

NAV DATA

FrequencyGeneration &UpconversionUnit (FGUU)

E2L1E1

E2L1E1RF

E6 RF

E5a+E5bRF

OMUX

FilterNavigationSignal

GenerationUnit

(NGSU)

NAV DATA

FrequencyGeneration &UpconversionUnit (FGUU)

E6

OMUX

x12

Clock Monitoring andControl Unit (CMCU)Clock Monitoring andControl Unit (CMCU)

E5a+E5bQ

E5a+E5bI

BFNBFN

BFN

Nav

igat

ion

Ant

enna

BFNBFN

BFN

Ant

enna

PHM2

RAFS1

RAFS2

PHM1

SSPA &Switches

RAFS: Cooperation with Temex Neuchatel (ESA Contract)

NSGU: Cooperation with AAe and Saab Ericsson (ESA Contract)

CMCU: In-house Predevelopment (sponsored by DLR Contract)


WBS: Gate Phase C/D

Overall ProjectManagement, Cost,

Control & Administration

WP 11000 / IfEN

Project Mgmt. IfEN

WP 12000 / IfEN

Project Mgmt.EADS-Astrium

WP 13000 / EAST

Project Mgmt. DLR-IKN

WP 14000 / DLR-IKN

Project Mgmt. DLR-GSOC

WP 15000 / DLR-GSOC

User Contacts

WP 16000 / TLM

Dissemination

WP 17000 / UniBW

Product Assurance

WP 18000 / IfEN

Management

WP 10000 / IfEN

Segment RequirementsConsolidation

WP 21000 / IfEN

Operational ConceptConsolidation &

Preparation

WP 22000 / DLR-GSOC

GUT-GPF Datalink

WP 23100 / TLM

Functional Architecture

WP 23000 / IfEN

System PerformanceAllocation & Analysis

WP 24000 / IfEN

System Verification &Validation Planning

WP 25000 / VEGA

Permissions & RegulatoryAffairs

WP 26000 / K-T

Scientific Consultancy

WP 27000 / UniBW

System Engineering

WP 20000 / IfEN

GTS TechnicalSpecification

WP 31000 / EAST

GTS Engineering

WP 32000 / EAST

SG Core

WP 33100 / EAST

SG Controller Unit

WP 33200 / EAST

Tx Antenna

WP 33300 / K-T

GTS Stations HousingPreparation & Connectivity

WP 33400 / K-T

Design, Development &Procurement

WP 33000 / EAST

GTS AIV

WP 34000 / EAST

Transmit Stations (GTS)

WP 30000 / EAST

GMS TechnicalSpecification

WP 41000 / IfEN

GMS Engineering

WP 42000 / IfEN

MRx RF-Front-End

WP 43100 / FHG

Signal Conditioning

WP 43210 /FHG

MRx Baseband

WP 43200 / IfEN

MRx Controller Unit

WP 43300 / IfEN

Rx Antenna

WP 43400 / FHG

GMS Station HousingPreparation & Connectivity

WP 43500 / K-T


WP 43000 / IfEN

GMS AIV

WP 44000 / IfEN

Monitoring Stations (GMS)

WP 40000 / IfEN

GCS TechnicalSpecification

WP 51000 / DLR-IKN

GCS Engineering

WP 52000 / DLR-IKN

GTS/GMS Freq. Std. Ver.

WP 53110 / DLR-IKN

System Time Facility(GTF)

WP 53100 / DLR-IKN

Processing Facility (GPF)

WP 53200 / IfEN

Monitoring & ControlFacility (GMCF)

WP 53300 / VCS

Archiving & Data Server

WP 53400 / VCS

Control Center &Operations Support

WP 53500 / DLR-GSOC


WP 53000 / DLR-IKN

GCS AIV

WP 54000 / DLR-IKN

Control Segment (GCS)

WP 50000 / DLR-IKN

OPS Concept Support

WP 61100 /DLR-GSOC

GSS TechnicalSpecification

WP 61000 / IfEN

Mission Support Facility(GMSF)

WP 62000 / IfEN

Backend SW Development

WP 63100 / UniBW

Antenna & RF-Front-End

WP 63200 / FHG

GATE User Terminal(GUT)

WP 63000 / IfEN

GSS AIV

WP 64000 / IfEN

Support Segment (GSS)

WP 60000 / IfEN

Field Segment Deployment

WP 71000 / K-T

Initial GPS Survey

WP 72000 / IfEN

Signal Laboratory Testing

WP 73000 / IfEN

System Testing

WP 74000 / IfEN

Field Testing / User

WP 75000 / KT

System AIV

WP 70000 / IfEN

Experimental Operations

WP 81000 / DLR-GSOC

System Transfer

WP 82000 / IfEN

System Operations

WP 80000 / DLR-GSOC

GATE Phase C/DWBS V.10


Gantt-Chart: Wasserfall

Aber: Fertigstellung und Eröffnung erst im Sommer 2008!Was war passiert und welche Auswirkungen hatte das?


Projektverlauf

• Koordinierte und planmäßiger Verlauf bis zu SAR (System Acceptance Review)

• Erstellung der Architektur- und Schnittstellenpläne• Verfassen von Interface Control Dokumenten (ICDs)• Aufbau der Komponenten der Projektpartner• Tests auf Komponentenebene

• Nicht-technische Arbeiten• Organisation des Vor-Betriebs

• GATE-Office, Infrastruktur, …• Hohe politische Sichtbarkeit

• Wir sind schneller als Galileo …

• Erste Inbetriebnahme (AIV … assembly integrationvalidatation)

• Sendesystem (Space-Segment)• Einschalten des Test-Navigationsempfängers

Empfänger funktional aber Navigationsperformance extrem schlecht:Signalabbrüche, Genauigkeit im 100 m Bereich


„Übersehene“ technische /physikalische Randbedingungen• Bodenreflexionen/Bodenwelle:

• Auswirkungen: Genauigkeitsverlust, Auslöschung des Signals durch destruktive Interferenz

• Effekt tritt bei echten Satellitensignalen nicht auf

• weder Erfahrungswerte noch „Awareness“ vorhanden

• → Kommentare/Anmerkungen von Technikern wurden von Entscheidungsträgern in der Anfangsphase ignoriert, da die notwendigen Tests das Projekt um Monate verzögert hätte

• Schlussendliche Lösung:• Verbesserte Sendeantennen mit

stärkerer Richtwirkung• Robustere und stabilerer

Empfänger• Anpassung der Erwartungshaltung


„Übersehene“ technische /physikalische Randbedingungen• Radar-Interferenz

• Radar-Anlage des österreichischen Bundesheeres sendet legal auf der Frequenz E6

• Signalempfang auf E6 war nicht möglich

• E6-Band bei GPS nicht benutzt• Standard GPS L1 (und L2) sind geschützte Bänder

• weder Erfahrungswerte noch „Awareness“ vorhanden

• Es gab auch keine Kommentare aus dem Projektteam

• Identifikation und Lösung• Einbau von Debug-Möglichkeiten in den

Navigationsempfänger, um die Ursache des schlechten Signalempfangs auf E6 zu verstehen.

• Lokalisierung des Senders

• Einbau von Gegenmaßnahmen in den Empfänger (auch für andere schwächere Störquellen)

• De-facto sehr einfache Mittel (Anschneiden der Pulsspitzen in Software)

• Vereinbarung mit der Radaranlage bei Testbetrieb nicht zu senden oder eine andere Frequenz zu nutzen


Auswirkungen

• GATE wurde schlussendlich fertiggestellt und hat eine im Rahmen der physikalischen Randbedingungen sehr gute Performance erzielt

• Erweiterung von 6 auch 8 Sendestationen• Stützung des Referenzempfängers durch Inertialnavigation

• Um ein System dieser Komplexität überhaupt fertigstellen und betreiben zu können, war sehr gutes und solides Projektmanagement erforderlich

• Operationeller Betrieb, Dokumentation, etc… war exzellent organisiert

• Dennoch wurde das eigentliche Ziel „Testen von echten Navigationsanwendungen“ faktisch verfehlt

• Kaum Nachfrage durch Kunden• Galileo-Testsignale aufgrund der Verzögerung in GATE bereits über GIOVE-Satelliten verfügbar• Die zu diesem Zeitpunkt bereits am Markt erhältlichen HF-Signalsimulatoren stellten einen

wesentlich einfacheren Weg dar, um Galileoempfänger zu testen.• Navigationsperformance in GATE wie oben besprochen nicht besonders gut.• Nutzung von GATE aufwändig (pro Tests min. 3 Tage, besser 1 Woche)• Aufbau von weiteren Testgebieten in Deutschland (SEAGATE, …) und in Europa• Der Begriff „Testbed“ ist heute beim DLR-RFM negativ besetzt

Top: Technologiedemonstrator Flop: „Markterfolg“


Take-Away

• Sehr gutes und solides Projektmanagement war unabdingbar, um dieses große technische Projekt überhaupt umsetzten zu können.

• Herausragendes Projektmanagement geht darüber hinaus.

• Was hätte man besser machen können:• Frühzeitiges Erkennen der technologischer Risiken und ihrer

Auswirkungen: • Projektmanager hat entweder selbst das technologische

Gespür oder kann durch sorgsame Kommunikation mit dem Team die Probleme heraushören (das Gras wachsen hören).

• Anerkennen äußerer Randbedingungen und proaktive Reaktion• Zum Beispiel hätte der Fokus des Projektes auf die Technologiedemonstration

anstatt auf das Testen von Anwendungen gelegt werden können. • Einsparung von Entwicklungskosten

• Auch andere Nutzungsszenarien wären denkbar gewesen, hätten aber alle ein Abweichen von der ursprünglichen Projektidee bedeutet.

• Projektmanager braucht für proaktives Reagieren• Überzeugende (wenn nicht geniale) Lösungsidee • Gute Kommunikation gegenüber dem Auftraggeber, Management

und dem Team• Führungsqualitäten, um eine Planänderung durchsetzen zu können


Robuste GNSS-AntenneESA-EntwicklungsprojektProjektplan, Schwierigkeiten, Lösungen, Verlauf TRL4 → TRL6


HintergrundGNSS-Antennen des Galileo-Kontrollsegmentes sind potentiell anfällig für Spoofing-Angriffe


• ESA-EGEP-Projekt• Entwicklung einer

rotierenden Antenne• Nutzung des Prinzip der

synthetischen Apertur zur Detektion der Signalrichtung

• Direkte und einfache Unterscheidung zwischen Satellitensignalen und Spoofingsignalen.

• Entwicklung von Mechanik, Steuerungselektronik, HF-Elektronik, Signalverarbeitung, GNSS-Empfänger

Rotierende Antenne zur Detektion von Spoofing


Gantt-Chart: ProjektantragID Task Name Start Finish

1 Project SETI Mon 02.06.14 Mon 30.11.15

2 Milestones Mon 02.06.14 Mon 30.11.15

3 KO Mon 02.06.14 Mon 02.06.14

4 PM1 Mon 01.09.14 Mon 01.09.14

5 MTR Mon 01.12.14 Mon 01.12.14

6 PM2 Mon 02.03.15 Mon 02.03.15

7 PM3 Mon 01.06.15 Mon 01.06.15

8 ERR Tue 01.09.15 Tue 01.09.15

9 FR Mon 30.11.15 Mon 30.11.15

10 WP 1000: Project Management Mon 02.06.14 Fri 27.11.15

11 WP 1100: Project Management IFEN Mon 02.06.14 Fri 27.11.15

12 WP 1200: Project Management CTU Mon 02.06.14 Fri 27.11.15

13 WP 2000: Requirements & System Analysis Mon 02.06.14 Fri 28.11.14

14 WP 2100: Performance Requirements Analysis Mon 02.06.14 Fri 29.08.14

15 WP 2200: Vulnerability Analysis & Spoofing Scen. Def. Mon 02.06.14 Fri 29.08.14

16 WP 2300: Impact of Synthetic Aperture on Error Budget Mon 01.09.14 Fri 28.11.14

17 WP 3000: Development and Test Environment Mon 01.12.14 Mon 31.08.15

18 WP 3100: Test Environment Setup Mon 01.12.14 Mon 31.08.15

19 WP 3200: Performance Analysis Tool Development Mon 01.12.14 Fri 29.05.15

20 WP 3300: Consolidation of Mechanical Design Mon 01.12.14 Fri 27.02.15

21 WP 3400: Spoofing Signal Detection Algo Development Mon 01.12.14 Fri 29.05.15

22 WP 4000: Experimental Demonstration for Validation Tue 01.09.15 Fri 27.11.15

23 WP 4100: Spoofing Test Campaing using GATE Tue 01.09.15 Wed 30.09.15

24 WP 4200: Analysis of Results & Recommendation Thu 01.10.15 Fri 27.11.15

02.0601.09

01.1202.03

01.0601.09

30.11

May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec2015

• Wasserfall-Plan um von TRL4 auf TRL6 zu gelangen• Anforderungsanalyse, Aufbau der Testumgebung, Testkampagne• Fokus:

• Welche für das Galileo-Kontrollsegment relevanten Parameter werden verbessert?• Welche ist die optimale Algorithmik?• Wie kann ein Langzeitbetrieb gewährleistet werden? Erste Erfahrungswerte für

Langzeitbetrieb (Prototyp)!


Gantt Chart bei PM1, 15.12.2015

• Verzögerung des Projektbeginns (ESA-seitig)

• „Weiche“-Arbeitspakete zu Beginn• Erstellen von technischen Noten• Einhalten des Zeitplans leicht möglich


Gantt Chart bei PM3, 18.4.2016

• Verzögerung beim Aufbau des Systems aufgrund von Ressourcenmangel• Weiteres und größeres ESA-Projekt höherer Dringlichkeit beim Hauptauftragnehmer

• Absprache mit der ESA und Genehmigung des Verschiebung

• Kommunikation der Verschiebung an die Unterauftragnehmer• Auftragnehmer A (Mechanik): Verschiebung hatte positive Auswirkungen, da mehr Zeit für Beschaffung von

Komponenten, Integration, Dokumentation. Diese Tätigkeiten sind voneinander unabhängig auch mit größeren Unterbrechungen gut durchführbar

• Auftragnehmer B (Performance-Evaluierung): Verschiebung grundsätzlich positiv, da Zeiträume für die Softwareentwicklung besser mit anderen Aufträgen abgestimmt werden können. Negative Auswirkungen, da der Zeitraum der Softwareentwicklung bis zur Softwarenutzung sehr groß war (weitere Einarbeitungszeit)


Weiterer Projektverlauf

• Aufbau der Mechanik und Elektrik laut Projektplan erfolgreich durchgeführt.

• In der Signalverarbeitung (Software) Beschränkung auf wesentliche Punkte, die für den Testbetrieb notwendig sind.

• Beispiel: Nutzung von einer Frequenz (L1) anstelle von zwei (L1+L5)

• Fokus auf Testbetrieb und Angriff Szenarien, um den Prototype möglichst aussagekräftig charakterisieren zu können.

• Beendigung des Projektes nach Verbrauch der Ressourcen


Take-Away

• Entwicklungsprojekte niederer TRL-Stufen haben eine höhere Flexibilität in der Aufgabenstellung, aber müssen sich anderen Aktivitäten unterordnen.

• Der Fokus des Erkenntnisgewinns bedarf besonderer Abstimmung mit dem Auftragnehmer.

• Welche Nutzungsszenarien dieser Technologie sind möglich?• Welche Parameter werden dadurch verbessert?• Welche Alternativen stehen zur Verfügung?• Welche Nachteile bringt diese Technologie?

• Die Entwickler bei den Auftragnehmern tendieren dazu, sich auf die eigenen Lösungen und Fähigkeiten zu fokussieren und diese möglichst breit in das Projekt einzubringen.

• Der Projektmanager muss aber das gesamte Projekt und den Nutzen für den Kunden im Fokus behalten!

• Kommunikation zwischen Auftragnehmer und Geber ist essentiell, um auf organisatorische Schwierigkeiten reagieren zu können.

• Der „ESA technical officer“ sollte mit dem Entwicklungsprozess beim Auftragnehmer vertraut sein und die Herausforderungen auf technischer, finanzieller oder personeller Sicht zumindest im Ansatz verstehen!


Test- und Analysesystem für neue GNSS-SignaleESA-Projekt im Galileo-ProgrammProjektplan, Schwierigkeiten, Lösungen, Verlauf Teile der Funktionalitäten: TRL2 → TRL9Beispiel für eine Negativspirale


Kontext

• HF-Signalgenerator und GNSS-Empfänger für Signaloptionen der nächsten Generation von Galileo (G2G)

• Testbed-Ansatz:• Simulation des Signals der Empfangsantenne• Vielzahl von Optionen für die Gestaltung von G2G

• Neue GNSS-Signale, neue Satellitenhardware (Spotbeam), neues Kontrollsegment, …

• Verifikation der Navigationsperformance über einen „test-user-receiver“, der sämtliche Galileo-Optionen unterstützen muss.

• Nutzung existierender Simulator-Technologie und Software-Radio Technologie

• Vorteile:• End-to-end Nachweis der Navigationsperformance, über Nutzung

eines echten Empfängers• Keine Papierstudie

• System sehr flexibel, da ~80% der Funktionalität über Software realisiert

• Spätere Nutzung der Technologie in kommerziellen Produkten:• Simulatoren für die Produktqualifizierung

• Empfängertechnologie


Projektstart

• Hohe Motivation beim Auftraggeber das Projekt zu bekommen

• Technologievorsprung • Prestige• Folgeaufträge

• Hoher Zeitdruck beim Auftraggeber, um die Ausschreibungsunterlagen fertigzustellen

• Breites Spektrum an Möglichkeiten (G2G noch in Phase A bei der Ausschreibung)

• Schwerpunktslegung unklar

• Beidseitiges Ignorieren von technischen Schwierigkeiten und unklaren Anforderungen


Projektanforderungen in der Ausschreibung

• Beispiel für eine klare Anforderungen:



• Beispiel für eine unklare Anforderungen:



• Beispiel für eine unmöglich zu erfüllende Anforderung:



• Eine weitere unmöglich zu erfüllende Anforderung


Projektplan


Start in die falsche Richtung

• Eine GNSS-Signaloption (CPM aus Req. 3) waren in der Ausschreibung nur lose definiert

• Nur Erwähnung des Akronyms

• Zwei unterschiedliche Definitionen:• GMSK wird als CPM-Signal im Mobilfunkstandard GSM genutzt (viel Literatur

verfügbar)• Zum Teil eingestufte CPM-Entwicklung für GNSS

• Wenig Kommunikation zwischen Auftragnehmer und Auftraggeber in der Definitionsphase

• Auftraggeber wählt falsche CPM-Variante• Fehler bleibt unbemerkt• Streitigkeiten, wer am Fehler schuld ist und wie es weitergehen soll• Am Ende entscheidet der Auftraggeber die andere CPM-Variante zu wählen• Verlust von Zeit und Budget

• Ausschreibungstext (und damit Projektgrundlage) bleiben weiter allgemein formuliert

• Auftraggeber ist nicht bereit Anforderungen zu streichen


Die unmögliche Flexibilität

• Projektkonzept sah eine generische Beschreibung aller möglicher Formate von Navigationsnachrichten vor

• Satellitenephemeridenformate, Fehlerkorrektur, …

• Ziel war es, damit Tests durchzuführen und somit die optimale Nachricht herauszufinden

• Es gab aber keinerlei Ansätze, wie so eine Beschreibung aussehen könnte

• Generalisierung existierender GNSS-Nachrichten über eine Baumstruktur• Mühsame Entwicklung über einige Jahre• XML-Templates, C++ Parsing-Routinen, Datenbanken• Implementierung für Satellit und Empfänger

• Resultierende XML-Dateien grundsätzlich funktional aber dermaßen komplex, das sie praktisch nicht konfigurierbar waren.

• Nur Beispieldateien der existierenden GNSS verfügbar

• Projektverlauf:• Offensichtliche Überforderung des Auftragnehmers bei der Umsetzung der Idee• Kein Eingeständnis des Auftragnehmers der Überforderung• Kein Eingeständnis des Auftraggebers der schlechten Aufgabenstellung


Negativspirale I

Substantielle technische

Schwierigkeiten

Verzögerungen

Finanzierungs-schwierigkeiten

Frustration der Mitarbeiter,

Kündigungen


Negativspirale II

Substantielle technische

Schwierigkeiten

Verzögerungen

Finanzierungs-schwierigkeiten

Aufstockung mit weiteren

Arbeits-paketen zur kurzfristigen Lösung der

Finanzierung


Lösungsvorschläge für das Projektmanagement

• Erfassen der Situation• Bestehen auf klaren Randbedingungen

• Exakte Anforderungen einfordern• Arbeitsaufwand an das Budget koppeln

• Anbieten eines Stundenkontigents• Bei ESA-Projekten allerdings nicht vorgesehen

• Kommunikation der Schwierigkeiten und Erzeugen eines Verständnisses der Situation

• Handlungsfreiheit bewahren• Ausstieg aus dem Projekt als Möglichkeit in Betracht

ziehen

• Ausarbeiten eines (genialen) Alternativvorschlages


Take-Away

• Auftraggeber formuliert nicht immer klare und erfüllbare Aufgaben

• Betreuende Personen beim Auftraggeber können sich ändern; neu hinzukommende Personen haben andere Vorstellungen „müssen“ sich an schriftliche Unterlagen halten.

• Das attraktive Schlagwort „Flexibilität“ überdeckt oft unausgereifte Anforderungen

• Substantielle Probleme in der Projektdurchführung müssen erkannt werden.

• Je früher man sie erkennt, anspricht und Lösungen vorschlägt, desto einfacher bekommt man sie gelöst.


Zwei Wege um erfolgreiche Projekte durchzuführenGuter Projektstrukturplan (falls möglich)Agiles Projektmanagement (SCRUM)


Projektstrukturplan

• Das Erfassen der für ein Projekt notwendigen Arbeiten ist ein wesentlicher Teil des klassischen Projektmanagements.

• Abweichung von +/- 10 % können als normal angesehen werden

• Sollte dieses Erfassen gelingen und die äußeren Umstände wie erwartet eintreten, wird das Projekt erfolgreich abgewickelt werden.

• Ein wesentlicher Beitrag dazu kann die richtige Granularität des Projektstrukturplans sein:

• Zu grob: Tätigkeiten, Risiken und Abhängigkeiten werden übersehen

• Zu fein: Überforderung des Projektmanagers und Übertragung der Projektarbeit auf den Manager


Ist der Projektstrukturplan (WBS) ausreichend detailliert definiert?• Is there a need to improve the assessment of the cost estimates or progress measuring of the WBS

element?

• Is there more than one individual responsible for the WBS element? Often a variety of resources are assigned to a WBS element, a unique individual is assigned the overall responsibility for the deliverable created during the completion of the WBS element.

• Does the WBS element content include more than one type of work process or produces more than one deliverable at completion?

• Is there a need to assess the timing of work processes that are internal to the WBS element?

• Is there a need to assess the cost of work processes or deliverables that are internal to the WBS element?

• Are there interactions between deliverables within a WBS element to another WBS element?

• Are there significant time gaps in the execution of the work processes that are internal to the WBS element?

• Do resource requirements change over time within a WBS element?

• Are there acceptance criteria, leading to intermediate deliverable(s), applicable before the completion of the entire WBS element?

• Are there identified risks that require specific attention to a subset of the WBS element?

• Can a subset of the work to be performed within the WBS element be organized as a separate unit?

Aus den ECSS-Projektmanagement Richtlinien.Sind mehr als 50 % der Fragen mit „Ja“ zu beantworten, muss das Arbeitspaket (WBS element) unterteilt werden.


SCRUM

Ab einer gewissen Komplexität ist es unmöglich Projekte so zu planen, dass

• eine definierte Funktionalität• mit definierten Ressourcen

erreicht wird.

Warum also nicht gleich einen iterativen Zugang zum Projekt wählen?


SCRUM

Projektanforderungen und Lösungsschritte,zeitlich unsortiert

Auswahl für die nächste Arbeitsperiode

Umsetzung mit iterativer Kontrolle

Verbesserte Lösung


SCRUM

• Erfassen aller Anforderungen und Arbeitsschritte zu Beginn der Projektes

• Feststellen welche Schritte einen messbaren Fortschritt bringen und innerhalb kurzer Zeit (7-30 Tage) umgesetzt werden können.

• Aufwands- und Arbeitsgeschwindigkeitsschätzung

• Umsetzung der Schritte• Evaluierung der Ergebnisse• Adaptierung der Anforderungen und Lösungsansätze• Verbesserte Schätzung der Arbeitsgeschwindigkeit


SCRUM

• Messung der Arbeitsgeschwindigkeit während des Sprints (=Umsetzungsperiode)

• Burndownchart: geplante und verbrauchte Arbeitsstunden/Tickets/Punkte, … als Funktion der Zeit

• Nach 2-3 Sprints stimmen Plan und Realität miteinander überein• Bessere Planung in nachfolgenden Sprints• Optimierung der Prozesse und Messung der Geschwindigkeitssteigerung


SCRUM

• SCRUM - oder allgemein agiles Projektmanagement - wird nur selten in der Luft- und Raumfahrt eingesetzt.

• Neue Methodik welche etablierte Methoden erst verdrängen müsste• Kernbereiche der Luft- und Raumfahrt (Flugzeugbau, Raumfahrtmission, … )

vermutlich nicht für agiles Projektmanagement geeignet• Aber: Nebenentwicklungen wie Testsysteme, Analysesoftware, Studien,

Prototypen, Anwendungsentwicklung, … wären sehr wohl für agile Methoden geeignet.

• Umdenken und Änderung der formalen Vorgaben erforderlich

• Weiterführende Literatur: • Jeff Sutherland: Die Scrum-Revolution: Management

mit der bahnbrechenden Methode der erfolgreichsten Unternehmen, Campus Verlag, 2015


Prüfungsrelevante Gebiete

• Was kann ein Projektmanager beim Auftragnehmer dafür tun, dass ein Projekt für eine technologische Neuentwicklung erfolgreich durchgeführt wird?

• Was kann bei der Projektvergabe beim Auftraggeber dafür getan werden, dass ein Projekt für eine technologische Neuentwicklung erfolgreich durchgeführt wird?

• Gehen Sie gedanklich eines der folgende Projekte durch und überlegen Sie sich auftretende Schwierigkeiten und mögliche Projektverläufe. Versetzen Sie sich sowohl in die Rolle des Auftraggebers und in die Rolle eines Auftragnehmers.

• Prototypentwicklung zur Steuerung von Fliegerbomben über das europäische Navigationssignal Galileo-PRS.

• Hintergrund: Über die Studie soll ein politisches Commitment der Bundeswehr zu Galileo gezeigt werden. Die Galileo-PRS Technologie selbst ist derzeit aber noch in einem Anfangsstadium. Im Gegensatz dazu sind GPS-geführte Fliegerbomben Stand der Technik.

• Studie über den Nutzen der satellitengestützten Quantenkommunikation zur abhörsicheren weltweiten Kommunikation innerhalb der Bundeswehr.

• Hintergrund: Die Möglichkeit der Quantenkommunikation wurde wissenschaftlich nachgewiesen, aber konkrete Nutzungsszenarien sind nicht bekannt. Weltweit sind nur wenige Forschungsgruppen in der Lage Quantenkommunikation durchzuführen.

• Entwicklung und Einführung eines „Device-Trackers (=GNSS+Mobilfunk)“, um bestimmte Gerätgruppen des Bundeswehrbestandes jederzeit lokalisieren zu können.

• Hintergrund: Device-Tracker sind eine Internet-of-Things (IoT) Anwendung, der ein hohes Wachstumspotential zugeschrieben wird. Sie können sehr klein ausgeführt werden und über eine einfache Batterie bis zu 10 Jahren im Betrieb bleiben. Device-Tracker sind bereits heutzutage als kommerzielle Produkte erhältlich.

Professur für Satellitennavigation (LRT 9.2) Institut für ... · • Einschalten des...

Documents

Transcript of Professur für Satellitennavigation (LRT 9.2) Institut für ... · • Einschalten des...