9. VL Juristisches IT-Projektmanagement 10.12.2022

Podcast über die Vorlesung

Neu auf MyUniNotes – Podcasts

Diese Podcasts sind neu verfügbar und bieten eine großartige Zusammenfassung der Vorlesung. Nach Anwesenheit in der Vorlesung und dem anhören der Audios, kann ich mit gutem Gewissen sagen, dass diese die Vorlesung sehr gut zusammenfassen.

• Kurzversion: Eine kompakte Zusammenfassung der wichtigsten Inhalte.
  
• Langversion: Detailliertere Inhalte inklusive abschließendem FAQ-Bereich.
  

Ich freue mich über euer Feedback! Schreibt mir gerne eure Meinungen, Verbesserungsvorschläge oder Anmerkungen unten in die Kommentare.

Projektmanagement in der IT: Ausführliche Grundlagen und Praxis

Einleitung

In der heutigen Vorlesung beschäftigen wir uns intensiv mit den zentralen Aspekten des Projektmanagements in der IT-Branche. Wir analysieren die Dynamik innerhalb von Projektteams, die essenzielle Bedeutung der Qualitätssicherung, die detaillierte Strukturierung von Projektplänen sowie weitere grundlegende Komponenten, die den Erfolg von IT-Projekten maßgeblich beeinflussen. Diese Zusammenfassung soll Studierenden als umfassendes Lernmaterial dienen und die wichtigsten Konzepte verständlich und praxisnah darstellen.

Teamdynamik im Projekt

Fluktuation im Projektteam

In langfristigen Projekten, die sich über Jahrzehnte erstrecken, ist es unrealistisch zu erwarten, dass alle Teammitglieder von Anfang bis Ende im Projekt verbleiben. Stattdessen ist ein kontinuierlicher Wechsel von Mitarbeitern üblich:

• Komm und Gehen: Mitarbeiter treten dem Projektteam bei und verlassen es wieder, sei es durch Tätigkeitswechsel, Firmenwechsel oder andere Gründe.
• Rollenwechsel: Teammitglieder können ihre Rollen innerhalb des Projekts ändern, um unterschiedlichen Anforderungen gerecht zu werden.
• Fachspezifische Anforderungen: Spezifische Expertise wird je nach Projektphase benötigt. Beispielsweise werden Experten für Lasttests erst zu einem späteren Zeitpunkt benötigt, während Spezifikationsspezialisten eher am Ende des Projekts gebraucht werden.

Aufbau- und Abbauplan

Ein effektiver Projektaufbauplan berücksichtigt nicht nur die initiale Struktur des Teams, sondern auch den schrittweisen Abbau der Ressourcen:

• Aufbauplan: Dokumentiert die initiale Teamstruktur und die Zuordnung der Rollen zu Beginn des Projekts.
• Abbauplan: Beschreibt den schrittweisen Rückzug von Teammitgliedern, wenn das Projekt dem Abschluss näher rückt. Dies beinhaltet die Reduktion der Teamgröße und die Anpassung der Ressourcen entsprechend den Projektanforderungen.

Beispiele aus der Praxis

Ein praktisches Beispiel verdeutlicht die Dynamik im Projektteam:

• Lasttests: Experten für Lasttests werden erst in späteren Projektphasen hinzugezogen, um die Stabilität der Software unter hoher Belastung zu prüfen.
• Qualifikationsspezialisten: Fachkräfte, die sich auf die Spezifikation spezialisiert haben, werden erst am Ende des Projekts benötigt, um die finalen Anforderungen zu dokumentieren und umzusetzen.

Qualitätssicherung im Projekt

Bedeutung der Qualitätssicherung

Qualitätssicherung (QS) spielt eine zentrale Rolle in der Softwareentwicklung. Sie stellt sicher, dass die entwickelte Software den festgelegten Anforderungen entspricht und fehlerfrei funktioniert.

• Fehlererkennung: Selbst erfahrene Entwickler übersehen oft logische Fehler, die erst durch systematische Tests entdeckt werden.
• Qualitätssicherungsplan: Ein detaillierter Plan, der die QS-Maßnahmen, Termine und Fristen definiert und eng mit dem Projektplan abgestimmt ist.

Qualitätssicherungsmaßnahmen

QS-Maßnahmen laufen parallel zu den Entwicklungsaktivitäten und umfassen verschiedene Aspekte:

• Lasttests: Definition von Grenzbereichen, um die Stabilität der Software unter hoher Belastung zu prüfen.
• Review-Prozess: Umfasst die Überprüfung der gelieferten Ergebnisse durch spezialisierte Reviewer, um die Einhaltung der Qualitätsstandards sicherzustellen.
• Automatisierte Tests: Einsatz von Tools zur Automatisierung von Testprozessen, um die Effizienz und Genauigkeit der Tests zu erhöhen.

