Archiv der Kategorie: Softwaredesign

IT-Großprojekte, zum Scheitern verurteilt? – einfach umsetzen.

IT-Großprojekte, zum Scheitern verurteilt? – einfach umsetzen.
IT-Großprojekte, zum Scheitern verurteilt?
1. Februar 2007

In seinem CIO-Artikel beschreibt Dr. Claus Herbolzheimer von Roland Berger die Risiken von IT-Großprojekten. Gleichzeitig werden Leitlinien vorgestellt, um diese Risiken zu minimieren. Am Ende des Tages sind sicherlich klare Spielregeln zwischen den Beteiligten, eine gute Kommunikation mit den TOP-Entscheidungsträgern und ein gutes Änderungsmanagement entscheidende Erfolgsfaktoren.
Der Artikel ist zu finden unter:
http://www.cio.de/markt/analysen/832292/index1.html

Objektmodelle kommunizieren

Ziel der Anforderungsanalyse ist es nicht nur, zu konsistenten Modellen zu kommen, welche die Anforderungen an das neue Softwaresystem adäquat beschreiben, sondern diese Modelle auch mit den Partnern kommunizieren zu können. Ein Modell ist nur dann praktisch effektiv, wenn alle Partner des Analyseprozesses es verstehen und bearbeiten können.
Es hat sich deshalb als effektiv erwiesen, nicht übermäßigen Gebrauch von Begriffen und Symbolen der Objektorientierten Designverfahren zu machen, insbesondere dann, wenn die Partner aus den Fachabteilungen mit dieser Terminologie nicht hinreichend vertraut sind. Statt immer wieder auf die Existenz von Klassen und Instanzen oder Objekten zu verweisen, sollte konkret über Dokumente und Akteure sowie über andere Elemente des Systems gesprochen werden.
Objekteigenschaften oder Attribute sind nichts anderes als diejenigen Merkmale, welche zur genauen Bestimmung eines Elementes nötig sind bzw. diejenigen, welche im Zusammenhang mit unserem Geschäftsprozess relevant sind, weil sie durch ihn geändert werden oder weil Entscheidungen auf ihnen basieren.

Wenn der (objektorientiert denkende) Designer oder Analyst nach Objektmethoden oder Operationen fragt, meint er nichts anderes als die Frage, was man mit den Systemelementen machen kann, wie man sie verändern kann. So sollte die Frage auch gestellt werden.

Letztlich kommt es immer darauf an, dass die drei Partner im Analyseprozess (Fachabteilung, Analyst, Entwickler) eine gemeinsame Sprache finden und sicher sein können, dass sie das gleiche meinen, wenn sie das gleiche sagen. Objektorientierte Denk- und Herangehensweisen sind für den Analysten hilfreich, in der Kommunikation mit der Fachabteilung sollten deshalb objektorientierte Begrifflichkeiten aber nicht unbedingt im Vordergrund stehen.

Der Prozess der Anforderungsanalyse

