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.
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.
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.
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.
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.
|