Beispiele aus der Praxis

Praktische Beispiele verdeutlichen die Bedeutung der QS:

• Entwicklerfehler: Ein Entwickler übersieht bei der ersten Programmversion einen logischen Fehler in einer Schleifenbedingung. Durch systematische Tests wird dieser Fehler erst in späteren Phasen entdeckt.
• Review-Prozess: In einem großen Projekt müssen mehrere Reviewer die Qualität der gelieferten Softwarekomponenten überprüfen, was mehrere Wochen in Anspruch nehmen kann.

Auslieferungsplanung

Auslieferungspläne bei großen Projekten

Bei umfangreichen Projekten ist eine detaillierte Auslieferungsplanung unerlässlich:

• Release-Management: Planung der Software-Releases mit spezifischen Funktionalitäten zu definierten Zeitpunkten.
• Beispiel: Einführung der Twin-SIM-Karte im Telekom-Netz, inklusive technischer und logistischer Planung. Dies umfasst die Entwicklung neuer Preismodelle und die Implementierung technischer Anpassungen.

Unterschiede bei kleineren Projekten

Kleinere Projekte erfordern eine einfachere Auslieferungsplanung:

• Einfachere Planung: Definieren eines festen Termins und Durchführung des Uploads auf entsprechende Plattformen (z.B. App-Store).
• Beispiel: Entwicklung einer kleinen App mit klar definierten Funktionen und einem festen Veröffentlichungstermin.

Praktische Beispiele

Ein praktisches Beispiel verdeutlicht die Unterschiede:

• Großes Projekt: Die Einführung einer neuen Funktionalität im Telekom-Netz erfordert eine umfassende Planung, einschließlich technischer Anpassungen und logistischer Koordination.
• Kleines Projekt: Eine einfache App-Entwicklung erfordert lediglich die Festlegung eines Veröffentlichungstermins und das Hochladen in den App-Store.

Wartungsmaßnahmen

Wartungsmaßnahmen sind essenziell, um die langfristige Funktionalität und Sicherheit von IT-Systemen zu gewährleisten.

Software-Wartung

• Regelmäßige Updates: Implementierung von Sicherheitsupdates und neuen Funktionalitäten.
• Datenreorganisation: Anpassung und Optimierung von Datenbanken, um die Effizienz der Software zu gewährleisten.
• Fehlerbehebungen: Behebung von Fehlern, die nach der ursprünglichen Implementierung auftreten.

Hardware-Wartung

• Firmware-Updates: Aktualisierung der Firmware auf Geräten, um deren Funktionalität und Sicherheit zu gewährleisten.
• Betriebssystemwechsel: Aktualisierung des Betriebssystems, um Kompatibilität mit neuer Software sicherzustellen.
• Installation neuer Wartungssoftware: Implementierung von Software zur Überwachung und Wartung der Hardwarekomponenten.

Beispiele aus der Praxis

• Server-Wartung: Aktualisierung der Server-Firmware, um Sicherheitslücken zu schließen und die Leistung zu verbessern.
• Betriebssystemwechsel: Migration von Windows 10 auf Windows 11, um neue Funktionen zu nutzen und die Sicherheit zu erhöhen.

Kostenplanung

Bedeutung der Kostenkontrolle

Die Kostenplanung ist ein zentraler Bestandteil des Projektmanagements. Sie stellt sicher, dass das Projekt innerhalb des vorgegebenen Budgets bleibt und ermöglicht die rechtzeitige Identifikation von Budgetüberschreitungen.

• Budgetverwaltung: Überwachung und Kontrolle der Projektkosten, um sicherzustellen, dass das Budget nicht überschritten wird.
• Zukunftsprognosen: Abschätzung zukünftiger Kosten für noch ausstehende Projektphasen, um finanzielle Engpässe zu vermeiden.

Praktische Beispiele

• Industrielle Projekte: In der Automobilindustrie ist die Kontrolle der Kosten besonders kritisch, da hier hohe Investitionen erforderlich sind.
• Öffentliche Verwaltung: Projekte in der öffentlichen Hand und in Forschungsprojekten müssen strenge Budgetvorgaben einhalten.

Formeln und Konzepte

Budgetüberwachung

Eine grundlegende Formel zur Budgetüberwachung lautet:

$$\text{Aktuelle Ausgaben}+\text{Zuku¨nftige gescha¨tzte Ausgaben}\le \text{Gesamtbudget}$$

Diese Formel hilft dabei, den finanziellen Status des Projekts zu überwachen und rechtzeitig Gegenmaßnahmen zu ergreifen, falls das Budget gefährdet ist.

