Aufgabe: Entwicklungsprozess für das Projekt anpassen |
|
 |
In dieser Aufgabe wird ein Entwicklungsprozess so angepasst, dass er bestimmten Anforderungen des Projekts genügt. |
|
Zweck
Diese Aufgabe hat folgenden Zweck:
-
Softwareentwicklungsprozess an die spezifischen Bedürfnisse des Projekts anpassen.
-
Relevante Prozessanleitungen in ausreichendem Umfang bereitstellen, so dass die Projektmitarbeiter ihre Jobs
effizient und in angemessener Qualität ausführen können.
-
Relevante und zugängliche Prozessbeschreibung für die Mitarbeiter des Projekts bereitstellen.
|
Beziehungen
Rollen | Hauptrollen:
| Zusätzliche Rollen:
| Unterstützende Rollen:
|
Eingaben | Verbindlich:
| Optional:
| Extern:
|
Ausgaben |
|
Hauptbeschreibung
Die folgenden Aufgaben liefern Informationen zur Entwicklung projektspezifischer Methoden-Assets. Sie werden im Rahmen
der Methodenentwicklungsschritte dieser Aufgabe ausgeführt:
Wenn ein Entwicklungsfall verwendet wird, wird die Aufgabe: Entwicklungsfall entwickeln zusammen mit dieser
Anpassungsaufgabe ausgeführt. |
Schritte
Projekt analysieren
Zweck:
|
Ein Gefühl für das vorliegende Problem und für die dem Projekt zur Verfügung stehenden Ressourcen
bekommen.
|
Für den Erfolg des Projekts ist entscheidend, dass der Bereitstellungsprozess für das jeweilige Projekt und für die
Größe sowie die Formalitätsanforderungen des Projekts relevant ist. Zu viel Prozess kann ein Hemmschuh für
Kreativität, Effektivität und Effizienz werden. Zu wenig Prozess kann zu einer chaotische Umgebung und dazu führen,
dass einzelne Projektmitarbeiter lokale Entscheidungen treffen, die ineffiziente, inkonsistente und unvorhersehbare
Ergebnisse zur Folge haben.
|
Umfang der Anpassungen definieren
Zweck:
|
Definieren, welche Prozessbereiche im projektspezifischen Prozess abgedeckt werden sollen.
|
Anhand der Ergebnisse der Analyse von Projektressourcen und ihren Erfahrungen in ähnlichen
Softwareentwicklungsprojekten können Sie den Umfang der Anpassung bestimmen. Ein projektspezifischer Prozess muss
nicht alle RUP-Disziplinen enthalten, und es muss nicht erforderlich sein, alle in RUP definierten Rollen
abzudecken. Beachten Sie, dass RUP ein Prozessframework ist, das für einen weiten Bereich von Projekttypen geeignet
und somit viel zu umfangreich ist, als dass es von einem spezifischen Projekt in seiner Gesamtheit befolgt werden
könnte. Welche Bereiche für den Projektprozess ausgewählt werden, richtet sich stark nach dem Qualifikationsprofil
der Projektmitarbeiter und der Art des durchzuführenden Projekts. Im Folgenden sind einige typische Überlegungen
beschrieben, die bei der Definition des Anpassungsumfangs berücksichtigt werden müssen.
-
Bereiche, in denen die Projektmitarbeiter bereits eine gemeinsame Arbeitsweise haben und in denen es nicht
erforderlich ist, einen neuen Prozess und neue Tools einzuführen. Wenn die Projektmitarbeiter wissen, wie Tests
durchgeführt werden, ist es mitunter keine sinnvolle Lösung, die RUP-Disziplin Test einzuführen, um die Anzahl
neuer Faktoren zu begrenzen. Sie können sich auf die Einführung solcher Teile des RUP konzentrieren, die sich
mit der Behebung von Problemen im vorhandenen Prozess beschäftigen. Ausführliche Informationen finden Sie auf
der Seite Konzept: Prozess in einem Projekt implementieren im Abschnitt "Prozess und
Tools verbessern".
-
Bereiche (Disziplinen), in denen das Projekt einen neuen Prozess und neue Tools einführen muss, weil es keine
gemeinsame Arbeitsweise gibt. Manchmal gibt es keinen Prozess und keine Tools, auf die zurückgegriffen werden
kann, und es ist erforderlich, den größten Teil von RUP zusammen mit unterstützenden Tools einzuführen.
Ausführliche Informationen hierzu finden Sie auf der Seite Konzept: Prozess in einem Projekt implementieren im Abschnitt "Alles".
-
Probleme im vorhandenen Prozess. Konzentrieren Sie sich auf die Verbesserung solcher Bereiche, in denen die
Organisation Probleme hat.
-
Welche Tools sollen verwendet werden? Wenn das Projekt sich für die Verwendung bestimmter Tools entschieden
hat, sollte der Entwicklungsprozess normalerweise die entsprechenden Bereiche des RUP abdecken.
-
Die Fähigkeit des Projekts, sich den Änderungen zu stellen. Wenn man sich die Probleme der Organisation
anschaut, ist die Versuchung groß, alles auf einmal korrigieren zu wollen, insbesondere weil viele dieser
Probleme gleichzeitig auftreten. Diese Vorgehensweise erweist sich in der Regel als verhängnisvolle Falle.
Organisationen sind wie Einzelpersonen in der Lage, mit Änderungen umzugehen, aber nur in einem begrenzten
Maße. Wenn die Änderungsfähigkeit gering ist, müssen Sie langsamer vorgehen und möglicherweise im ersten
Projekt nur eine oder zwei Disziplinen von RUP einführen.
-
Bereiche, in denen es den Projektmitarbeitern an Wissen fehlt oder in denen die Mitarbeiter schwach sind.
Lassen Sie diese Bereiche vom Entwicklungsprozess abdecken. Stellen Sie sicher, dass die richtigen
Informationen in RUP einfach zu finden sind.
Weitere Informationen zum Definieren des Anpassungsumfangs finden Sie im Abschnitt Richtlinie: RUP anpassen.
Eine Beschreibung der Faktoren, die sich auf die Anpassung eines Prozesses für ein Projekt auswirken, finden Sie in
Richtlinie: Prozessdiskriminanten.
Gefundene verbesserungswürdige Bereiche müssen nicht unbedingt zusammen in demselben Projekt eingeführt werden.
Reduzieren Sie die Anzahl der unbekannten Faktoren und sehen Sie sich die Bereiche an, in denen die
Entwicklungsorganisation in der Vergangenheit die meisten Schwierigkeiten hatte. Wir empfehlen, RUP iterativ zu
implementieren. Diesbezügliche Informationen können Sie der Seite Konzept: Prozess in einem Projekt implementieren entnehmen. Für kleine Projekte
gibt es eine Anleitung auf der Seite Beispiel: Ein kleines Projekt mit RUP.
Obwohl Sie möglicherweise in mehreren Disziplinen den Bedarf an Verbesserungen erkannt haben, sollten Sie sich die
Option einer iterativen Einführung im Verlauf mehrerer Projekte in Erwägung ziehen, anstatt sich für eine
einstufige Änderung zu entscheiden. Es bietet sich beispielsweise an, zuerst Anforderungen mit Anwendungsfällen
einzuführen und die Einführung eines neuen Änderungsmanagementprozesses hinauszuzögern, wenn vorherige Projekte mit
unklaren und/oder nicht ausreichenden Anforderungen zu kämpfen hatten oder wenn ernstzunehmende Beschwerden von
Kunden eingegangen sind, dass das gelieferte Produkt ihren Anforderungen nicht entspricht.
Die vorgenommenen Abwägungen und der sich daraus ergebende Änderungsumfang müssen als Teil des Prozesses
dokumentiert werden, um die Entscheidungen externen Stakeholdern vermitteln zu können.
|
Projektspezifischen Inhalt entwickeln
Zweck:
|
Zusätzliches "Prozess-Know-how" in den Bereichen entwickeln, in denen die Abdeckung im RUP-Prozessframework
für das Projekt unzureichend zu sein scheint.
|
Das RUP-Methodenframework manifestiert sich in einem Prozessmodell, das mit Hilfe eines UML-basierten Metamodells
definiert wird. Das RUP-Methodenframework basiert auf einem Metamodell, der so genannten "Unified Method Architecture"
(UMA). Die Grundlagen von UMA sind in Konzept: Hauptfunktionalität von Unified Method Architecture (UMA) beschrieben.
Sie können das RUP-Framework durch Hinzufügen von Rollen, Aufgaben und/oder Arbeitsergebnissen erweitern, oder Sie können projektspezifische Anleitung zum vorhandenen RUP-Framework hinzufügen.
In jedem projektspezifischen Prozess sollte es eine angepasste Gruppe verfügbarer Ressourcen geben, die
spezifische Hilfe und Referenzmaterial für die Produktion von Projektartefakten bereitstellen. Beispiele für
solche Ressourcen sind:
-
Allgemeine Richtlinien für die Produktion bestimmter Artefakte.
-
Vorlagen, die für die Verwendung in Projekten angepasst sind. Diese werden teilweise mit Projektinformationen
instanziert.
-
Artefaktbeispiele, die für die definierten Liefergegenstände und die ausgewählte Technologie des Projekts relevant
sind.
-
Wiederverwendbare Assets, z. B. Designmuster und Codebibliotheken.
Zu Beginn des Projekts wählt der Projektleiter in der Regel zusammen mit dem Prozessentwickler die entsprechenden Ressourcen aus und stellt sie
den Projektmitarbeitern im Rahmen des projektspezifischen Prozesses zur Verfügung. Der Bedarf an zusätzlichen
Ressourcen wird am Anfang jeder Iteration überarbeitet.
|
Prozess konfigurieren
Zweck:
|
Prozess so anpassen, dass der den exakten Bedarf eines Projekts unterstützt.
|
Zum Konfigurieren eines Prozesses gehört die Auswahl des Methodeninhalts (Arbeitsergebnisse, Aufgaben, Rollen usw.),
der in den Prozess aufgenommen werden muss. Spezielle Empfehlungen zur Auswahl der Methodenelemente für jede Disziplin
finden Sie in den Richtlinien "Wichtige Entscheidungen in der <Disziplin xxx>", die für jede der RUP-Disziplinen
bereitgestellt werden. Die Auswahl des richtigen Methodeninhalts für ein bestimmtes Projekt ist keine triviale
Aufgabe. Um effektiv zu sein, muss der Prozess in verschiedenen Dimensionen relevant und korrekt angepasst sein.
Beispiele für diese Dimensionen sind die Projektgröße (Ressourcen und Dauer), Formalität, technologische Plattform,
Domäne.
Weitere Informationen zum Klassifikationsschema für die Dokumentation der Bedeutung einzelner Arbeitsergebnisse und
deren Verwendung finden Sie in Richtlinie: Arbeitsergebnisse klassifizieren.
|
Lebenszyklusmodell für das Projekt definieren
Zweck:
|
Lebenszyklusmodell für das Projekt definieren.
|
Ein wichtiger Teil der Anpassung eines Prozesses für ein Projekt ist die Entscheidung über ein Lebenszyklusmodell für
das folgende Projekt, einschließlich der Strukturierung in Phasen und Iterationen. Für diesen Teil der
Anpassungsarbeiten muss der Prozessentwickler eng mit dem Projektleiter zusammenarbeiten, da das gewählte
Lebenszyklusmodell die Grundlage für den Projektplanungsprozess bildet. Je nach Art des Projekts muss der
RUP-Lebenszyklus möglicherweise an die speziellen Bedürfnisse angepasst werden. Green-Field-Entwicklung erfordert
beispielsweise in der Konzeptionsphase gewöhnlich mehr Aufwand als ein Wartungsprojekt. Deshalb muss die
Lebenszyklusbeschreibung an die Art des Projekts angepasst werden. Auf der Seite Konzept:
Iterationen finden Sie eine Beschreibung der verschiedenen Typen von Lebenszyklusmodellen.
Zusätzlich zur Auswahl des Gesamtlebenszyklusmodells muss außerdem entschieden werden, wie die Workflows für
die einzelnen Disziplinen, die von den Anpassungen betroffen sind, ausgeführt werden, und zu welchem Zeitpunkt
im Projektlebenszyklus die einzelnen Teile des Workflows jeder Disziplin eingeführt werden. Die Entscheidung darüber,
wie der Workflow ausgeführt wird, beinhaltet auch die Entscheidung darüber, welche Aktivitäten ausgeführt werden und in
welcher Reihenfolge. Die Entscheidung darüber, wann die einzelnen Teile des Workflows ausgeführt werden, beinhaltet
auch die Entscheidung darüber, zu welchem Zeitpunkt im Lebenszyklus (z. B. in welcher Phase) die ausgewählten
Aktivitäten ausgeführt werden. Weitere Informationen zum Anpassen des Workflows für jede der RUP-Disziplinen finden Sie
in den Verwendungshinweisen für die Referenzworkflows, die für die einzelnen RUP-Disziplinen bereitgestellt werden.
Einige zusätzliche Informationen, die Sie zu diesem Zeitpunkt angeben können, sind die Ablauf- und
Formalitätsanforderungen der Arbeitsergebnisse an verschiedenen Punkten im Lebenszyklus, z. b. in welchen Phasen ein
Arbeitsergebnis erstellt und/oder aktualisiert wird und welche Formalität bei dem jeweiligen Arbeitsergebnis
eingehalten werden muss (erfordert es beispielsweise ein formale Abnahme durch den Kunden).
|
Prozess für die Projektmitarbeiter verfügbar machen
Zweck:
|
Den projektspezifischen Prozess für die Projektmitarbeiter verfügbar machen.
|
Nach den ersten Anpassungsarbeiten muss der entstandene Prozess dem Projektteam in einem "verdaulichen" Format
verfügbar gemacht werden.
Eine Möglichkeit ist die, den Prozess über eine Website verfügbar zu machen, die sich entweder auf einem Webserver
im Netz der Organisation befinden oder auf den Computern der einzelnen Teammitglieder installiert werden kann. Wenn
die Projektmitarbeiter die meiste Zeit über mit dem Netz verbunden sind, wird das Deployment der Website auf einem
Webserver empfohlen, um Mehraufwand zu vermeiden, der bei Aktualisierungen des Prozesses während des
Projektlebenszyklus entsteht.
|
Prozess verwalten
Obwohl der Großteil der Anpassungsarbeiten in den frühen Stadien des Projekts durchgeführt werden, muss der Prozess
ständig auf dem neuesten Stand gehalten werden, da die Projektteams Hindernisse und andere Probleme im Prozess
feststellen werden. Je weiter sich der Prozess entwickelt, desto mehr Erfahrungen werden während des Prozesses selbst
gesammelt, die der Prozessentwickler als Feedback verwenden kann, um den Prozess zu verbessern. Auch während des
Projekts vorgenommene Bewertungen sind eine wichtige Eingabe für die Verbesserung des Prozesses.
Geringfügige Anpassungen werden normalerweise vom Projekt gehandhabt. Aktualisierungen am projektspezifischen Prozess
werden vorgenommen, wenn die Entwicklungsumgebung für die bevorstehende Iteration vorbereitet wird. Diese Art von
Prozessverbesserungen führen häufig zu Aktualisierungen am projektspezifischen Prozess (z. B. Präzisierungen der
Arbeitsergebnisvorlagen und -richtlinien. Komplexere Probleme werden als Änderungsanfragen im Prozess erhoben.
Einer der Hauptvorteile der iterativen Entwicklung besteht darin, dass die Projektteams allmählich die Art und Weise
verbessern, in der sie Software entwickeln. Wir empfehlen, dass jedes Projekt Mikrozyklen für das Prozess-Engineering
einbaut, die sich aus den folgenden Schritten zusammensetzen:
|
|
Eigenschaften
Mehrere Vorkommen |  |
Ereignisgesteuert |  |
Fortlaufend |  |
Optional |  |
Geplant |  |
Wiederholt anwendbar |  |
Abbildungen
Wichtige Hinweise
Egal welche Stufe der Anpassung durchgeführt wird, es ist wichtig, dass die Ergebnisse der (und möglicherweise die
Begründung für die) Anpassung erfasst werden. Wenn der angepasste Prozess voraussichtlich nochmals angepasst wird,
(beispielsweise zuerst eine gesamte Organisation und anschließend dann für die einzelnen Projekte erneut), müssen Sie
außerdem Richtlinien erstellen, die beschreiben, wie der angepasste Entwicklungsprozess angepasst wird. Solche
Anpassungsentscheidungen und -empfehlungen können in einem separaten Dokument oder als integraler Bestandteil des
Entwicklungsprozess erfasst werden. Weitere Informationen zu den Anpassungsstufen finden Sie in Konzept: RUP anpassen.
Der Softwareentwicklungsplan und die Organisation haben großen Einfluss
auf den Entwicklungsprozess und umgekehrt. Die Anpassung des Prozesses muss
mit der Entwicklung des Projektplans koordiniert werden. Wenn das Projekt beispielsweise entscheidet, andere Phasen als
in Rational Unified Process (RUP) zu verwenden, ist dies etwas, was in dem angepassten Entwicklungsprozess erfasst
werden muss. Nachdem der Entwicklungsprozess angepasst wurde, muss er zu einem umsetzbaren Projektplan instanziert
werden. Weitere Informationen zur Projektplanung finden Sie in Aufgaben: Phasen und Iterationen planen und Aufgabe: Iterationsplan entwickeln.
Wir empfehlen, dass Sie nicht den gesamten Prozess auf einmal anpassen. Konzentrieren Sie sich stattdessen auf die
Disziplin, die als nächstes im Projekt angewendet wird. Weitere Informationen zu einem iterativen Ansatz für die
Prozessimplementierung finden Sie in Konzept: Prozess in einem Projekt implementieren.
Sofern eine Bewertung der Entwicklungsorganisation verfügbar ist, zeigt diese die
Bereiche auf, auf die sich die Entwicklungsorganisation als Ganzes konzentrieren muss. Es muss entschieden werden,
welche der angegebenen verbesserungsfähigen Bereiche für das Projekt in Angriff genommen werden sollen. Diese
Entscheidung wirkt sich direkt auf den Umfang der Anpassungen aus..
Das Anpassen des Prozesses für ein Projekt muss als eigenes Projekt mit eigenen Plänen, eigenem Budget und eigenen
Steuermechanismen behandelt werden. Sie müssen basierend auf der Return-on-Investment-Analyse einen Geschäftsfall für
dieses Projekt definieren. Der eigentlichen Entwicklung des Plug-in können die Einhaltung des Lebenszyklus und der
Disziplinen in RUP zu Gute kommen. Es wird empfohlen, die Hauptideen, die hinter dem Plug-in stecken, in einem echten
Projekt auszuprobieren, bevor Sie das Projekt für die Entwicklung des Plug-in starten.
Ein Entwicklungsfall kann verwendet werden, um Anpassungsentscheidungen (z.
B. welche Teile von RUP angepasst wurden und warum) sowie Richtlinien für künftige Anpassungen zu dokumentieren. Je nach
Grad der vorgenommenen Anpassung kann der Entwicklungsfall in den Entwicklungsprozess selbst aufgenommen oder lediglich für die Planung,
Steuerung und Dokumentation der Anpassungen verwendet werden. Weitere Informationen zu Anpassungsebenen finden Sie im
Abschnitt RUP anpassen. |
Alternativen
Es gibt mehrere unterschiedliche Stufen der Anpassung für RUP. Weitere Informationen finden Sie in Konzept: RUP anpassen. |
Weitere Informationen
Konzepte |
|
Richtlinien |
|
Toolmentoren |
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|