Aufgabe: Projektorganisation und Mitarbeitereinsatz planen
Diese Aufgabe zeigt die Notwendigkeit, den Personalbedarf eines Projekts und die Mitarbeiterstruktur zu bestimmen.
Disziplinen: Projektmanagement
Zweck
  • Organisationsstruktur des Projekts definieren
  • Auf der Basis einer Schätzung wird der Mitarbeitereinsatz für die nächste Iteration (sowie die nachfolgenden) geplant. Dazu muss auch Erfahrung der ein gesetzten Personen und ihre Anzahl berücksichtigt werden. So kann man rechtzeitig mit der Anforderung zusätzlicher Mitarbeiter beginnen.
Beziehungen
Schritte
Projektorganisation definieren
Zweck Die Organisationsstruktur des Projekts bezüglich Positionen, Teams, Zuständigkeiten und Hierarchie definieren.  

Die Auswahl der Organisationsstruktur für das Projekt hängt von seinen Merkmalen und externen Vorgaben ab, wie z. B. bestehenden Geschäftsstrategien. Es ist daher schwierig, Strukturen genau zu beschreiben, weil das, was effektiv oder machbar ist, stark von den Gegebenheiten abhängt. Die Themen, die besprochen werden müssen, sind in der  Richtlinie: Softwareentwicklungsplan enthalten; dort finden Sie auch eine Standardprojektstruktur, die den jeweiligen Bedürfnissen angepasst werden kann. In der Standardstruktur wird vorgeschlagen, den RUP-Rollen Organisationspositionen zuzuordnen. Form und Größe der Projektorganisation unterscheiden sich in den einzelnen Phasen. Der Softwareentwicklungsplan ist kein statisches Dokument und wird ständig aktualisiert, um die Änderungen widerzuspiegeln.

Personalanforderungen definieren
Zweck Anzahl, Typ, Fachgebiet, Erfahrung und Seniorität der Mitarbeiter definieren, die für das Projekt eingesetzt werden sollen. 

Abhängig vom geschätzten Aufwand für Zeitplan, ausgewählte Organisationsstruktur und Zuordnung der Rollen bestimmt der Projektleiter das erforderliche Mitarbeiterprofil (Anzahl der Personen während des Projekts, Qualifikationsprofil). Die Aufwandsschätzung für ein Projekt hängt natürlich auch von Faktoren wie Teamgröße, Erfahrung und Seniorität ab; der Projektleiter hat wahrscheinlich bereits zuvor in seine Überlegungen die Qualifikation der einzelnen Mitarbeiter einbezogen. Im COCOMO-Berechnungsmodell (siehe Aufgabe: Phasen und Iterationen planen) sind die Mitarbeiter und ihre Erfahrung wichtige Triebfedern. Die Planung des Gesamtaufwands (durch Anpassen der verschiedenen COCOMO-Aufwandverstärker) und eines durchführbaren Zeitplans führt zu einer Entscheidung hinsichtlich des Mitarbeiterprofils.

In einigen Fällen weiß der Projektleiter evtl. im Voraus, wie viele Mitarbeiter mit welchem Know-how verfügbar sein werden. Sobald Mitarbeiter und Qualifikationsprofil feststehen, bleibt als einzige Variable der Zeitplan, vorausgesetzt, der Projektumfang bleibt unverändert.

Der Projektleiter muss wissen, welche katastrophale Auswirkungen auf das Projekt ein zu schnelles Aufstocken der Mitarbeiterzahlen, das Einbeziehen von zu vielen Mitarbeitern oder die radikale Verkürzung des Zeitplans haben können.

Mitarbeiter für die Konzeptions- und die Ausarbeitungsphase

Während der Konzeption liegt der Fokus auf dem Definieren und Eingrenzen des Projekts und auf dem Erstellen einer Kosten-Nutzen-Analyse. Daher ist das Team sehr klein; ein Projektleiter, ein Softwarearchitekt und vielleicht noch ein oder zwei Entwickler, vor allem dann, wenn ein Konzeptnachweis erforderlich ist, um die Anforderungen transparenter zu gestalten oder Produktunterstützung zu erstellen.

Während der Ausarbeitung liegt der Fokus primär auf der Architektur und dem architektonischen Prototyp. Das Design in der frühen Ausarbeitungsphase konzentriert sich daher auf architektonische Aspekte. Klassen und ihre Attribute sind zu dieser Zeit zwar identifiziert, aber für die Architektur nicht besonders wichtig. Während dieser Iterationen kommen die meisten Anstrengungen vom Architektur- und Prototyperstellungsteam. Das Prototyperstellungsteam besteht normalerweise aus erfahrenen Programmierern. Zu diesem Zeitpunkt ist das Designteam, das sich auf generische Mechanismen und Technologien konzentriert, sehr klein. Die Testgruppe konzentriert sich auf das Erstellen der Testumgebung und testet frühe Anwendungsfälle.

Die Auswahl der Mitglieder für das Architekturteam muss gut überlegt werden; sie müssen nicht nur hohe analytische und Designfähigkeiten haben, sondern auch außerordentliche Führungsqualitäten besitzen. Um die Architektur während der Konstruktionsphase einem größeren Team zu erklären, kann es sinnvoll sein, die Mitglieder des Architekturteams auf die Konstruktionsteams zu verteilen. Die Mitglieder des Architekturteams müssen auch über umfassende Software-Engineering-Kenntnisse verfügen; für Softwaredesign und -implementierung, Leistungsoptimierung, Datenbankmanagement, Netzmanagement und Konfigurationsmanagement sind ähnliche Qualifikationsprofile erforderlich wie für das Architekturteam.

