20070506b sd&m Fachlichkeit Großprojekte Softwareprojekte

In großen Projekten besteht die Herausforderung, dass sich häufig verschiedene Teile des Systems gleichzeitig in ganz unterschiedlichen Phasen befinden und viele der Beteiligten nur einen Ausschnitt des Gesamtsystems kennen oder die Fachlichkeit des Systems nur bis zu einer gewissen Detailtiefe durchdrungen haben. Hier muss sichergestellt werden, dass jede fachliche Entscheidung so abgesichert wird, dass sie in das Gesamtbild des Systems passt. Zur Steuerung der Fachlichkeit eines großen Systems bedarf es eigener Prozesse und Organisationsformen, die für das Gelingen eines Projektes entscheidend sind.

Inhaltsverzeichnis

1 Einleitung

2 Wann und wie entsteht Fachlichkeit?

3 Wer im Projekt hat etwas mit Fachlichkeit zu tun?

4 In welchem Spannungsfeld steht Fachlichkeit?

5 Was ist bei Großprojekten bzgl. Fachlichkeit anders?

6 Was muss bei Großprojekten getan werden?

1 Einleitung

Ziel eines Softwareprojekts ist es, eine bestimmte Fachlichkeit in ein Softwaresystem umzusetzen. Dabei besteht ein guter Teil der Arbeit darin, festzulegen, auf welche Art und Weise welche fachlichen Anforderungen umgesetzt werden. In Großprojekten unterliegt die Fachlichkeit sehr vielfältigen Einflüssen und Interessen. Das bringt die Gefahr mit sich, dass Geschlossenheit und Konsistenz zerrieben werden und das entstehende System sein eigentliches Ziel nicht erreicht. Durch geeignete Maßnahmen muss daher sichergestellt werden, dass die Fachlichkeit ein eigener Betrachtungsgegenstand wird, dessen innere Konsistenz und Vollständigkeit durch alle Phasen erhalten bleibt.

2 Wann und wie entsteht Fachlichkeit?

Ein Softwaresystem hat den Zweck, bestimmte Prozesse innerhalb einer Organisation durch Software zu unterstützen. Diese Welt der Anwender mit ihren Daten, Funktionen und prozessualen Zusammenhängen wird hier als Fachlichkeit bezeichnet. Flankiert wird sie von der Technik, die die Basis darstellt, um die geforderte Fachlichkeit im Rahmen eines Softwaresystems umzusetzen.

Zu Beginn eines Projekts kann der »Reifegrad« der vorliegenden Fachlichkeit sehr unterschiedlich sein. Der einfachere Fall liegt vor, wenn das neue System an den gelebten Prozessen nichts ändert, sondern diese nur besser unterstützt. Im komplexeren Fall werden mit dem neuen System auch neue Prozesse eingeführt, im Extremfall sind diese neuen Prozesse überhaupt erst durch das neue System möglich.

Die übliche Vorgehensweise ist, zunächst mit dem Fachbereich festzulegen, was das System zu leisten hat, dieses dann umzusetzen und anschließend nach erfolgreichen Tests einzuführen. Bekanntermaßen stellt dieser eine Satz den Ablauf aber stark verkürzt dar. Während des gesamten Projektverlaufs entstehen fachliche Anforderungen neu, verändern sich oder werden infrage gestellt. Damit muss umgegangen werden können. Die Quellen von Anforderungen können je nach Projektphase sehr unterschiedlich sein.

Während der Spezifikationsphase gießen Kunde und Softwareersteller (so sollen die beiden beteiligten Parteien im Folgenden genannt werden, unabhängig davon, wie ihr juristisches Verhältnis zueinander aussieht) das fachliche Wollen des Kunden in die Funktionalität eines Softwaresystems.

In der Phase von IT-Konzept und Programmierung liegen die Anforderungen vor und müssen eigentlich »nur noch« in ein lauffähiges System umgesetzt werden. Jedoch kann keine Spezifikation dieser Welt so umfassend sein, dass sie nicht einzelne Detailfragen und Spezialfälle offenließe. Auch und gerade in der Umsetzungsphase müssen die Anforderungen also zusammen mit dem Kunden weiter präzisiert und gegebenenfalls modifiziert werden.