Im Prozess der Anforderungsanalyse müssen wir zwei Handlungskomplexe unterscheiden:
1. Die eigentliche Anforderungsentwicklung, in deren Verlauf aus Problemen und Zielen plausible und valide Anforderungsdokumentationen spezifiziert werden
2. Das Anforderungsmanagement, in welchem sozusagen auf einer übergeordneten Handlungsebene die Pflege, Versionierung und Weiterentwicklung von Anforderungsspezifikationen während des Gesamtprojektes betrieben wird.
Anforderungsmanagement
Zum Anforderungsmanagement gehört zunächst die Definition der verschiedenen Verfahren, welche im Gesamtprozess der Anforderungsanalyse zum Einsatz kommen. Hierzu gehören insbesondere das Anforderungsentwicklungs- und das Änderungskontrollverfahren.
Ein weiterer Schwerpunkt ist das definieren der Anforderungsbaseline sowie das Änderungsmanagement (Versionierung, Änderungskontrollgremium, Statusüberwachung).
Anforderungsentwicklung
Im Mittelpunkt der Anforderungsentwicklung steht die Kommunikation zwischen dem, der die Anforderung stellt und dem, der sie zu analysieren, zu objektivieren, zu strukturieren und zu dokumentieren hat – dem Anforderungsanalysten. Die Bedeutung der Kommunikation ist dabei nicht zu unterschätzen. Aus der großen Bedeutung der Kommunikation für das Erstellen optimaler Anforderungsspezifikationen ergeben sich zwei entscheidende Bedingungen:
1. Anforderungssteller und Anforderungsanalyst müssen eine gemeinsame Sprache sprechen.
2. Anforderungssteller und Anforderungsanalyst müssen vor allem viel Zeit in die Anforderungsanalyse investieren.
Die Anforderungsentwicklung kann – entsprechend der oben genannten Tätigkeiten des Analysten – im wesentlichen in vier Phasen unterteilt werden: Erhebung, Analyse, Spezifikation und Validierung.
Ein gut strukturiertes und definiertes Anforderungsmanagement ist Voraussetzung für erfolgreiche Anforderungsentwicklung. Zu Beginn des Projektes wird das Anforderungsentwicklungsverfahren definiert, dies ist genau genommen ein Bestandteil des Anforderungsmanagements. Wenn Standards im Unternehmen definiert sind, sind diese auf ihre Anwendbarkeit und Aktualität zu prüfen.
Vor der eigentlichen Erhebung steht die Benennung Anspruchsgruppen und die Auswahl von geeigneten Repräsentanten für die Durchführung der Anforderungsanalyse, insbesondere die Anspruchsgruppe der Benutzer ist dann weiter zu differenzieren, Benutzerklassen werden gebildet und Produktchampions identifiziert.
Neben der Durchführung spezieller Veranstaltungen (Interviews, Workshops) gehören auch das Studium von Dokumenten und die Beobachtung der Benutzer bei der Arbeit zur Anforderungserhebung.
Unter Analyse verstehen wir hier das Sichten, Strukturieren, Klassifizieren und Objektivieren der erhobenen Fakten. Mit einem aus der Meteorologie übernommenen Begriff können wir diese Phase auch als Synopsis (Zusammenschau) bezeichnen. Das Ergebnis sind insbesondere die identifizierten Anwendungsfälle.
Bei der Spezifikation kommen die verschiedenen Modellierungsansätze zum Einsatz. Neben weiter ausgeprägten Anwendungsfalldokumentationen entstehen hier Prozess- und Objektmodelle sowie logische Datenmodelle und (Papier-)Prototypen.

Bei der Validierung steht wiederum die Kommunikation mit den (Vertretern der) Anspruchsgruppen im Vordergrund. Anforderungstests werden durchgeführt, die Spezifikationen werden nach formalen und inhaltlichen Kriterien bewertet.

Anforderungsanalyse: Nicht lösungs- sondern zielorientiert!

Zunächst muss Klarheit darüber bestehen, was gemeint ist wenn wir von Anforderungen sprechen. Die Abgrenzung zu Begriffen wie „Problem“, „Lösungsvorschlag“, „Funktionalität“ ist dabei genauso wichtig wie die Frage, welche Anforderungsarten und –ebenen es gibt.
Anforderungen sind die Erwartungen von Menschen an ein System, mit dessen Hilfe sie ihre Arbeit erledigen wollen.

Wie kommt es zu Anforderungen?

Vor der Anforderung steht immer ein Problem. Menschen haben ein Ziel, können dieses mit den ihnen zur Verfügung stehenden Mitteln aber nicht erreichen. Sie suchen nach einem Werkzeug, mit welchem sie das Ziel erreichen können. An dieses Werkzeug stellen sie die Anforderung, dass mit seiner Hilfe das Ziel erreichbar sein möge.
Wir sehen an dieser Überlegung bereits einen ganz wesentlichen Aspekt der Anforderungsanalyse, welcher uns immer begleiten wird: In ihrem Zentrum steht nicht die Lösung, nicht die Frage, wie das Ziel letztlich tatsächlich erreicht wird, sondern das Verstehen des Problems und damit des Zieles!

Anforderungsanalyse ist primär nicht die Suche nach Lösungen sondern die Dokumentation von Problemen und Zielen auf eine Weise, dass daraus Lösungen abgeleitet werden können. Das ist deshalb besonders wichtig, weil in der Anforderungsanalyse häufig viel zu früh über mögliche Lösungen gesprochen wird, ohne dass das Ziel bereits hinreichend klar spezifiziert ist. Wenn die Beteiligten aber keine klare und gemeinsame Vorstellung von den Zielen haben, können sie auch keine wirkliche Übereinstimmung darin haben, ob eine angestrebte Lösung tatsächlich zielführend ist, ja, sie werden von der „Lösung“ die sie gemeinsam beschreiben, oft ganz unterschiedliche Vorstellungen haben, da jeder seine Zielvorstellungen in die „Lösung“ hineininterpretiert.

Ansätze zur Beschreibung von Geschäftsvorfällen

Welche Ansätze zur Beschreibung von Geschäftsprozessen gibt es?
1. Die erste Frage, die gestellt werden kann, um Geschäftsvorfälle zu beschreiben und zu verstehen, heißt: Was wird getan? Welche Prozesse laufen ab und in welcher Reihenfolge, wann werden Entscheidungen getroffen, die den Prozessablauf ändern, wann ist ein Prozess abgeschlossen? In welche Teilprozesse zerfällt ein Prozessschritt?

