Grundlagen des Prozesses
Auf dieser Seite werden die grundlegenden Elemente von RUP vorgestellt und einige Richtlinien erläutert, mit denen der Prozess für Ihre Anforderungen angepasst werden kann. Dies ist der Schlüssel zur Bewältigung des Drahtseilakts, qualitativ hochwertige Software sehr schnell zu liefern (das sog. Softwareparadox).
Hauptbeschreibung

Einführung

Dies ist der Schlüssel zur Bewältigung des Drahtseilakts, qualitativ hochwertige Software sehr schnell zu liefern (das Softwareparadox). Er liegt darin, die grundlegenden Elemente des Prozesses zu verstehen und bestimmte Richtlinien für die Anpassung des Prozesses an die spezifischen Anforderungen des Projekts zu befolgen. Halten Sie sich an die "Best Practices", die sich in der Branche für erfolgreiche Softwareentwicklung bewährt haben.   

Es folgt die Beschreibung der grundlegenden Prinzipien für einen effektiven Softwareprozess.

1. Vision: Vision entwickeln

Das Entwickeln einer klaren Vision ist der Schlüssel zu einem Produkt, das den echten Bedürfnissen Ihrer Stakeholder entspricht.

In RUP erfasst das Artefakt Vision Anforderungen und Designvorgaben auf sehr hoher Ebene, um dem Leser das zu entwickelnde System nahezubringen Es dient als Eingabe für den Projektabnahmeprozess und steht daher eng mit der Kosten-Nutzen-Analyse in Zusammenhang. Es klärt die grundlegenden Fragen "Warum" und "Was" des Projekts und ist ein Maßstab für alle künftigen Entscheidungen.

Der Inhalt der Vision, zusammen mit anderen Anforderungsartefakten, sollte die folgenden Fragen beantworten; sie kann auch in weitere, detailliertere Artefakte unterteilt werden:

  • Was sind die Schlüsselbegriffe? (Glossar)
  • Welche Probleme sollen gelöst werden? (Problembeschreibung)
  • Wer sind die Stakeholder? Wer sind die Benutzer? Was sind ihre Bedürfnisse?
  • Was sind die Produktmerkmale?
  • Was sind die funktionalen Anforderungen? (Anwendungsfälle)
  • Was sind die nicht funktionalen Anforderungen?
  • Was sind die Designvorgaben?

Der Kern dieser Disziplin und des Prinzips Konkurrierende Stakeholder-Prioritäten ausgleichen ist es, eine klare Vision und eine genaue Vorstellung von den Anforderungen zu erhalten. Man muss das Problem analysieren und die Bedürfnisse der Stakeholder kennen, bevor man das System definieren und die Anforderungen in ihrem Wandel verwalten kann.   

2. Plan: Verwaltung nach Plan

"Das Produkt ist nur so gut wie der Plan für das Produkt. ( FIS96 ).

Neues Projekt konzipieren, Umfang und Risiko bewerten, Projekt überwachen und steuern, Iterationen der einzelnen Phasen planen und bewerten: dies ist der Kern in der Disziplin "Projektmanagement".

In einem Softwareentwicklungsplan werden die für die Projektverwaltung erforderlichen Informationen zusammengestellt. Mit ihm werden Ressourcenbedarf und Anforderungen geplant und der Fortschritt anhand des Zeitplans überwacht. Er bezieht sich auf Bereiche wie Projektorganisation, Zeitplan, Budget und Ressourcen. Er kann auch Pläne für Anforderungsmanagement, Konfigurationsmanagement, Fehlerbehebung, Qualitätssicherung, Bewertung und Test sowie Produktabnahme enthalten.

In einem einfachen Projekt können diese Themen mit jeweils ein oder zwei Sätzen abgedeckt werden. Für das Konfigurationsmanagement könnte z. B. einfach stehen: "Am Ende jedes Arbeitstages muss die Verzeichnisstruktur des Projekts gezippt, die Zip-Datei auf einen mit Datum und Etikett versehenen externen Datenträger kopiert, mit einer Versionsnummer versehen und in einen zentralen Sicherungsschrank eingeschlossen werden.

Das Format der Planungsartefakte ist nicht so wichtig wie die Planungsaktivitäten selbst und die Aufmerksamkeit, die ihnen gewidmet wird. Das Aussehen des Plans spielt keine Rolle, auch nicht die Tools, mit denen Sie ihn entwickeln.  Schon Dwight D. Eisenhower sagte: "Der Plan ist nichts, die Planung alles."

3. Risiken: Risiken und überwachungsbedingte Probleme minimieren

Es ist sehr wichtig, die größten Risiken früh im Projekt zu identifizieren und zu minimieren, und die Überwachung auch der anderen Probleme entsprechend auszurichten. In der Liste der Risiken werden die Risiken erfasst, die erkannt wurden und den Projekterfolg gefährden können. Die Liste enthält, in absteigender Priorität, alle Ereignisse, die das Ergebnisse negativ beeinflussen könnten.

Für jedes Risiko muss ein Plan vorhanden sein. So können Projektaktivitäten geplant werden, die als Basis für die Iterationen dienen.