Hinzu kommt, dass sich die fachliche Welt des Kunden unabhängig vom Projektverlauf weiterentwickelt. Änderungen im Prozess, oder in der Organisation des Kunden, in seinem Markt oder von gesetzlichen Vorschriften ziehen auch Änderungen der Fachlichkeit nach sich. Gegebenenfalls müssen dann bereits während der Realisierungsphase Änderungen am (noch gar nicht fertiggestellten) System vorgenommen werden.

In Systemtest und Abnahme wird das System gegen die Spezifikation und ggf. zwischenzeitlich vorgenommene (und dokumentierte!) Änderungen getestet. In der Praxis testen viele Tester jedoch ausschließlich oder zumindest immer auch gegen ihre Erwartungen, ganz gleich, wie diese entstanden sind und ob sie konform zur Spezifikation sind. Erfüllt das System diese Erwartungen nicht, kann dies Änderungswünsche und neue Anforderungen nach sich ziehen, auf die häufig sehr kurzfristig reagiert werden muss.

Das Testen gegen eigene Erwartungen ist prinzipiell gar nicht negativ, sondern im Grunde eine zusätzliche QS-Maßnahme gegenüber der Spezifikation. Der Tester bringt seinen eigenen Erfahrungshorizont mit ein und seine Vorstellungen, wie er mit dem System arbeiten will und welche Informationen und Funktionalitäten es bereitstellen muss. Insbesondere wenn der Tester an der Erstellung der Spezifikation nicht beteiligt war, können so neue Aspekte zutage treten. Ein anderes Thema ist, wie mit solchen gegenüber dem Fachkonzept neuen Anforderungen kommerziell und planerisch umgegangen wird.

Selbst im laufenden Betrieb, nach Einführung des Systems, entstehen neue Anforderungen, die aus der täglichen Arbeit mit dem System resultieren. Hier könnte man sagen »hätte man sich in der Spezifikationsphase besser überlegen müssen«. Oft erschließt aber erst der tägliche Umgang mit einem System neue Nutzungsmöglichkeiten, die sich in einer Konzeptphase nicht vorhersehen lassen.

Bei der Weiterentwicklung eines im Betrieb laufenden Systems müssen neue Anforderungen fachlich (technisch natürlich auch, aber das ist hier nicht das Thema) in das bereits laufende System integriert werden. Zusätzlich zur Integration neuer Funktionalität stellt sich oft auch das Problem der Integration neuer Datenstrukturen. Die Migration der alten Datenwelt in eine neue ist dann bei der Gestaltung der neuen Funktionalität bereits zu berücksichtigen.

3 Wer im Projekt hat etwas mit Fachlichkeit zu tun?

In einem Softwareprojekt treffen Menschen aus verschiedenen Umfeldern und mit verschiedenen Hintergründen aufeinander. Aufgrund ihrer jeweiligen Rollen im Projekt haben sie unterschiedliche Interessen und daher einen unterschiedlichen Blick auf die Fachlichkeit. Beispielhaft seien hier einige benannt.

Der Fachbereichsvertreter für die Konzeptphase kennt die zu unterstützende Fachlichkeit genau und ist meist (aber nicht immer!) ein künftiger Nutzer des Systems. Er spricht häufig einen spezifischen Jargon, den Außenstehende teilweise nur schwer verstehen. Er hat seine eigene lokale Sicht auf den zu unterstützenden Prozess, die mit der Sicht anderer Fachbereichsvertreter nicht unbedingt übereinstimmen muss. Hier besteht die Gefahr, dass Prozessabläufe zwischen verschiedenen Bereichen nicht rechtzeitig geklärt werden und sich die Unstimmigkeiten später im System widerspiegeln. Der Fachbereichsvertreter kennt jedes Detail und jeden Ausnahmefall seiner Fachlichkeit, hat viele Ideen, wie damit im System umgegangen werden muss und will alles im System abgebildet sehen.

Der Spezifikateur auf Seiten des Softwareerstellers bringt eine strukturierte Vorgehens- und Dokumentationsweise mit, kennt aber häufig die Fachlichkeit nicht im Detail. Er hat eher das Interesse, das System nach klaren Regeln zu strukturieren (also z. B. möglichst wenig Ausnahmefälle).

