mindflux/src/main/resources/static/finalflux/ap1/projektmanagement.html

<!DOCTYPE html>
<html lang="de" data-theme="dark">
<head>
  <meta charset="UTF-8">
  <title>Projektmanagement - FinalFlux AP1</title>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="/css/style.css">
  <link rel="stylesheet" href="/css/theme.css">
  <link rel="stylesheet" href="/css/finalflux.css">
  <script src="/js/theme.js"></script>
</head>
<body class="finalflux-page">
<div class="mf-theme-float"><button class="mf-theme"></button></div>
<main>
  <a href="/finalflux" class="back-link">Zurück zu FinalFlux</a>
  <h1>Projektmanagement in der AP1</h1>

  <section>
    <h2>Prüfungsmodus</h2>
    <p>
      Dieser FluxCheck führt dich durch prüfungsrelevante Projektmanagement-Themen:
      Auftrag, Ziele, Anforderungen, Planung, Risiken, Qualität, Kommunikation,
      Dokumentation und Abnahme. Jede Frage gehört zu einer Kategorie, die oben im
      Themenblock angezeigt wird.
    </p>
  </section>

  <section>
    <h2>Projektphasen im Überblick</h2>
    <p>
      Ein IT-Projekt durchläuft typische Phasen, die in der AP1 immer wieder
      auftauchen. Sie bauen aufeinander auf: Erst wenn eine Phase ein
      verwertbares Ergebnis liefert, beginnt sinnvoll die nächste. Wer Phasen
      überspringt, plant meist auf unsicherer Grundlage.
    </p>
    <ul class="key-list">
      <li><strong>Initiierung / Auftragsklärung:</strong> Ziel, Auftraggeber, Rahmenbedingungen und Erfolgskriterien klären.</li>
      <li><strong>Analyse:</strong> Ist-Zustand aufnehmen, Anforderungen sammeln, Soll-Konzept beschreiben.</li>
      <li><strong>Planung:</strong> Arbeitspakete, Termine, Ressourcen, Kosten und Risiken festlegen.</li>
      <li><strong>Realisierung:</strong> Umsetzung der geplanten Arbeitspakete.</li>
      <li><strong>Test &amp; Abnahme:</strong> Soll-Ist-Vergleich, Abnahmekriterien prüfen, Übergabe.</li>
      <li><strong>Abschluss:</strong> Dokumentation, Übergabe, Lessons Learned.</li>
    </ul>
    <p>
      <strong>Merksatz:</strong> Eine Phase ist ein Zeitabschnitt mit Dauer; ein
      Meilenstein ist nur ein Zeitpunkt (Kontrollpunkt) ohne eigene Dauer.
    </p>
  </section>

  <section>
    <h2>Projektziele und die SMART-Regel</h2>
    <p>
      Ein gutes Projektziel ist eindeutig und überprüfbar. Vage Wünsche wie
      "Das System soll besser werden" lassen sich weder planen noch abnehmen.
      Die SMART-Regel hilft, Ziele prüfbar zu formulieren.
    </p>
    <ul class="key-list">
      <li><strong>S – Spezifisch:</strong> eindeutig und konkret beschrieben.</li>
      <li><strong>M – Messbar:</strong> der Erfolg lässt sich an einer Größe prüfen.</li>
      <li><strong>A – Attraktiv / Akzeptiert:</strong> von den Beteiligten getragen.</li>
      <li><strong>R – Realistisch:</strong> mit Zeit, Budget und Ressourcen erreichbar.</li>
      <li><strong>T – Terminiert:</strong> mit klarem Zeitpunkt oder Zeitraum.</li>
    </ul>
    <p>
      Beispiel: "Bis Freitag, 16 Uhr sind 12 Arbeitsplätze eingerichtet und ihre
      Netzverbindung ist getestet" erfüllt alle fünf Kriterien.
    </p>
  </section>

  <section>
    <h2>Das magische Dreieck (Zeit, Kosten, Qualität)</h2>
    <p>
      Zeit, Kosten und Qualität stehen in Wechselwirkung. Ändert man eine der
      drei Größen, wirkt sich das fast immer auf mindestens eine andere aus.
      Wird zum Beispiel der Termin verkürzt, der Umfang bleibt aber gleich,
      steigen entweder die Kosten (mehr Personal) oder die Qualität sinkt.
    </p>
    <ul class="key-list">
      <li><strong>Zeit:</strong> verfügbare Dauer bis zum Termin.</li>
      <li><strong>Kosten:</strong> Budget, Personal, Material, Lizenzen.</li>
      <li><strong>Qualität:</strong> Erfüllungsgrad der Anforderungen.</li>
      <li><strong>Scope (Leistungsumfang):</strong> was im Projekt enthalten ist; <em>Scope Creep</em> ist sein schleichendes, unkontrolliertes Anwachsen.</li>
    </ul>
    <p>
      <strong>Merksatz:</strong> An einer Ecke des Dreiecks ziehen heißt immer,
      an einer anderen Ecke nachzugeben. Änderungswünsche deshalb bewerten und
      dokumentieren.
    </p>
  </section>

  <section>
    <h2>Lastenheft vs. Pflichtenheft</h2>
    <p>
      Diese beiden Dokumente werden in der Prüfung gern verwechselt. Die einfache
      Eselsbrücke: Das Lastenheft beschreibt das <em>Was</em> (vom Auftraggeber),
      das Pflichtenheft das <em>Wie</em> (vom Auftragnehmer).
    </p>
    <ul class="key-list">
      <li><strong>Lastenheft:</strong> erstellt vom <em>Auftraggeber</em>; beschreibt Anforderungen und Ziele aus Kundensicht.</li>
      <li><strong>Pflichtenheft:</strong> erstellt vom <em>Auftragnehmer</em>; beschreibt die konkrete technische Umsetzung der Anforderungen.</li>
      <li><strong>Funktionale Anforderung:</strong> was das System tun soll (z. B. Anmeldung mit Benutzername und Passwort).</li>
      <li><strong>Nicht-funktionale Anforderung:</strong> Qualitätsmerkmal wie Antwortzeit, Sicherheit oder Verfügbarkeit.</li>
      <li><strong>Priorisierung:</strong> Muss-, Soll- und Kann-Anforderungen ordnen die Wichtigkeit.</li>
    </ul>
  </section>

  <section>
    <h2>Planung: Arbeitspakete, Meilensteine, Gantt und Netzplan</h2>
    <p>
      Aus dem Projektziel entsteht ein Projektstrukturplan (PSP), der das Projekt
      in Teilaufgaben bzw. Arbeitspakete zerlegt. Für jedes Arbeitspaket werden
      Aufwand, Dauer und ein Verantwortlicher festgelegt.
    </p>
    <ul class="key-list">
      <li><strong>Aufwand vs. Dauer:</strong> Aufwand ist die geleistete Arbeit (z. B. 16 Personenstunden), Dauer die verstrichene Zeit (z. B. 2 Tage) – nicht dasselbe.</li>
      <li><strong>Projektstrukturplan:</strong> hierarchische Zerlegung in Arbeitspakete (das Was).</li>
      <li><strong>Gantt-Diagramm:</strong> Balkenplan, zeigt zeitliche Lage und Dauer von Aufgaben auf einer Zeitachse.</li>
      <li><strong>Netzplan:</strong> zeigt Abhängigkeiten und Reihenfolge der Vorgänge sowie den kritischen Pfad.</li>
      <li><strong>Kritischer Pfad:</strong> die längste Vorgangskette ohne Puffer; Verzögerungen darauf verschieben das Projektende.</li>
      <li><strong>Puffer:</strong> Reserve für Verzögerungen, Lieferverzug oder Probleme.</li>
    </ul>
  </section>

  <section>
    <h2>Stakeholder und Kommunikation</h2>
    <p>
      Stakeholder sind alle Personen oder Gruppen mit Interesse oder Einfluss auf
      das Projekt: Auftraggeber, Anwender, IT, Datenschutz, Management. Wer sie
      früh einbindet, vermeidet späte Überraschungen.
    </p>
    <ul class="key-list">
      <li><strong>Kick-off:</strong> gemeinsamer Projektstart zur Klärung von Ziel, Rollen und Vorgehen.</li>
      <li><strong>Kommunikationsplan:</strong> regelt, wer wann welche Information erhält.</li>
      <li><strong>Protokolle:</strong> halten Beschlüsse, Aufgaben, Verantwortliche und Termine fest.</li>
      <li><strong>Eskalation:</strong> Weitergabe eines Problems an eine höhere Entscheidungsebene.</li>
    </ul>
  </section>

  <section>
    <h2>Risikomanagement</h2>
    <p>
      Ein Risiko ist ein mögliches zukünftiges Ereignis mit negativer Auswirkung –
      keine sichere Tatsache. Risiken werden früh erkannt, bewertet und mit
      Maßnahmen versehen; im Projektverlauf werden sie regelmäßig überprüft.
    </p>
    <ul class="key-list">
      <li><strong>Bewertung:</strong> nach Eintrittswahrscheinlichkeit und Schadensauswirkung (Risikomatrix).</li>
      <li><strong>Vermeidung:</strong> Vorgehen wählen, bei dem das Risiko gar nicht entsteht.</li>
      <li><strong>Minderung:</strong> Wahrscheinlichkeit oder Auswirkung senken (z. B. getestetes Backup).</li>
      <li><strong>Übertragung:</strong> Risiko abgeben, etwa per Versicherung oder Vertrag.</li>
      <li><strong>Akzeptanz / Restrisiko:</strong> das, was nach allen Maßnahmen bewusst bleibt.</li>
    </ul>
  </section>

  <section>
    <h2>Qualität, Abnahme und Projektabschluss</h2>
    <p>
      Qualität wird im Projekt an den Anforderungen gemessen, nicht am
      Geschmack. Tests und ein Soll-Ist-Vergleich zeigen vor der Übergabe, ob
      die Lösung passt. Die Abnahme stützt sich auf vorher vereinbarte
      Abnahmekriterien und wird in einem Abnahmeprotokoll dokumentiert.
    </p>
    <ul class="key-list">
      <li><strong>Testfall:</strong> Eingabe, Ablauf und erwartetes Ergebnis – wiederholbar und nachvollziehbar.</li>
      <li><strong>Pilotbetrieb:</strong> begrenzter Test mit kleiner Nutzergruppe vor dem breiten Rollout.</li>
      <li><strong>Abnahmeprotokoll:</strong> Ergebnis, offene Punkte, Datum und Freigabe.</li>
      <li><strong>Dokumentation:</strong> technische Doku für Betrieb und Wartung, Anwenderdoku für Nutzer.</li>
      <li><strong>Lessons Learned:</strong> Erkenntnisse für künftige Projekte sichern.</li>
    </ul>
    <p>
      <strong>Merksatz:</strong> Ein Projekt ist erst sauber abgeschlossen, wenn
      Abnahme erfolgt, Dokumentation übergeben und offene Punkte geklärt sind.
    </p>
  </section>

  <section class="finalflux-test" data-finalflux-test aria-live="polite">
    <div class="test-meta">
      <span data-question-counter>Frage 1</span>
      <span data-score-counter>0 richtig</span>
    </div>

    <div class="category-block">
      <p class="eyebrow">Kategorie</p>
      <h2 data-category-title>Projektstart</h2>
      <p data-category-hint>Auftrag, Ausgangslage und Ziel verstehen.</p>
    </div>

    <div class="question-card">
      <h3 data-question-text></h3>
      <div data-answer-options class="answer-options"></div>
      <div data-answer-feedback class="fluxcheck-result"></div>
    </div>

    <div class="test-actions">
      <button type="button" data-check-answer>Antwort prüfen</button>
      <button type="button" data-skip-question class="secondary">Überspringen</button>
      <button type="button" data-next-question class="secondary" disabled>Weiter</button>
    </div>
  </section>

  <section data-test-result class="finalflux-panel" hidden>
    <h2>Auswertung</h2>
    <p data-result-summary></p>
    <ul data-category-summary class="key-list"></ul>
    <div class="finalflux-actions">
      <button type="button" data-restart-test>Test neu starten</button>
      <a href="/finalflux">Zurück zur Übersicht</a>
    </div>
  </section>
</main>

<script src="/js/finalflux-test.js" data-questions-src="/finalflux/questions/projektmanagement.json" defer></script>
</body>
</html>