4. Kosten-Nutzen-Analyse: Kosten und Nutzen analysieren

Die Kosten-Nutzen-Analyse enthält die vom wirtschaftlichen Standpunkt erforderlichen Informationen, anhand derer entschieden wird, ob sich bei diesem Projekt die Investition lohnt oder nicht.

Mit der Kosten-Nutzen-Analyse wird hauptsächlich das Ziel verfolgt, einen Wirtschaftsplan für die Realisierung der Projektvision zu entwickeln. Sie wird erstellt, um eine präzise Einschätzung des Return on Investment (ROI) für das Projekt zu erhalten. Die Analyse liefert die Rechtfertigung für das Projekt und legt die wirtschaftlichen Vorgaben fest. Sie liefert den Entscheidungsträgern Informationen zum wirtschaftlichen Wert des Projekts und wird daher verwendet, um festzustellen, ob die Entwicklung des Projekts vorangetrieben werden sollte.

Die Beschreibung sollte nicht zu sehr in die Tiefe gehen, sondern Argumente liefern, warum ein Produkt gebraucht wird. Sie muss kurz sein, damit alle Projektteammitglieder sie verstehen und sich daran erinnern. Kosten und Nutzen werden an allen kritischen Meilensteinen erneut verglichen. So wird festgestellt, ob die Schätzungen bezüglich Ertrag und Kosten noch stimmen und ob das Projekt fortgesetzt wird.

5. Architektur: Komponentenarchitektur entwerfen

In Rational Unified Process (RUP) besteht die Architektur des Softwaresystems (zu einem gegebenen Zeitpunkt) aus der Organisation oder Struktur der wichtigen Komponenten; diese Komponenten wiederum setzen sich aus kleineren Komponenten und Schnittstellen zusammen. Was sind die Hauptkomponenten? Wie passen sie zusammen? Gibt es ein Framework, dem die restliche Software hinzugefügt werden kann?

Bevor Sie über die Softwarearchitektur sprechen können, muss die Darstellung definiert werden, in der wichtige Aspekte der Architektur beschrieben werden können. Diese Beschreibung ist im Softwarearchitekturdokument enthalten, das die Architektur aus unterschiedlichen Sichten darstellt.

Jede Architektursicht bezieht sich auf eine bestimmte Gruppe aus Überlegungen von Stakeholdern im Entwicklungsprozess: Benutzer, Entwickler, Manager, Systemberater, Wartungspersonal etc. Das Dokument dient als Kommunikationsmittel zwischen dem Softwarearchitekten und anderen Projektteammitgliedern und hilft ihnen bei wichtigen Projektentscheidungen.

Eine geeignete Architektur zu definieren, sie anzupassen, ihr Verhalten zu analysieren und die Komponenten des Systems zu entwerfen, das ist der Kern der Disziplin Analyse und Design und des Prinzips Abstraktionsstufe.

6. Prototyp: Produkt schrittweise erstellen und testen

RUP bietet eine iterative Methode, ausführbare Produktversionen zu erstellen, zu testen und zu bewerten; dadurch können Probleme früh erkannt und beseitigt werden.

Das schrittweise Erstellen und Testen der Systemkomponenten ist der Kern der Disziplinen Implementierung  und Test sowie des Prinzips Nutzen iterativ nachweisen.

7. Bewertung: Regelmäßige Ergebnisbewertung

Eine fortlaufende, offene Kommunikation auf der Basis objektiver Daten, die direkt aus den laufenden Aktivitäten und den entstehenden Produktkonfigurationen stammen, ist in jedem Projekt wichtig. Regelmäßige Statusbewertungen stellen einen Mechanismus für die Bearbeitung, Kommunikation und Behebung von Verwaltungsproblemen, technischen Problemen und Projektrisiken dar. Zusätzlich zur Identifizierung der Sachverhalte bzw. Probleme sollte ein Fälligkeitsdatum sowie eine für die Lösung zuständige Person festgelegt werden. Der jeweilige Stand muss regelmäßig überprüft und entsprechend aktualisiert werden.

Diese Projektmomentaufnahmen sind wichtig für das Management. Der Zeitraum kann variieren, aber die Erfassung der Projektgeschichte ist unerlässlich, damit Hindernisse und Engpässe aus dem Weg geräumt werden können.

Die Iterationsauswertung erfasst das Ergebnis einer Iteration, den Grad, zu dem die Bewertungskriterien erfüllt wurden, gesammelte Erfahrungen und zu implementierende Änderungen.

Die Iterationsauswertung ist ein wichtiges Artefakt der iterativen Methode. Je nach Umfang und Risiko des Projekts und der Art der Iteration kann es sich um einen einfachen Eintrag bezüglich Darstellung und Ergebnis bis hin zu kompletten Prüfunterlagen eines formellen Tests handeln.

Das Wesentliche ist hier, sich auf Prozess- und Produktprobleme zu konzentrieren: "Je früher Sie Zeit verlieren, desto schneller holen Sie sie wieder auf."

8. Änderungsanfragen: Änderungen verwalten und steuern