Der Projektleiter beim Kunden auf Fachbereichsseite hat das Interesse, für sein Budget möglichst schnell möglichst viel an Funktionalität im System zu bekommen. Eher als der Fachbereichsvertreter akzeptiert er auch Lösungen, die nicht alle Sonderfälle abdecken. Auch er kennt die Fachlichkeit nicht immer bis ins letzte Detail.

Die IT beim Kunden muss das fertige System betreiben und übernimmt auch häufig die Wartung. Ihre Interessen spiegeln sich meist in technischen Anforderungen wider, können aber auch in die Fachlichkeit hineinspielen.

Der Projektleiter beim Ersteller hat das Ziel, nur so viel Funktionalität umzusetzen, wie das Budget gut hergibt, und dabei im Zeitplan zu bleiben. Auch er kennt die Fachlichkeit oft nur grob.

Der Entwickler beim Ersteller war im Idealfall vorher ein Spezifikateur, dann kennt er die umzusetzende Fachlichkeit sehr gut. Wenn nicht, dann kennt er in der Regel nur einen kleinen Ausschnitt daraus.

4 In welchem Spannungsfeld steht Fachlichkeit?

Bei der Diskussion und Entscheidung, welcher fachlicher Fragestellung auch immer, spielen meist auch außerfachliche Aspekte mit herein.

Der Softwareersteller will – zugunsten von Aspekten wie Umsetzbarkeit, Wartbarkeit, Performance – möglichst Komplexität vermeiden. Vereinzelt gibt es aber auch das Phänomen, dass einzelne Entwickler plötzlich die Lust an der Komplexität packt, was eine Gefahr spezieller Art darstellt.

Der Kunde will möglichst schnell möglichst viel bekommen. Das ist verständlich, aber nicht immer sachdienlich. Ein Projekt verträgt in einer bestimmten Zeit nur eine bestimmte Komplexität. Überzieht man hier, so werden Zusammenhänge nicht richtig verstanden und durchdacht. Die Folge sind konzeptionelle Fehler im System.

Die Kunden des Kunden (also letztlich die verschiedenen Nutzer) besitzen unterschiedliche Schwerpunkte, die sich durchaus widersprechen können. Das geht bis zum Streit zwischen verschiedenen Fraktionen, wie ein Geschäftsprozess denn zu leben sei, und in Folge davon, wie er im System abgebildet werden muss.

Fachliche sowie planerische und kommerzielle Aspekte beißen sich häufig. Bei der Art und Weise, wie man ein fachliches Problem löst, spielt immer auch hinein, wie dringend das Problem ist und welche Zeit für die Umsetzung einer Lösungsvariante benötigt wird sowie welches Budget zur Verfügung steht.

5 Was ist bei Großprojekten bzgl. Fachlichkeit anders?

Bei einem Großprojekt steigt der Umfang der Fachlichkeit, Menge und Komplexität der Funktionalität nehmen zu. Das System zerfällt meist in mehrere Teilsysteme, die über Daten und übergreifende Funktionen miteinander verkoppelt werden. Die einzelnen Bestandteile bleiben dabei fachlich meist relativ einfach. Die Komplexität entsteht durch die Vielzahl der möglichen Zusammenhänge und Bezüge der vielen einzelnen Bestandteile.

Aufgrund des schieren Umfangs des Systems kann es dann auch niemanden mehr geben, der die gesamte Breite und Tiefe der Funktionalität in allen Details abrufbar im Kopf hat. Bei einer neuen Anforderung ist daher auch nicht mehr spontan entscheidbar, ob sie in das bestehende Gefüge passt oder nicht. Dies ist in jedem Einzelfall anhand vorliegender Dokumentation und durch Diskussion mit Beteiligten systematisch zu prüfen. Es gilt die große Gefahr zu vermeiden, dass das fachliche Gesamtgefüge durch viele lokale Änderungen und Ergänzungen unterlaufen wird oder gar irgendwann kollabiert.