Schulungsplan

Notwendigkeit von Schulungen

Schulungspläne sind unerlässlich, um sicherzustellen, dass alle Beteiligten die notwendigen Kenntnisse und Fähigkeiten besitzen, um das neue System effektiv zu nutzen.

• Große Anwendergruppen: Beispiel des Uniklinikums Augsburg, wo über 3.500 Mitarbeiter geschult werden mussten.
• Schulungssysteme: Implementierung von Stehwahlsystemen zur effizienten Durchführung der Schulungen, um eine breite Anwenderbasis abzudecken.

Praktische Umsetzung

• Train-the-Trainer-Ansatz: Schulung einer kleinen Gruppe von Mitarbeitern, die ihrerseits ihre Kollegen schulen.
• Modulare Schulungen: Aufteilung der Schulungen in Module, die spezifische Funktionen und Prozesse abdecken.

Beispiele aus der Praxis

• Uniklinikum Augsburg: Schulung von über 3.500 Ärzten und Pflegekräften zur Bedienung eines neuen IT-Systems, inklusive der Implementierung von Schulungssystemen zur effizienten Durchführung.
• Softwarehaus-Beispiel: Einführung eines neuen ERP-Systems, das umfassende Schulungen für alle Abteilungen erfordert.

Bestandteile einer Projektplanung

Eine umfassende Projektplanung umfasst mehrere wesentliche Komponenten, die in der Praxis oft erst im Detail erarbeitet werden.

Wesentliche Komponenten

1. Aktueller Projektstand: Klare Definition, was bereits abgeschlossen ist und was noch aussteht.
2. Vorgehensweise: Planung der Schritte zur Umsetzung, z.B. Ablösung eines Altsystems oder Datenmigration.
3. Projektorganisation: Strukturierung des Teams und Zuordnung der Rollen.
4. Anlagen und Rahmenbedingungen: Berücksichtigung externer Faktoren wie Lieferzeiten und Ressourcenverfügbarkeit.
5. Aufgabenabgrenzung und Abhängigkeiten: Definition von Aufgaben und deren Abhängigkeiten voneinander.
6. Meilensteine und Prüfkriterien: Festlegung von Zwischenzielen und den Kriterien zu deren Erreichung.
7. Werteinsatzplanung: Abschätzung der Aufwände und Ressourcen zur Realisierung der Projektziele.
8. Ressourcenanforderungen: Identifikation und Planung zusätzlicher Ressourcen bei Bedarf.
9. Risikoanalyse: Identifikation und Bewertung potenzieller Risiken und deren Auswirkungen.
10. Grafischer Projektplan: Visuelle Darstellung des Projektverlaufs mit Terminen und Meilensteinen.
11. Projektergebnisse: Definition der zu liefernden Ergebnisse und deren Dokumentation.
12. Qualitätsmanagementbeschreibung: Integration des Qualitätsplans in die Projektplanung.

Detaillierte Betrachtung

Aktueller Projektstand

• Definition: Was ist bereits abgeschlossen? Was ist noch zu tun?
• Beispiel: Überprüfung der fachlichen Spezifikation auf Vollständigkeit und Korrektheit.

Vorgehensweise

• Strategie: Schrittweise Planung, z.B. Einführung neuer Technologien oder Anpassung bestehender Systeme.
• Beispiel: Umstieg von Windows 7 auf Windows 11 inklusive technischer Anpassungen.

Projektorganisation

• Teamstruktur: Festlegung von Rollen und Verantwortlichkeiten innerhalb des Teams.
• Qualitätsmanagement: Entscheidung über die Stärke des Qualitätsmanagements im Projekt, z.B. ob eine einzelne Person oder ein ganzes Team dafür verantwortlich ist.

Meilensteine und Prüfkriterien

• Definition eines Meilensteins: Ein Zwischenziel mit spezifischen Prüfkriterien.
• Beispiel: Fertigstellung der Datenbankanbindung als Meilenstein mit definierten Erfolgsparametern.
• Prüfkriterien: Kriterien, die erfüllt sein müssen, um den Meilenstein als erreicht zu deklarieren, z.B. erfolgreiche Verbindung zur Datenbank und funktionierende Schnittstellen.

Werteinsatzplanung

• Aufwandsabschätzung: Berechnung der benötigten Arbeitsstunden und Ressourcen.
• Beispiel: Vergleich von geplanten 250 Arbeitsstunden mit verfügbaren 80 Stunden zweier Mitarbeiter.
• Formel:

$$\text{Gesamtaufwand}=\sum _{i=1}^n{\text{Aufwand}}_i$$ $$\text{Verfu¨gbare Stunden}=\text{Anzahl der Mitarbeiter}\times \text{Arbeitsstunden pro Woche}$$

