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