In einem Großprojekt ist natürlich auch die Zahl der beteiligten Personen groß. Dies hat zur Folge, dass der Bezug jeder Einzelperson zum Projekt ein anderer ist. Viele der Beteiligten vertreten und kennen nur einen Ausschnitt des Gesamtsystems. Ein Fachbereichsvertreter bearbeitet etwa nur einen Teil des zu unterstützenden Gesamtprozesses oder ein Entwickler setzt nur einen Teil der Funktionalität um und kennt sich daher nur in diesem Bereich aus. In Diskussionen besteht dann die Gefahr, dass häufig nur noch Partikularinteressen vertreten werden, der Blick für das Ganze kann schon mangels detaillierter Kenntnis nur schwer entstehen.

In einem Großprojekt besteht in der Regel eine Gleichzeitigkeit der Projektphasen. Das Gesamtsystem ist in mehrere Teile zerlegt, die zeitlich versetzt konzipiert und umgesetzt werden. Daher gibt es im Extremfall verschiedene Subsysteme, die sich parallel jeweils in Produktion, in Test, in Entwicklung und in Konzeption befinden. Eine Änderung an der Fachlichkeit schlägt dann unter Umständen auf mehrere dieser Teile durch und muss entsprechend sorgfältig konzipiert, kommuniziert und geplant werden.

6 Was muss bei Großprojekten getan werden?

In einem Großprojekt muss mit Fachlichkeit in all ihren Aspekten angemessen umgegangen werden. Wenn am Ende ein aus fachlicher Sicht brauchbares und in sich stimmiges System entstehen soll, sind einige Bausteine im Projekt unerlässlich.

In großen Projekten können wichtige fachliche Entscheidung nicht mehr von der Projektleitung nebenbei mit erledigt werden. Daher ist es unerlässlich, die Verantwortung für den fachlichen Gesamtzusammenhang des Systems in eine eigene Rolle zu legen, diejenige des fachlichen Chefdesigners (FCD). Einen solchen muss es dabei sowohl beim Kunden als auch beim Softwareersteller geben.

Die FCD sind ausschließlich für die fachliche Stimmigkeit des Systems verantwortlich. Fragen zu Planung, Budget und Terminen liegen bei den Projektleitern. Damit ist gewährleistet, dass der potenzielle Konflikt zwischen »alles vollständig und richtig« und »alles schnell und billig« zwischen verschiedenen Rollen ausgetragen wird und nicht innerhalb eines Kopfes stattfindet. Die letzten Entscheidungen trifft aber weiterhin die Projektleitung, da diese die Ergebnisverantwortung trägt.

Aufgrund der schieren Menge können nicht alle Aufgaben, die etwas mit Fachlichkeit zu tun haben, durch die FCD persönlich erledigt werden. Es müssen aber alle Ergebnisse aus diesen Aufgaben von den FCD geprüft und gutgeheißen werden. In regelmäßigen FCD-Meetings werden fachliche Themen besprochen und entschieden. Dazu gehören auch Reviews von fachlichen Ergebnissen, die in anderen Arbeitsgruppen erstellt wurden. Eine Dokumentation der Ergebnisse und Beschlüsse sowie eine Kommunikation an alle Betroffenen ist dabei selbstverständlich.

Im Verlauf eines Projekts kommen immer neue fachliche Anforderungen oder Änderungswünsche an bereits beschriebenen oder gar schon umgesetzten Funktionen auf. Für einen geordneten Umgang damit ist ein formaler Change-Request-Prozess (CR-Prozess) unerlässlich. Meist wird der CR-Prozess hauptsächlich unter dem Aspekt Termine und Budget betrachtet. Ein ganz wesentlicher Aspekt bei CRs ist aber auch die Aufrechterhaltung der fachlichen Stimmigkeit eines Systems. Stimmt der CR mit den fachlichen Grundprinzipien des Systems überein oder bringt er ungewollte Seiteneffekte mit sich? Erst wenn das FCD-Gremium einen CR aus fachlicher Sicht verabschiedet hat, ist eine Bewertung bezüglich Aufwand, Terminen und Kosten sinnvoll.

Daneben gilt für Großprojekte in besonderem Maße, dass ein formaler Abnahmeprozess der Spezifikation unter Einbeziehung der künftigen Nutzer durchgeführt werden muss. Nur so erhält man eine zwischen allen Parteien abgestimmte Dokumentation der Fachlichkeit als Basis für die Realisierung und für weitere Diskussionen.