Mitarbeiter für die Konstruktionsphase

Die Konstruktionsphase konzentriert sich auf das Beibehalten der architektonischen Integrität des Systems, während immer mehr Funktionen in das System integriert werden. Dies erfordert architektonische Verbesserungen (Ermittlung von Vergleichsdaten statt Einfrieren der Architektur nach der Ausarbeitungsphase); das Architekturteam behält die Designer und ihre Entwürfe im Auge.

Das Architekturteam sollte sich auf die Entwicklerteams verteilen, um dort Führungspositionen einzunehmen und die Themen zu behandeln, die sich zwischen den verschiedenen Gruppen und den anderen technischen Führungspositionen ergeben. Die Konstruktionsteams müssen sich aus Mitgliedern verschiedener Funktionsbereiche zusammensetzen, weil sie sowohl für das Design als auch für die Implementierung der zugeordneten Funktionalität zuständig sind. Normalerweise ist ein Konstruktionsteam für Subsysteme mit klar strukturierten Schnittstellen zuständig. Werden diese Schnittstellen verändert oder neue Subsysteme hinzugefügt, kann dies zu architektonischen Veränderungen führen. Innerhalb des Subsystems hat das Team relativ freie Hand beim Design und bei der Implementierung; trotzdem muss teamübergreifend kommuniziert werden, damit nicht mehrere Teams die gleichen Implementierungsmechanismen parallel entwickeln.

Konstruktionsteams sind normalerweise horizontal in verschiedenen Schichten organisiert. Ein Team ist z. B für Datenbankschnittstellen oder die Kommunikationsinfrastruktur verantwortlich, andere Teams konzentrieren sich auf die Funktionalität der Anwendung. Die Teams der "oberen" Schichten benötigen daher mehr Fachwissen in der Aufgabendomäne und dem Schnittstellendesign oder für die Schnittstellen zu externen Systemen. Teams in "unteren" Schichten kennen die Implementierungstechnologie genauer. Die Zusammensetzung dieser Teams muss die Skills für die unterschiedlichen Fachgebiete reflektieren.

Mitarbeiter für Testaufgaben

Die erste Frage beim Testen ist, wie viel formales Testen erforderlich ist. Dann muss überlegt werden, was getan werden soll, um die Qualitätsziele zu erfüllen und die Kosten und den Zeitplan trotzdem in einem vordefinierten Rahmen zu halten. Man hat selten ein Budget, das die Durchführung aller Arten von Tests erlaubt. Normalerweise muss man für ein Projekt eine Teststufe auswählen, die bezahlbar ist. Natürlich müssen die Testspezifikationen auch überprüft und gepflegt werden. Es ist nicht gut für das Arbeitsklima im Projektteam, wenn laut Plan viele Testspezifikationen erstellt werden sollen, die Implementierung aber aus Zeitgründen nicht mehr durchgeführt werden kann.

Stellen Sie ein spezielles Testteam zusammen. Mindestens eine Person muss aus einem Anforderungserfassungsteam kommen. Das Testteam ist für Folgendes verantwortlich:

  • Blackbox-Tests. Anwendungsfälle außerhalb des Systems auf der Basis ihrer Ereignisabläufe testen (siehe Arbeitsergebnis: Anwendungsfall).
  • Whitebox-Tests. Das Versenden von Nachrichten im Anwendungsfall auf der Basis der Anzeigenfolge für die Szenarios testen.
  • Systemtests. Die Belastbarkeit des Systems testen.

Zum Testen gehört nicht nur das Testen selbst, sondern auch die Vorbereitung einer Testumgebung und das Schreiben und Prüfen der Testdokumentation.

Eine unabhängige Gruppe sollte dann die Anwendungsfälle und das gesamte System testen. Sie sollte außerdem die Testberichte schreiben. Der Ablauf muss so organisiert sein, dass eine Person einen Anwendungsfall testet.

Wenn es nicht möglich ist, dass eine unabhängige Gruppe die Anwendungsfälle testet, wie z. B. bei einem sehr kleinen Projekt, muss zumindest sichergestellt sein, dass nicht die Person den Fall testet, die ihn entwickelt hat.

Für mittlere und große Projekte sind automatisierte Regressionstests sinnvoll. Das Testteam benötigt Programmierer zur Unterstützung. Dies ist bei der iterativen Entwicklung sehr wichtig, weil so vermieden wird, vollständige Testsuiten wiederholen zu müssen.

Mitarbeiter für die Übergangsphase

In der Übergangsphase wird die Entwicklungsarbeit abgeschlossen. Betatests werden durchgeführt und eine Endversion wird vorbereitet. Wenn die Konstruktion gut war, kann das Projektteam jetzt verkleinert werden, weil weniger Entwickler und Tester benötigt werden. Die Mischung des Teams verschiebt sich hin zu Schulungsleitern und Infrastrukturexperten, die für die Implementierung des Produkts und die Benutzergemeinde verantwortlich sind.

Der Softwarearchitekt bzw. das Architekturteam arbeitet jetzt im "Nachbereitungsmodus". Das heißt, es werden Fehlerberichte bearbeitet, Prioritäten für Änderungsanträge vergeben und Anträge verändert. So wird sichergestellt, dass Fehler nicht nur schnell behoben werden, sondern dass die Architektur durch die Reparatur nicht beschädigt wird. Designaufgaben treten während der Übergangsphase in den Hintergrund und sind auf Fehlerkorrektur oder auf die Einführung letzter funktionalen Erweiterungen begrenzt.