Sobald der erste Prototyp den Benutzern vorgestellt wird (und oft bereits auch früher), gibt es Änderungsanfragen. Das zeigt die Erfahrung! Um diese Änderungen zu steuern und den Stakeholdern Umfang und Erwartungen mitteilen zu können, müssen alle Änderungen der Entwicklungsartefakte anhand von Änderungsanfragen erfasst und konsistent verwaltet werden.

Mit Änderungsanfragen werden Schäden, sowie Änderungs- und Verbesserungsvorschläge für das Produkt dokumentiert und verfolgt. Der Vorteil von Änderungsanfragen ist, dass sie über Entscheidungen informieren und durch den Bewertungsprozess sicherstellen, dass die Auswirkungen potenzieller Änderungen von allen Projektteammitgliedern verstanden werden. Änderungsanfragen sind die Grundlage für die Verwaltung des Projektumfangs und für die Bewertung der Auswirkungen der vorgeschlagenen Änderungen.

Der Kern der Disziplin Konfigurations- und Änderungsmanagement und des unterstützenden Materials für die Aktivität 'Änderungen steuern' ist das Verwalten und Steuern des Projektumfangs; dabei werden die Änderungen während des Projektlebenszyklus integriert und die Bedürfnisse der Stakeholder bewertet und, wenn möglich, integriert.

9. Benutzerunterstützung: Verwendbares Produkt implementieren

Sinn und Zweck des Prozesses ist das Erstellen eines verwendbaren Produkts. Alle Aspekte des Prozesses müssen an diesem Ziel ausgerichtet werden. Das Produkt ist mehr als nur die Software. Mindestens ein Benutzerhandbuch und evtl. implementierte Onlinehilfe gehört ebenfalls dazu. Sie können auch ein Installationshandbuch und Release-Informationen einbeziehen. Abhängig von der Komplexität des Produkts sind Schulungsunterlagen oder Stücklisten erforderlich, sowie eine Produktverpackung. Die zugeordneten Vorgänge bilden die Disziplin Deployment

10. Prozess: Prozess wählen, der zum Projekt passt

Es ist von fundamentaler Wichtigkeit, dass der ausgewählte Prozess zu dem Produkttyp passt, den Sie entwickeln. Auch nachdem ein Prozess ausgewählt wurde, darf er nicht blind verfolgt werden. Gesunder Menschenverstand und Erfahrung sind für die Konfiguration von Prozess und Tools notwendig, damit die Ziele von Organisation und Projekt erfüllt werden können.

Das Anpassen eines Prozesses für das Projekt ist der wichtigste Teil der Disziplin Umgebung.

Weitere Informationen über den Einsatz von RUP für Projekt und Organisation finden Sie unter Konzept: Anpassung von RUP.

Fazit

Die oben angegebenen Kernpunkte helfen Ihnen dabei, einen Prozess schnell zu bewerten und die Bereiche zu identifizieren, die am meisten von Verbesserungen profitieren würden. Es ist wichtig festzustellen, was geschieht, wenn diese Kernaussagen ignoriert werden. Beispiele:

  • Keine Vsion? Sie verlieren das Ziel aus den Augen und gehen evtl. Umwege.
  • Kein Prozess? Ohne einheitlichen Prozess hat das Team evtl. falsche oder unterschiedliche Vorstellungen davon, wer was wann tut.
  • Kein Plan? Der Verarbeitungsfortschritt ist nicht erkennbar.
  • Keine Liste der Risiken? Sie konzentrieren sich jetzt evtl. auf die falschen Themen und treten erst Monate später auf eine Mine.
  • Keine Kosten-Nutzen-Analyse? Sie riskieren es, Zeit und Geld beim Projekt zu verlieren. Es wird vielleicht storniert oder die Mittel werden überschritten.
  • Keine Architektur? Koordination von Kommunikation, Synchronisation und Datenzugriff sind evtl. nicht möglich. Es kann zu Skalierungs- oder Leistungsproblemen kommen.
  • Kein Produkt (Prototyp)? Ein Produkt muss sobald wie möglich dem Kunden vorgestellt werden. Wer nur bedrucktes Papier ansammelt, stellt nicht unbedingt ein erfolgreiches Projekt zusammen - weder für sich noch für den Kunden. Außerdem wird das Risiko vergrößert, dass das Budget nicht eingehalten wird oder das Projekt komplett fehlschlägt.
  • Keine Bewertung? Stecken Sie Ihren Kopf nicht in den Sand! Man muss der Wahrheit ins Auge sehen. Können Sie den Endtermin wirklich einhalten? Qualitäts- oder Budgetziele? Werden alle Sachverhalte ausreichend erfasst und verfolgt?
  • Keine Änderungsanfragen? Wie werden Anforderungen von Stakeholdern verfolgt und geprüft? Welche Prioritäten haben sie? Wie wird verhindert, dass Themen mit geringerer Priorität durch das Raster fallen?
  • Keine Benutzerunterstützung? Was passiert, wenn ein Benutzer eine Frage oder mit dem Produkt Probleme hat. Wie einfach kann er Hilfe anfordern?

Diese Kernpunkte liefern auch eine Einführung in die Gruppierung: RUP-Disziplinen und unterstützen die wichtigen Prinzipien.