Ressourcenanforderungen

• Personelle Ressourcen: Identifikation von Engpässen und Planung zusätzlicher Mitarbeiter.
• Kritik am Hinzufügen von Mitarbeitern: Gefahr der Projektverzögerung durch Einarbeitungszeit neuer Teammitglieder.

Risikoanalyse

• Risikomanagement: Identifikation und Bewertung von Risiken, z.B. gesetzliche Änderungen wie der EU Artificial Intelligence Act.
• Beispiel: Anpassung der Softwareentwicklung an neue Datenschutzbestimmungen.

Grafischer Projektplan

• Visualisierung: Darstellung des Projektverlaufs mit Abhängigkeiten und Verantwortlichkeiten.
• Beispiel: Planung des Audi-Webseiten-Relaunchs mit verschiedenen Abteilungen und Terminen.

Projektergebnisse

• Definition der Liefergegenstände: Klarstellung, was das Projekt am Ende liefern soll (z.B. Software, Dokumentation, Testdaten).
• Beispiel: Entwicklung einer App inklusive Entwicklungsunterlagen und Testfallbeschreibungen.

Qualitätsmanagementbeschreibung

• Integration des Qualitätsplans: Sicherstellung, dass der Qualitätsplan eng mit dem Projektplan verknüpft ist.
• Beispiel: Beschreibung der Qualitätskontrollen und -standards, die während des gesamten Projekts angewendet werden.

Ressourcenmanagement

Anforderungen an weitere Ressourcen

In der Regel sind Projektleiter mit begrenzten Ressourcen konfrontiert. Die Identifikation und Planung zusätzlicher Ressourcen ist ein kritischer Aspekt:

• Personelle Ressourcen: Erkennung von Engpässen und Planung zusätzlicher Mitarbeiter.
• Effizienz vs. Erweiterung: Die Hinzufügung neuer Teammitglieder kann zu Verzögerungen führen, da diese eingearbeitet werden müssen.

Effiziente Ressourcennutzung

Statt das Team zu vergrößern, kann eine effizientere Nutzung der vorhandenen Ressourcen oft schneller zum Projekterfolg führen:

• Überstunden und Effizienz: Nutzung vorhandener Ressourcen durch erhöhte Arbeitsintensität.
• Beispiel: In der Schlussphase eines Projekts ist es oft effizienter, bestehende Teammitglieder Überstunden arbeiten zu lassen, anstatt neue Mitglieder hinzuzufügen.

Beispiele aus der Praxis

• Großes Projekt: Bei der Entwicklung einer komplexen Softwarelösung müssen zusätzliche Entwickler eingestellt werden, um das Projekt termingerecht abzuschließen. Dies kann jedoch zu Verzögerungen führen, da die neuen Mitglieder eingearbeitet werden müssen.
• Kleines Projekt: Eine kleine App kann durch eine Steigerung der Arbeitsstunden der bestehenden Entwickler schneller fertiggestellt werden, ohne das Team zu vergrößern.

Risikoanalyse

Bedeutung der Risikoanalyse

Eine umfassende Risikoanalyse ist unerlässlich, um potenzielle Probleme frühzeitig zu erkennen und geeignete Maßnahmen zu planen.

• Identifikation von Risiken: Erkennen von Risiken, die den Projektverlauf negativ beeinflussen könnten.
• Bewertung der Risiken: Einschätzung der Wahrscheinlichkeit und der potenziellen Auswirkungen der identifizierten Risiken.

Beispiele aus der Praxis

• Gesetzliche Änderungen: Neue Datenschutzbestimmungen, wie der EU Artificial Intelligence Act, können erhebliche Auswirkungen auf die Softwareentwicklung haben.
• Technische Risiken: Schwierigkeiten bei der Integration neuer Technologien oder unerwartete technische Probleme während der Entwicklung.

Formeln und Konzepte

Risikobewertung

Eine grundlegende Methode zur Bewertung von Risiken ist die Risikomatrix:

$$\text{Risikomatrix}=\left(\begin{array}{cc}\text{Wahrscheinlichkeit}& \text{Auswirkung}\\ \text{Niedrig}& \text{Gering}\\ \text{Mittel}& \text{Moderat}\\ \text{Hoch}& \text{Schwer}\end{array}\right)$$

Diese Matrix hilft dabei, Risiken nach ihrer Wahrscheinlichkeit und ihren potenziellen Auswirkungen zu priorisieren und geeignete Maßnahmen zu planen.

Projektplanung und Dokumentation

Grafischer Projektplan

Ein grafischer Projektplan bietet eine visuelle Darstellung des gesamten Projektverlaufs, inklusive Terminen, Meilensteinen und Ressourcen.