Dieses Verfahren wird Geschäftsprozessanalyse genannt, im Ergebnis entstehen Geschäftsprozessmodelle.
2. Der nächste Ansatz lässt sich durch die Frage fassen: Womit beschäftigen sich die Akteure in den Geschäftsvorfällen? Welche Dokumente werden erzeugt, bearbeitet, verändert, vernichtet und welche Ressourcen werden dafür benötigt? Was wird mit diesen Objekten getan? Wie sind sie aufgebaut, bestehen sie aus Teilobjekten? Ein solches Verfahren ist die Geschäftsobjektmodellierung.
3. Ein weiterer Ansatz besteht darin, nach den Daten, den Informationen zu fragen, die im Geschäftsvorfall benötigt, erzeugt, verändert und gelöscht werden. Welche Entitäten gibt es, welche Attribute haben diese? Wie hängen die Entitäten miteinander zusammen. Welche Restriktionen bestehen für die Attribute, welche Datentypen haben sie? Dieses Verfahren ist die logische Datenmodellierung.
4. Schließlich gibt es die Möglichkeit, zu versuchen, die Interaktion des Benutzers mit der Software unmittelbar zu beschreiben. Welche Menüpunkte sollen existieren, wie sollen Dialoge aufgebaut sein, welche Elemente sollen diese haben, welche Aktionen sollen ausgeführt werden können und mit welchem Ergebnis? Ziel dieses Ansatzes ist die Erstellung eines „Papierprototypen“.

Der Teufelskreis der Anforderungsanalyse

Das Ziel der Anforderungsanalyse für Softwaresysteme ist letztendlich die hinreichende Beschreibung von Geschäftsvorfällen, die so noch nicht existieren. Nur, wenn die Struktur eines Geschäftsvorfalles, der von der erst zu entwickelnden Software unterstützt werden soll, bekannt ist, können die Anforderungen an diese Software analysiert werden. Da aber der Geschäftsvorfall in seiner Struktur von eben dieser Software abhängt, bewegen wir uns in einem „Teufelskreis“. Diesen Teufelskreis gilt es zu durchbrechen.
Der Prozess der Anforderungsanalyse für Softwaresysteme ist mehrstufig und umfasst verschiedene Aspekte. Abhängig von den konkreten Rahmenbedingungen kann er unterschiedlich komplex sein. Er umfasst:
• die Spezifikation der fachlichen Anforderungen
• die Einordnung in die gesamte IT-Infrastruktur des Unternehmens
• die Identifikation von Anwendungsfällen und die Ableitung von Testfällen.
Gleichzeitig wird ein Verfahren benötigt, mit welchem sichergestellt wird, das die gefundene Beschreibung vollständig und umfassend ist. Dies kann am ehesten sichergestellt werden, wenn die Geschäftsvorfälle mehrdimensional analysiert werden, wenn mehrere Ansätze parallel verfolgt werden, die gewissermaßen orthogonal zueinander sind. Ein wichtiges Merkmal für die Vollständigkeit der Beschreibung ist dann die innere Konsistenz der Analyseteile: Jedes Element der Beschreibung innerhalb eines Ansatzes muss sich auch in den anderen Beschreibungsansätzen wieder finden lassen.

Studie zum Projektcontrolling

Zwei Ziele hat ein Entwicklungsprojekt: Ein Ergebnis, welches den Auftraggeber
zufrieden stellt und die Einhaltung eines vorgegebenen Kosten- und Zeitplanes.
Aber die Erfahrung fast jedes Projektmanagers zeigt, dass beides zusammen
selten zu haben ist. Und das gilt nicht nur für Softwareprojekte, die gleichen
schmerzhaften Erfahrungen machen Werbefachleute genauso wie
Produktentwickler in der Automobilindustrie.
Wenn Sie diese Seiten gelesen haben, werden Sie nicht nur wissen, warum das so
sein muss. Sie werden nicht nur Verständnis für gestresste Projektverantwortliche
in ehrgeizigen Entwicklungsprojekten bekommen, die sich immer wieder für
Verzögerungen rechtfertigen müssen, die immer wieder nach neuen Mitteln rufen
oder die am Schluss ein Produkt präsentieren, das keiner so recht haben will.
Sie werden beim Lesen eine Vorstellung davon bekommen, wie die
althergebrachten Methoden der Projektplanung, die vor einem Jahrhundert
entwickelt wurden und die heute noch immer den Kern fast aller
Projektmanagementsoftware bestimmen, modifiziert werden müssen, damit
Entwicklungsteams erfolgreich Produkte hervorbringen und sich dabei an einmal
abgegebene Kosten- und Terminzusagen halten können.
weiter lesen…