Der Softwareentwicklungsprozess wird durch die folgenden Faktoren beeinflusst:
-
Domänenfaktoren wie Anwendungsdomäne, zu unterstützender Geschäftsprozess, Benutzergruppe und verfügbare
Produktangebote von Mitbewerbern.
-
Lebenszyklusfaktoren wie Einführung am Markt, erwartete Lebensdauer der Software und geplante künftige Releases.
-
Technische Faktoren wie Programmiersprache, Entwicklungstools, Datenbank, Komponenten-Frameworks und vorhandene
Softwaresysteme.
-
Organisatorische Faktoren.
Diese Faktoren haben nicht alle dieselbe Bedeutung. In den folgenden Abschnitten werden einige der Hauptfaktoren
beschrieben, und zwar die, die sich wahrscheinlich auf die gesamte Form des Entwicklungsprozesses auswirken und
bestimmen, wie Sie den Prozess und die Tools in der Entwicklungsorganisation implementieren.
Der Geschäftskontext beschreibt den Kontext, in dem die Software entwickelt wird. Es gibt verschiedene Typen von
Business-Kontexten, die sich darauf auswirken, wie der Prozess am besten angepasst wird. Beispiele für
Geschäftskontexte:
-
Vertragsarbeit, bei der der Entwickler Software für eine bestimmte Kundenspezifikation und nur für diesen Kunden
erstellt.
-
Spekulative oder kommerzielle Entwicklung, bei der der Entwickler die Software erzeugt und die Kosten dafür
übernimmt, die Software auf den Markt zu bringen.
-
Interne Projekte, bei denen Kunde und Entwickler derselben Organisation angehören.
Es gibt zahlreiche Zwischensituationen, z. B. Situationen, in denen nur ein Teil der Softwareentwicklung im Rahmen
eines Unterauftrags übertragen wird, Situationen, in denen die geographische Verteilung einen zusätzlichen Faktor
darstellt usw. Die Gesamtanzahl der unterschiedlichen Stakeholder ist ein guter Anhaltspunkt für den Geschäftskontext.
Der Geschäftskontext wirkt sich auf den Grad der Zeremonie, den Grad der Formalität und die Starre des Prozesses aus.
Je mehr Stakeholders (Geldgeber), Kunden, Unterauftragnehmer, Genehmigungsbehörden usw. involviert sind, desto
wahrscheinlicher ist es, dass das Projekt formale Nachweise wie Dokumente, Berichte und Prototypen an den wichtigen
Projektmeilensteinen produzieren muss.
Die Größe des Softwareentwicklungsaufwands, die durch bestimmte Metriken wie Quellcodezeilen (SLOC, Source Lines of
Code), gelieferte Quellenanweisungen oder Funktionspunkte, Anzahl der Mannmonate oder rein durch die Kosten ermittelt
werden kann.
Die Größe des Aufwands wirkt sich auf den Grad der Zeremonie, den Grad der Formalität und die Starre des Prozesses aus.
Unabhängig vom Geschäftskontext gilt, dass mit zunehmender Größe des Projekts auch die Größe des Entwicklungsteams
zunimmt und die verschiedenen Teams und das Management mehr Formalität und Transparenz in Anforderungen, Schnittstellen
und Fortschrittsindikatoren erbringen müssen. Kommunikationsprobleme nehmen in großen Projekten noch weiter zu, wenn
die Teams geografisch verstreut sind.
Der Neuheitsgrad basiert darauf, was dem Softwareaufwand relativ zur Entwicklungsorganisation vorausgegangen ist
und insbesondere ob die Entwicklung sich in einem zweiten Zyklus oder Folgezyklus befindet. Dazu gehören die Reife der
Organisation und ihres Prozesses, ihre Assets, ihr aktuelles Qualifikationsprofil und Aspekte wie die Zusammenstellung
und Ausbildung eines Teams, der Erwerb von Tools und anderer Ressourcen.
Der Neuheitsgrad eines Projekts wirkt sich auf den Prozess in einer ganz anderen Weise aus. Ein neues Projekt - das
erste seiner Art - betrifft die dynamische Konfiguration: Die Konzeptions- und Ausarbeitungsphasen sind länger und
erstrecken sich möglicherweise über mehrere Iterationen. Außerdem wird mehr Schwerpunkt mehr auf die Sondierung und
Erfassung von Anforderungen, auf die Anwendungsfallmodellierung, auf die Architektur und auf die Risikominderung
gelegt. In einem Projekt, das sich in einem Weiterentwicklungszyklus befindet (d. h. es gibt bereits ein
früheres System), ist das Änderungsmanagement ausschlaggebender, und die Integration des Codes aus der früheren Version
stellt eine gewisse technische Herausforderung dar.
Neuheit ist nicht nur relativ zu dem zu entwickelnden System zu betrachten, sondern auch relativ zur Reife der
ausführenden Organisationen, da sich die Einführung neuer Techniken oder Tools auf den Prozess auswirkt. Insbesondere
die Einführung von Rational Unified Process (RUP) in eine Organisation muss sorgfältig vorgenommen werden. Eine
Organisation legt in der Regel eine gewisse Trägheit in Bezug auf die Einführung eines neuen Prozesses an den Tag, und
die Einführungsstrategie muss für einen reibungslosen Übergang von vorhandenen Verfahren auf neue sorgen.
Es gibt verschiedene Typen von Anwendungen, z. B. Embedded-Echzeitsysteme, dezentrale Informationssysteme,
Telekommunikationssysteme, CASE-Tools (Computer-Aided Software Engineering) usw. Der Typ der Anwendung hat Einfluss auf
den Prozess, insbesondere in Bezug auf bestimmte Einschränkungen, die die Domäne der Entwicklung auferlegen kann, z. B.
Sicherheit, Leistung Internationalisierung, Hauptspeicher usw.
Der Typ der Anwendung kann sich auf den Prozess auswirken, wenn die Anwendung geschäftskritisch ist, wie z. B. das
Flugreglersystem in einem Flugzeug. Ein geschäftskritisches System erfordert im Allgemeinen ein höheres Maß an
Zeremonie, um Anforderungen zu verfolgen und die Qualität des Produkts zu gewährleisten. Außerdem muss bei einer
geschäftskritischen Anwendung mehr Ressourcen für Tests eingesetzt werden.
Der Typ der Entwicklung bzw. die Zieldomäne bringt Prozessaspekte wie die folgenden ein:
-
Techniken und Tools für die Unterstützung bestimmter Aufgaben, z. B. automatische Codegenerierung für
Endzustandsmaschinen.
-
Zertifizierungsprozeduren, z. B. für medizinische Geräte.
-
Einhaltung von Standards, z. B. für Abrechnungs- oder steuerrechtliche Aspekte oder für Telekommunikationsanlagen.
Es gibt verschiedene Entwicklungstypen, z. B.:
-
Vertragsarbeit: Hier wird ein Produkt für einen speziellen Kunden entwickelt. Wenn Sie Vertragsarbeiten
ausführen, müssen Sie mehr Stakeholder verwalten und mit diesen verhandeln. Häufig müssen mehr formal-externe
Arbeitsergebnisse erzeugt werden, weil der Kunde oder Kundenvertreter den Fortschritt überwachen und ständig
informiert sein möchten. Stellen Sie sicher, dass die Arbeitsergebnisse, die der Kunde prüft, leicht verständlich
sind. Manchmal muss ein Meilenstein angesetzt werden, an dem das Projekt einen Festpreis für den Rest des Projekts
anbieten kann. In diesem Fall müssen Sie möglicherweise einen neuen Meilenstein hinzufügen oder die vorhandenen
Meilensteine anpassen. In anderen Fällen müssen Sie sich möglicherweise an das Lebenszyklusmodell anpassen, das der
Kunde verwendet und das möglicherweise andere Meilensteine und Phasen hat.
-
Spekulative Entwicklung: Hier entwickeln Sie ein Produkt für einen Massenmarkt. Bei der spekulativen
Entwicklung tritt ein Vertriebs- bzw. Produktmanager innerhalb der Organisation als Kunde auf. Die
Markteinführungszeit ist bei spekulativer Entwicklung häufig wichtiger als die Funktionalität, und der Bedarf an
formalen Prüfungen ist nicht so hoch.
-
Interne Entwicklung: Hier entwickeln Sie ein Produkt, das an eine andere Abteilung innerhalb des
Unternehmens geliefert wird. Sie müssen sich möglicherweise an ein anderes Lebenszyklusmodell anpassen, wenn Ihr
Produkt ein Beitrag für ein anderes Projekt ist, in dem RUP nicht angewendet wird. Eine technischere Beschreibung
der Arbeitsergebnisse kann hier zulässig sein, weil die meisten Arbeitsergebnisse von Kollegen geprüft werden.
-
Vorabstudien: Hier entwickeln Sie gewöhnlich kein Produkt. Der Zweck einer Vorabstudie ist herauszufinden,
ob es möglich ist, ein Produkt zu erstellen. Ein solches Projekt hat nicht dieselben Meilensteine wie ein reguläres
Projekt.
In den meisten Fällen wird der derzeit angewendete Softwareentwicklungsprozess in der Organisation nicht ersetzt, weil
Sie den neuen Entwicklungsprozess nach und nach implementieren und sich zuerst auf die kritischeren und wichtigeren
Bereiche konzentrieren. Ein Teil des aktuellen Softwareentwicklungsprozesses kann sogar über längere Zeit hinweg oder
für immer bestehen bleiben.
Welche Probleme für das Projekt ermittelt und priorisiert werden, hat Einfluss auf die Bereiche des Prozesses, auf die
Sie sich zu Beginn der Prozessimplementierung konzentrieren. Wichtig zu bemerken ist, dass die Ermittlung von Problemen
zwecklos ist, wenn es noch keine etablierte Arbeitsweise in der Organisation gibt. Informationen hierzu finden Sie auf
der Seite Konzept: Prozess in einem Projekt implementieren. Stattdessen müssen Sie
möglicherweise die eigentlichen Ursachen für die Probleme ermitteln. Zur Behebung der Probleme müssen Sie die
eigentlichen Ursachen angehen, indem Sie den Prozess verbessern und Tools zur Automatisierung des Prozesses einführen
und Mitarbeiter schulen.
Beispiele für allgemeine Probleme
Im Folgenden finden Sie einige Beispiele für allgemeine Probleme:
-
Unfähigkeit, Inhalt und Umfang (Scope) zu verwalten - Die Organisation versucht regelmäßig mehr zu tun, als sie
letztendlich schafft.
-
Unfähigkeit, Anforderungen zu erfassen - Die Organisation hat Schwierigkeiten mit der Spezifikation von
Anforderungen.
-
Unfähigkeit, Anforderungsänderungen zu verwalten.
-
Unfähigkeit, Anforderungen zu verwalten - Anforderungen werden im Endprodukt nicht berücksichtigt.
-
Unfähigkeit, Schätzungen abzugeben - Die Organisation ist regelmäßig zu optimistisch, was ihre Fähigkeit einer
termingerechten Lieferung anbelangt.
-
Designmängel - Die Organisation ist zwar in der Lage, Anforderungen zu erfüllen, aber weist Mängel beim Design von
Systemen auf. Welche Arten von Designproblemen hat die Organisation? Sind die Systeme zu schwierig zu verwalten und
zu erweitern? Weisen die Systeme Probleme in der Leistung, Benutzerfreundlichkeit, Kapazität usw. auf?
-
Unfähigkeit, qualitativ hochwertige Produkte zu produzieren - Das Produkt hat zu viele Mängel, was möglicherweise
auf zu wenig Tests zurückzuführen ist, aber in der Regel daran liegt, dass die Anforderungen nicht korrekt erfasst
und verwaltet werden und das Design mangelhaft ist.
-
Inakzeptable Softwareleistung.
-
Geringe Benutzerfreundlichkeit.
-
Kollidierende Entwickler - Kontrolle des Eigentumsrechts und Konfigurationsmanagement sind mangelhaft und deshalb
nehmen die Entwickler Änderungen vor, die miteinander in Konflikt stehen. Es geht Arbeit verloren.
-
Späte Erkennung von Problemen.
-
Mühe beim Übergang von Anwendungsfällen zum Design.
Beispiele für Ursachen
Ein Problem ist häufig ein Symptom für eine Fehlentwicklung. Sie müssen die eigentlichen Ursachen der Probleme
ermitteln. Im Folgenden finden Sie einige Beispiele für allgemeine Ursachen:
-
Ungenügendes Anforderungsmanagement
-
Mehrdeutige oder unpräzise Kommunikation
-
Labile Architekturen
-
Erdrückende Komplexität
-
Unerkannte Inkonsistenzen zwischen Anforderungen, Designs und Implementierungen
-
Ungenügende Tests
-
Subjektive Bewertung des Projektstatus
-
Verzögerte Risikominderung wegen Entwicklung nach Wasserfallmodell
-
Unkontrollierte Änderungsweitergabe
-
Ungenügende Automatisierung
-
Unsystematische Methode bei der Erstellung von Benutzerschnittstellen
-
Keine Möglichkeit, von Anwendungsfällen zu einem Design überzugehen
Die Implementierung des Prozesses in einer Organisation ist von organisatorischen Faktoren abhängig, z. B. der
Fähigkeit der Organisation, mit Änderungen umzugehen, der Organisationsstruktur, der Organisations- und
Managementkultur im Projekt, verfügbare Fähigkeiten und Know-how, vorherige Erfahrungen und aktuelle Attribute.
Die organisatorischen Faktoren wirken sich auch auf die Konfiguration des Prozesses aus. Wenn die Personen in der
Organisation beispielsweise bereits mit einer Beschreibung eines Softwareentwicklungsprozesses gearbeitet haben, ist
der Einstieg in RUP einfacher. Falls die Personen noch keine solche Beschreibung verwendet haben, müssen Sie
möglicherweise entscheiden, den Umfang der Prozessbeschreibung zu beschränken. Außerdem sollten Sie besonders darauf
achten, dass die Prozessbeschreibung einfach zu verstehen und zu verwenden ist. Stellen Sie sicher, dass die
Prozessbeschreibung die Informationen enthält (bzw. auf diese verweist), die den größten Wert darstellen.
Wenn es Bereiche gibt, die für viele Mitarbeiter neu sind, kann der Übergang durch klar und unmissverständlich
definierte Richtlinien erleichtert werden. Wenn beispielsweise die Programmiersprache für viele Mitarbeiter neu ist,
sollten Sie sehr gute Richtlinien für die Programmierung und Richtlinien für das Design schreiben, um den Mitarbeitern
das Erlernen dieser Sprache zu erleichtern.
Eine negative Einstellung des Organisationspersonals gegenüber der Umstellung auf eine neue Technologie, einen neuen
Prozess oder neue Tools ist wahrscheinlich die größte Bedrohung der erfolgreichen Implementierung von Prozess und
Tools. Auch eine allzu überschwängliche Begeisterung für einen Prozess kann ein Problem darstellen, weil es die
Mitarbeiter dazu verleiten kann, sich zu sehr auf den Prozess zu konzentrieren.
Um die Einstellung der Mitarbeiter gegenüber der neuen Technologie, dem neuen Prozess und den neuen Tools zu bewerten,
sollten Sie Fragen wie die folgenden stellen:
-
Welche Vorteile sehen Sie in der neuen Technologie? Wird die neue Technologie die heutigen Probleme lösen? Welche
Probleme sehen Sie bei der neuen Technologie?
-
Welche Vorteile sehen Sie in dem neuen Prozess? Wird der neue Prozess die heutigen Probleme lösen? Welche Probleme
sehen Sie bei dem neuen Prozess?
-
Welche Vorteile sehen Sie in den neuen Tools? Werden die neuen Tools die heutigen Probleme lösen? Welche Probleme
sehen Sie bei den neuen Tools?
Versuchen Sie, Antworten auf die folgenden Fragen zu erhalten, um die Motivation der Mitarbeiter einzuschätzen:
-
Erkennt jeder in der Organisation, warum die Änderung erforderlich ist?
-
Sind sich alle bewusst, was ihr Konkurrenzkampf anrichtet und wie er sich auf das Geschäft auswirkt?
-
Sind jedem die Technologieänderungen in der Branche und ihre Auswirkungen auf das Geschäft bewusst?
Anzeigen für eine negative Einstellung können Äußerungen wie die folgenden sein:
-
"Der Prozess hilft nicht, er behindert nur."
-
"Der Prozess bedeutet, dass viele Dokumente produziert werden."
-
"Der Prozess ist erdrückend."
Im Folgenden finden Sie einige Tipps, solchen negativen Einstellungen entgegenzuwirken:
-
Motivieren Sie die Mitarbeiter, indem Sie auf die aktuellen Probleme hinweisen.
-
Machen Sie Ihren Mitarbeitern klar, dass ein Prozess ihnen nicht vorschreibt, was zu tun ist, sondern dass sie den
Prozess primär als "Hilfesystem" betrachten sollen, indem sie Anleitung, Definitionen usw. nachschlagen können.
-
Erklären Sie Ihren Mitarbeitern, dass Sie nur kleine Abschnitte des Prozesses verwenden. Niemand kann den gesamten
Prozess beherrschen, und das ist auch nicht der Zweck. Vergleichen Sie den Prozess mit einem Bücherregal, aus dem
Sie Bücher herausziehen, wenn Sie Informationen benötigen.
-
Führen Sie ein erfolgreiches Pilotprojekt durch, in dem Sie zeigen, wie der neue Prozess und die Tools
funktionieren. Beziehen Sie ein oder zwei Skeptiker in das Pilotprojekt ein.
Zeichen für Übereifer sind:
-
Die Mitarbeiter verlassen sich komplett auf den Prozess und denken, dass der Prozess all ihre Probleme löst.
-
Der Prozess wird als Wunderwaffe oder magische Formel angesehen, die bei Einhaltung den Erfolg garantiert.
-
Das Projektteam möchte viel Zeit und Aufwand in die Anpassung des Prozesses stecken, ohne zuerst die
prozessbezogenen Probleme auszuwerten, die der Lösung bedürfen.
Im Folgenden finden Sie einige Tipps, solchem Übereifer entgegenzuwirken:
-
Definieren Sie Erwartungen. Der Prozess hilft, aber er löst nicht die Probleme. Probleme werden von Menschen
gelöst.
-
Reden Sie dem Team aus, zu viel Zeit in die Anpassung des Prozesses zu stecken.
-
Bringen Sie die Mitarbeiter dazu, sich auf die Entwicklung der Softwareprodukte zu konzentrieren.
Unterschiedliche Typen von Systemen und ihre Projekte können
anhand ihrer technischen Komplexität und ihrer verwaltungsbezogenen Komplexität kategorisiert werden. Die
folgende Abbildung veranschaulicht ein Konzept für die Klassifizierung unterschiedlicher Systeme. Eine typische kleine
Spreadsheet-Anwendung weist häufig eine geringe technische Komplexität auf und ist einfach zu verwalten. Das andere
Extrem ist ein typisches Waffensystem, das häufig technisch komplex und schwierig zu verwalten ist.
Mit zunehmender Systemgröße, zunehmender Projektdauer oder zunehmendem Geschäftskontext steigt gewöhnlich auch die
Verwaltungskomplexität. Die technische Komplexität steigt mit dem Neuheitsgrad - in der Problemdomäne oder im
Lösungsbereich. Es besteht außerdem eine Wechselwirkung zwischen Verwaltungskomplexität und technischer Komplexität.
Viele große Projekt sind auch technisch sehr komplex. Dies führt zu:
-
einer höheren Verwaltungskomplexität mit mehr Zeremonie, einschließlich mehr formalen Prüfungen und Meilensteinen
und mehr Arbeitsergebnissen,
-
einer höheren technischen Komplexität mit der Einführung spezieller Techniken, Rollen und Tools und daher auch mehr
Aufgaben.
Systeme werden anhand ihrer technischen Komplexität und ihrer Verwaltungskomplexität klassifiziert.
|