• Visualisierung: Darstellung von Aktivitäten und deren Abhängigkeiten.
• Beispiel: Planung des Audi-Webseiten-Relaunchs, wobei jede Abteilung ihre spezifischen Aufgaben hat und die Abhängigkeiten zwischen den Aktivitäten klar dargestellt sind.

Projektergebnisse

Die klar definierte Dokumentation der Projektergebnisse ist entscheidend für die erfolgreiche Abnahme und Implementierung.

• Definition der Liefergegenstände: Klarstellung, was das Projekt am Ende liefern soll (z.B. Software, Dokumentation, Testdaten).
• Beispiel: Entwicklung einer App inklusive Entwicklungsunterlagen, Testfallbeschreibungen und Schnittstellendokumentationen.

Dokumentationsstrategien

• Versionierung: Nutzung von Versionskontrollsystemen, um Änderungen an den Projektdokumenten nachzuverfolgen.
• Zugriffsrechte: Sicherstellung, dass nur autorisierte Personen Zugang zu den Projektdokumenten haben.

Vertragsmanagement

Lastenheft und Pflichtenheft

Das Lastenheft und das Pflichtenheft sind zentrale Dokumente im Vertragsmanagement, die die Anforderungen und die Umsetzung des Projekts festhalten.

• Lastenheft: Dokumentiert die Anforderungen des Auftraggebers an das Produkt.
• Pflichtenheft: Beschreibt, wie der Auftragnehmer die Anforderungen umsetzen will.

Unterschiede und Bedeutung

• Lastenheft: Fokus auf was gebaut werden soll, ohne technische Details.
• Pflichtenheft: Fokus auf wie die Anforderungen technisch umgesetzt werden.

Beispiele aus der Praxis

• Lastenheft: Ein Auftraggeber spezifiziert die Anforderungen für eine neue Adressenverwaltung, ohne technische Details zu nennen.
• Pflichtenheft: Der Auftragnehmer beschreibt, wie die Adressenverwaltung technisch umgesetzt wird, z.B. welche Programmiersprache verwendet wird und wie die Datenbank integriert wird.

Formeln und Konzepte

Anforderungsmanagement

Eine systematische Methode zur Verwaltung von Anforderungen kann durch folgende Schritte erreicht werden:

1. Anforderungserhebung: Sammeln aller Anforderungen des Auftraggebers.
2. Anforderungsanalyse: Bewertung der Anforderungen auf Machbarkeit und Relevanz.
3. Anforderungsdokumentation: Festhalten der Anforderungen im Lastenheft.
4. Anforderungsüberprüfung: Sicherstellung, dass alle Anforderungen korrekt und vollständig sind.
5. Anforderungsmanagement: Verwaltung von Änderungen und Ergänzungen während des Projektverlaufs.

Spezifikation von IT-Systemen

Bedeutung der Spezifikation

Die Spezifikation eines IT-Systems ist essenziell, um klar zu definieren, was entwickelt werden soll und wie die einzelnen Komponenten zusammenarbeiten.

• Klarheit: Definiert, was gebaut werden soll, und ermöglicht eine präzise Planung und Kostenabschätzung.
• Beispiel: Spezifikation einer Adressenverwaltung mit spezifischen Funktionen und Anforderungen.

Fachliche vs. Technische Spezifikation

Es ist wichtig, zwischen fachlichen und technischen Spezifikationen zu unterscheiden, um Missverständnisse und Fehler zu vermeiden.

• Fachliche Anforderungen: Beschreiben, was das System leisten soll, basierend auf den Bedürfnissen des Auftraggebers.
• Technische Spezifikation: Beschreibt, wie die fachlichen Anforderungen technisch umgesetzt werden, einschließlich der verwendeten Technologien und Architekturen.

Anforderungen und Leistungsbeschreibung

Anforderungskatalog

Ein Anforderungskatalog ist eine umfassende Liste der Anforderungen, die der Kunde an das System stellt.

• Beispiel: Eine Adressenverwaltung muss in der Lage sein, 200 Adressen zu verwalten, Serienbriefe zu erstellen und Schnittstellen zu externen Systemen bereitzustellen.

Leistungsbeschreibung

Die Leistungsbeschreibung ist ein detailliertes Dokument, das die zu erbringenden Leistungen im Vertrag festhält.

• Beispiel: Eine Leistungsbeschreibung für ein IT-Projekt könnte die Erstellung einer Adressenverwaltung, die Implementierung spezifischer Funktionen und die Bereitstellung von Schulungsmaterialien umfassen.

Formeln und Konzepte

Anforderungen präzisieren

Um sicherzustellen, dass die Anforderungen klar und präzise sind, kann eine Checkliste verwendet werden:

1. Klarheit: Sind die Anforderungen eindeutig und verständlich formuliert?
2. Vollständigkeit: Decken die Anforderungen alle notwendigen Funktionen ab?
3. Machbarkeit: Sind die Anforderungen technisch und finanziell umsetzbar?
4. Testbarkeit: Können die Anforderungen durch Tests überprüft werden?

Beispiele und Fallstudien

Fallstudie 1: Audi-Webseiten-Relaunch

Ein praktisches Beispiel zeigt die Komplexität der Projektplanung:

• Ziel: Relaunch der Audi-Webseite mit neuer Technik und verbessertem Benutzerinterface.
• Zeitplan: Neun Monate von Februar bis Dezember.
• Abteilungszuordnung: Verschiedene Abteilungen sind für spezifische Aufgaben verantwortlich.
• Abhängigkeiten: Die Datenbankanbindung muss abgeschlossen sein, bevor die Software integriert werden kann.
• Meilensteine: Fertigstellung der Datenbankanbindung, Implementierung des neuen Menüs, Abschluss der Tests.

Fallstudie 2: Entwicklung einer Ladesoftware für Elektroautos

Eine weitere Fallstudie verdeutlicht die Bedeutung der Ressourcenplanung:

• Projektumfang: Entwicklung einer Ladesoftware für das BMW ChargeNow System.
• Dauer: Drei Jahre Entwicklungszeit.
• Ressourcen: Tausende von Entwicklungstagen, ein großes Team von 10 Personen.
• Ressourcenplanung: Effektive Nutzung des Teams ermöglicht eine realistische Projektzeitplanung.

Formeln und Konzepte

Ressourcenberechnung

Zur Überprüfung der Machbarkeit des Projektplans wird die folgende Gleichung verwendet:

$$\text{Verfu¨gbare Stunden}=\text{Anzahl der Mitarbeiter}\times \text{Arbeitsstunden pro Woche}$$

Vergleicht man dies mit dem Gesamtaufwand, lässt sich feststellen, ob das Projekt innerhalb des geplanten Zeitrahmens abgeschlossen werden kann.

Change Management

Bedeutung des Change Control Boards (CCB)

Ein Change Control Board (CCB) ist ein Gremium, das Änderungen im Projekt verwaltet und genehmigt.

• Aufgaben: Bewertung von Änderungsanträgen, Entscheidung über die Umsetzung und Priorisierung von Änderungen.
• Beispiel: Eine Änderung des Betriebssystems von Windows 7 auf Windows 11 erfordert eine umfassende Bewertung der Auswirkungen auf das gesamte Projekt.

Unterschied zwischen traditionellen und agilen Projekten

• Traditionelle Projekte: Nutzen oft ein CCB, um Änderungen formal zu bewerten und zu genehmigen.
• Agile Projekte: Arbeiten mit selbstorganisierenden Teams, die Änderungen flexibel integrieren, ohne ein formales CCB.

Beispiele aus der Praxis

• Traditionelles Projekt: Einführung einer neuen Funktionalität erfordert die Genehmigung durch das CCB, um sicherzustellen, dass alle Auswirkungen berücksichtigt werden.
• Agiles Projekt: Ein Scrum-Team entscheidet eigenständig über die Integration neuer Funktionen während der Sprint-Planung.

Vertragsmanagement in IT-Projekten

Lastenheft vs. Pflichtenheft

Die Unterscheidung zwischen Lastenheft und Pflichtenheft ist entscheidend für das Verständnis der Anforderungen und deren Umsetzung.

• Lastenheft: Dokumentiert die Anforderungen und Erwartungen des Auftraggebers.
• Pflichtenheft: Beschreibt, wie der Auftragnehmer die Anforderungen technisch umsetzen will.

Unterschiede und Bedeutung

• Lastenheft:
  • Fokus: Was gebaut werden soll.
  • Inhalt: Fachliche Anforderungen, ohne technische Details.
  • Autor: Auftraggeber.
• Pflichtenheft:
  • Fokus: Wie die Anforderungen umgesetzt werden.
  • Inhalt: Technische Details, Implementierungsstrategien.
  • Autor: Auftragnehmer.

Praktische Beispiele

• Lastenheft: Ein Friseurgeschäft verlangt eine Adressenverwaltung für 200 Kunden mit der Möglichkeit, Serienbriefe zu erstellen.
• Pflichtenheft: Das Softwarehaus beschreibt, wie die Adressenverwaltung technisch umgesetzt wird, z.B. welche Datenbank verwendet wird und wie die Benutzeroberfläche gestaltet ist.

Formeln und Konzepte

Anforderungsmanagement

Eine systematische Methode zur Verwaltung von Anforderungen kann durch folgende Schritte erreicht werden:

1. Anforderungserhebung: Sammeln aller Anforderungen des Auftraggebers.
2. Anforderungsanalyse: Bewertung der Anforderungen auf Machbarkeit und Relevanz.
3. Anforderungsdokumentation: Festhalten der Anforderungen im Lastenheft.
4. Anforderungsüberprüfung: Sicherstellung, dass alle Anforderungen korrekt und vollständig sind.
5. Anforderungsmanagement: Verwaltung von Änderungen und Ergänzungen während des Projektverlaufs.

Spezifikation von IT-Systemen

Bedeutung der Spezifikation

Die Spezifikation eines IT-Systems ist essenziell, um klar zu definieren, was entwickelt werden soll und wie die einzelnen Komponenten zusammenarbeiten.

• Klarheit: Definiert, was gebaut werden soll, und ermöglicht eine präzise Planung und Kostenabschätzung.
• Beispiel: Spezifikation einer Adressenverwaltung mit spezifischen Funktionen und Anforderungen.

Fachliche vs. Technische Spezifikation

Es ist wichtig, zwischen fachlichen und technischen Spezifikationen zu unterscheiden, um Missverständnisse und Fehler zu vermeiden.

• Fachliche Anforderungen: Beschreiben, was das System leisten soll, basierend auf den Bedürfnissen des Auftraggebers.
• Technische Spezifikation: Beschreibt, wie die fachlichen Anforderungen technisch umgesetzt werden, einschließlich der verwendeten Technologien und Architekturen.

Anforderungen und Leistungsbeschreibung

Anforderungskatalog

Ein Anforderungskatalog ist eine umfassende Liste der Anforderungen, die der Kunde an das System stellt.

• Beispiel: Eine Adressenverwaltung muss in der Lage sein, 200 Adressen zu verwalten, Serienbriefe zu erstellen und Schnittstellen zu externen Systemen bereitzustellen.

Leistungsbeschreibung

Die Leistungsbeschreibung ist ein detailliertes Dokument, das die zu erbringenden Leistungen im Vertrag festhält.

• Beispiel: Eine Leistungsbeschreibung für ein IT-Projekt könnte die Erstellung einer Adressenverwaltung, die Implementierung spezifischer Funktionen und die Bereitstellung von Schulungsmaterialien umfassen.

Formeln und Konzepte

Anforderungen präzisieren

Um sicherzustellen, dass die Anforderungen klar und präzise sind, kann eine Checkliste verwendet werden:

1. Klarheit: Sind die Anforderungen eindeutig und verständlich formuliert?
2. Vollständigkeit: Decken die Anforderungen alle notwendigen Funktionen ab?
3. Machbarkeit: Sind die Anforderungen technisch und finanziell umsetzbar?
4. Testbarkeit: Können die Anforderungen durch Tests überprüft werden?

Zusammenfassung

Ein effektives Projektmanagement in der IT erfordert eine sorgfältige Planung und Strukturierung aller Projektkomponenten. Von der Teamdynamik über die Qualitätssicherung bis hin zur detaillierten Spezifikation der IT-Systeme – jede Phase spielt eine entscheidende Rolle für den Projekterfolg. Durch klare Dokumentation, effizientes Ressourcenmanagement und proaktives Risikomanagement können Projekte zielgerichtet und innerhalb des Budgets erfolgreich abgeschlossen werden.

Wichtige Formeln und Konzepte

Aufwandsabschätzung

Die Aufwandsabschätzung ist ein zentraler Bestandteil der Projektplanung. Eine einfache Formel zur Berechnung der benötigten Arbeitsstunden lautet:

$$\text{Gesamtaufwand}=\sum _{i=1}^n{\text{Aufwand}}_i$$

Dabei ist $n$ die Anzahl der Aktivitäten und ${\text{Aufwand}}_i$ der geschätzte Aufwand für jede einzelne Aktivität.

Ressourcenberechnung

Zur Überprüfung der Machbarkeit des Projektplans wird die folgende Gleichung verwendet:

$$\text{Verfu¨gbare Stunden}=\text{Anzahl der Mitarbeiter}\times \text{Arbeitsstunden pro Woche}$$

Vergleicht man dies mit dem Gesamtaufwand, lässt sich feststellen, ob das Projekt innerhalb des geplanten Zeitrahmens abgeschlossen werden kann.

Weitere Wichtige Konzepte

• Selbstorganisation in agilen Teams: In agilen Projekten, insbesondere in Scrum, organisieren sich die Teams selbst und definieren ihre Aufgaben ohne eine separate Projektleiterrolle.
• Change Control Board (CCB): Ein Gremium in traditionellen Projekten, das Änderungen am Projekt überwacht und genehmigt.
• Risikomanagement: Systematische Identifikation, Bewertung und Steuerung von Risiken, um negative Auswirkungen auf das Projekt zu minimieren.

---

FAQ: Projektplanung in der IT

1. Was sind die wichtigsten Bestandteile einer Projektplanung?

Eine umfassende Projektplanung in der IT-Welt beinhaltet weitaus mehr als nur ein simples Diagramm mit Terminen. Es ist entscheidend, den aktuellen Projektstand zu erfassen, einschließlich abgeschlossener und offener Tätigkeiten. Daraufhin muss die Vorgehensweise festgelegt werden, einschließlich der Ablösung von Altsystemen und etwa notwendiger Datenmigrationen. Die Projektorganisation mit klaren Rollen und Verantwortlichkeiten spielt ebenfalls eine zentrale Rolle. Qualitätssicherung, Auslieferungsplanung und Wartung sind weitere wichtige Elemente. Kostenpläne, Schulungspläne sowie Risikoanalyse dürfen nicht vernachlässigt werden.

2. Was sind Meilensteine in der IT und wie werden sie geprüft?

Ein Meilenstein ist ein Zwischenziel im Projektverlauf, welches an einen bestimmten Termin gekoppelt ist. Meilensteine helfen, den Fortschritt zu kontrollieren und sicherzustellen, dass alle wichtigen Punkte termingerecht erreicht werden. Um einen Meilenstein zu prüfen, werden vorab definierte Prüfkriterien herangezogen. Dies kann ein mehrstufiger Review-Prozess sein, bei dem die Ergebnisse vom Auftraggeber bewertet und freigegeben werden.

3. Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Im Lastenheft legt der Auftraggeber seine fachlichen Anforderungen an die Software dar. Er beschreibt, was er will, ohne dabei auf technische Details einzugehen. Das Pflichtenheft hingegen wird ebenfalls vom Auftraggeber erstellt, beschreibt aber sein fachliches Verständnis der im Lastenheft formulierten Anforderungen. Es geht dabei um die Frage, wie der Auftraggeber die Anforderungen interpretiert und umsetzen würde. Technische Details sind auch im Pflichtenheft nicht enthalten.

4. Was ist ein Fachkonzept und wozu dient es?

Ein Fachkonzept ist ein detailliertes Dokument, das die fachlichen Anforderungen an die Software in Textform ausarbeitet. Im Gegensatz zum Lastenheft ist es kein einfacher Anforderungskatalog, sondern eine umfassende Beschreibung der gewünschten Funktionalität. Technische Details der Implementierung finden sich auch im Fachkonzept nicht.

5. Wo liegt der Unterschied zwischen fachlichen und technischen Anforderungen?

Fachliche Anforderungen beschreiben, was die Software leisten soll, aus der Sicht des Kunden. Technische Anforderungen hingegen definieren, wie die Software realisiert wird, also die Implementierung. Die Grenze zwischen diesen Bereichen stellt die Verantwortlichkeitsgrenze dar: Der Kunde ist für die fachlichen Vorgaben zuständig, während die technischen Experten die Umsetzung verantworten.

6. Wie wichtig ist die Berücksichtigung von Änderungen im Projektverlauf?

Änderungen im Projektverlauf, wie z. B. neue Anforderungen oder gesetzliche Anpassungen, müssen sorgfältig gehandhabt werden. Sie beeinflussen den Zeitplan, die Kosten und die Qualitätssicherung. In traditionellen Projekten kommt hierfür ein Change Control Board (CCB) zum Einsatz, ein Gremium, welches über Änderungen berät und entscheidet. Auch in agilen Projekten ist es wichtig, Änderungen zu dokumentieren und ihre Auswirkungen zu bewerten.

7. Warum ist eine Risikoanalyse wichtig?

Eine Risikoanalyse identifiziert potenzielle Probleme, die den Projektverlauf negativ beeinflussen könnten. Dazu gehören beispielsweise technische Schwierigkeiten, Änderungen der gesetzlichen Rahmenbedingungen oder Ausfälle von Projektmitgliedern. Durch frühzeitige Erkennung und Planung von Gegenmaßnahmen können Risiken minimiert oder ihre Auswirkungen abgeschwächt werden.

8. Wozu dient ein Qualitätsplan?

Ein Qualitätsplan definiert die Maßnahmen zur Sicherstellung der Softwarequalität. Er legt fest, welche Qualitätsstandards gelten, wie Tests durchgeführt werden und welche Kriterien für die Abnahme der Software relevant sind. Der Qualitätsplan muss mit dem Projektplan abgestimmt sein und stellt sicher, dass die Software den Anforderungen des Kunden entspricht und fehlerfrei funktioniert.

---