Planung etwas komplexerer Software-Projekte

[A. B. (steinzeitmensch)]

Hallo,

wie handhabt Ihr die Planung und Umsetzung bei etwas größeren 
Software-Projekten?

Also jetzt keine Riesen-Projekte mit Programmier-Teams, sondern eher 
eine maßgeschneiderte Software-Lösung eines Einzelunternehmers für die 
Kernprozesse eines kleineren Unternehmens mit Schnittstellen zu anderen 
Anbietern (SOAP, etc.) und mit einer zum jetzigen Zeitpunkt vorsichtig 
geschätzten Projekt-Dauer von ca. 9 - 12 Monaten.

Während meiner beruflichen Entwicklung habe ich früher mal einen Blick 
in die Anforderungsunterlagen eines relativ dicken Software-Projekts 
werfen dürfen. Da waren hunderte von Seiten voll mit stets ähnlich 
aufgebauten Absätzen, die jede Funktion, jeden Button, jeden Text, usw., 
furztrocken beschrieben haben.

Eigentlich habe ich mich bei meinen bisherigen Kundengesprächen immer 
auf die Funktionalität der Software beschränkt und versucht, diese 
gemeinsam mit dem Kunden möglichst präzise und dennoch möglichst knapp 
zu beschreiben. Das aktuelle Projekt wird aber etwas umfangreicher 
werden und die Entwicklung soll auch bei Abwesenheit des Chefs durch 
Gespräche mit den Mitarbeitern weiter verfolgt werden, daher stellt sich 
mir die Frage, in welcher Form man die vielen noch folgenden 
Informationen abstrakt und somit kundengerecht visualisieren und dennoch 
jederzeit den gewünschten Komplexitätsgrad wieder hervorzaubern kann, 
damit die vereinbarten Details nicht auf der Strecke bleiben und man 
dennoch frühzeitig Inkonsistenzen erkennt?

Benutzt Ihr dafür Software, um die Anforderungen besser sammeln, 
formulieren und darstellen zu können? Ich bin bei meiner Recherche 
natürlich auf diverse Mind Map Programme gestoßen - was haltet Ihr 
davon?

Also vom Programmiertechnischen her bin ich der Aufgabe definitiv 
gewachsen, aber ich werde da wohl viele Monate dran entwicklen und lange 
Besprechungen mit unterschiedlichen Mitarbeitern haben. 
Missverständnisse bezüglich des Umfangs oder der Funktion sollten daher 
möglichst vermieden werden. Eventuell hat hier ja jemand Erfahrung mit 
Software-Entwicklung in dem von mir beschriebenen Umfang und kann mir 
ein paar nützliche Tipps geben...

Grüße...Jay

[Jan H. (j_hansen)]

Agile Entwicklung :)

Jedes Monat zu Beginn die Ziele für dieses Monat besprechen, dann 
entwickeln und am Ende des Monats dem Kunden einen lauffähigen 
Zwischenstand zum Spielen (oder sogar zum Benutzen) geben.
Meiner Erfahrung nach kann man spezifizieren was man will - erst wenn 
der Kunde etwas sieht und damit spielen kann weiß er, was er eigentlich 
will und braucht.
Schon im Vorhinein alles zu spezifizieren hat bei mir nie funktioniert. 
Außer man ist auf massig Geld durch Change Requests scharf, das soll es 
ja auch öfter einmal geben.

[Christian B. (casandro)]

Mein Tipp, erst mal den Kern des Problems finden, ihn dann lösen und 
dann den Rest dran hängen. Man darf auch keine Angst davor haben, auch 
mal Teile neu zu machen.

Dein großer Feind ist die Komplexität, die gilt es zu vermeiden.

[c-hater (Gast)]

A. B. schrieb:

> wie handhabt Ihr die Planung und Umsetzung bei etwas größeren
> Software-Projekten?

Wie die Igel den GV, sehr vorsichtig.

> Also jetzt keine Riesen-Projekte mit Programmier-Teams

Die Zahl der Entwickler ist eigentlich immer das geringere Problem.

Das Hauptproblem sind die Kunden, die vielfach einfach keinen 
Projektverantwortlichen haben, der auch nur annähernd die nötige 
Kompetenz hat. Damit meine ich: Den abzubildenden Prozeß in seiner 
ganzen Komplexität zu kennen. Schlimmer ist noch: oftmals ist in der 
ganzen verschissenen Kundenfirma überhaupt niemand aufzutreiben, der 
versteht, wie der Prozess im Detail funktioniert, der alle Ausnahmen von 
der Regel kennt und alle Verästelungen von deren Auswirkungen.

D.h.: in aller Regel vergeht entweder die halbe Projektzeit mit der 
Erforschung dieser Sachen durch Leute, die abstraktes Denken gewohnt 
sind (also eigenenes, in der Prozessmodellierung erfahrenes Personal) 
und die darüber hinaus Erfahrung darin haben, die kritischen Punkte 
durch hochnotpeinliche Befragungen quasi des gesamten Kundenpersonals 
herauszukitzeln, oder es kommt unbrauchbarer Schrott raus, um den dann 
langwierige Gerichts-Prozesse geführt werden müssen, wenn der Kunde am 
Ende nämlich merkt, was alles nicht geht, aber gebraucht wird, um den 
oft in den "Ausnahmen" durch und durch unlogischen Prozess in der 
eingefahrenen Form weiterführen zu können. Auf die Idee, mal irgendwas 
zu ändern, was "schon immer so gemacht wurde", kommt natürlich i.d.R. 
kein Kunde. Genausowenig übrigens wie darauf, vor der 
Implementierungsphase von sich aus zu sagen dass es so gemacht wird...

> Während meiner beruflichen Entwicklung habe ich früher mal einen Blick
> in die Anforderungsunterlagen eines relativ dicken Software-Projekts
> werfen dürfen. Da waren hunderte von Seiten voll mit stets ähnlich
> aufgebauten Absätzen, die jede Funktion, jeden Button, jeden Text, usw.,
> furztrocken beschrieben haben.

Von Idioten, für Idioten... Das ist unbrauchbarer Labersülz für Leute, 
die maximal in den Kategorien eines GUI denken können.

Nicht, daß ein gut benutzbares GUI unwichtig wäre, aber das ist eine 
Sache, die man notfalls von Praktikanten umsetzen lassen kann. Das 
Wesentliche ist das, was an der Oberfläche nicht direkt zu sehen ist: 
Das Prozessmodell (neudeutsch: die "business logic"). Wenn das auf den 
abgebildeten Prozess paßt, ergibt sich die GUI-Logik für jede beliebige 
Stelle im Prozess praktisch von selbst.

Deswegen würde ich jedem Kunden empfehlen, tiefstes Mißtrauen gegen 
Anbieter aufzubringen, die nach 10% der Projektzeit erste Versionen der 
GUI-Anwendungen vorführen wollen. Das kann nur kompletter Mist der 
Klasse "PowerPoint enhanced reality" sein, nur daß es halt statt mit PP 
mit VS oder Eclipse generiert wurde...

[Matthias (Gast)]

Jan Hansen schrieb:

> Schon im Vorhinein alles zu spezifizieren hat bei mir nie funktioniert.

Während des Entwicklungsprozesses wird es immer 
Änderungs-/Erweiterungsbedarf von Kundenseite geben. Insofern sehe ich 
es ähnlich wie Jan.

Allerdings sollte im Vorfeld der Rahmen stehen. Bei Sicherheitslösungen 
oder Penetration Tests würde man ja auch nicht dem Kundenwunsch a la 
"Prüfen Sie mal auf alles" entsprechen, sondern eingrenzen, worauf es 
dem Kunden besonders ankommt und was in seinem Falle ein Muß ist, was 
weggelassen werden kann.

A.B. schrieb:

> Ich bin bei meiner Recherche natürlich auf diverse Mind Map Programme gestoßen - 
> was haltet Ihr davon?

Für die kaufmännische Seite oder die Bosse ganz sinnvoll, sollte man 
aber auch nicht überbewerten, denn...

c-hater schrieb:
> Das Hauptproblem sind die Kunden, die vielfach einfach keinen
> Projektverantwortlichen haben

Der Boss sagt, was er will, aber der Projektverantwortliche ist der 
Ansprechpartner und sollte auch was von der Materie verstehen. Dem dann 
mit Folien zu kommen halte ich nicht für zielführend. Viel wichtiger ist 
es, wie schon angeklungen, dass es diesen Verantwortlichen überhaupt 
gibt und das die Zusammenarbeit mit dieser Person im Vorfeld besprochen 
und festgehalten wird.

[Karl H. (kbuchegg)]

c-hater schrieb:

> Kompetenz hat. Damit meine ich: Den abzubildenden Prozeß in seiner
> ganzen Komplexität zu kennen. Schlimmer ist noch: oftmals ist in der
> ganzen verschissenen Kundenfirma überhaupt niemand aufzutreiben, der
> versteht, wie der Prozess im Detail funktioniert, der alle Ausnahmen von
> der Regel kennt und alle Verästelungen von deren Auswirkungen.

Jep.

Hellhörig sollte man auch immer werden, wenn bei den ersten 
Besprechungen dir 10 Dinge auffallen, von denen dein Gegenüber dir sagt 
"Das kommt bei uns nicht vor" ohne weitere Begründung warum nicht.
Wetten doch? Dein Gegenüber weiss das nur noch nicht, weil diese Fälle 
in Eigenregie von den Mitarbeitern gelöst werden.
Verlässt du dich auf dieses "Kommt bei uns nicht vor", dann landest du 
eigentlich unweigerlich nach ein paar Monaten in Teufels Küche.

> Das Wesentliche ist das, was an der Oberfläche nicht direkt zu sehen
> ist: Das Prozessmodell (neudeutsch: die "business logic"). Wenn das auf
> den abgebildeten Prozess paßt, ergibt sich die GUI-Logik für jede
> beliebige Stelle im Prozess praktisch von selbst.

Das ist auch meine Erfahrung.
Wobei das Problem beim Prozessmodell darin besteht, dass der Kunde es 
oft selbst nicht versteht. Da schliesst sich wieder der Kreis zu Jan: Je 
früher der Kunde damit spielen kann, um so schneller fällt auf, wo er 
dir falsche Informationen gegeben hat. Wenn überhaupt. Denn oft nickt 
dein Gegenüber deine Vorschläge einfach nur ab, weil er eigentlich keine 
Ahnung hat, wovon zum Teufel du eigentlich sprichst. Und die Vorschläge 
WERDEN von dir kommen, rechne nicht damit, dass dein Kunde da eine 
grosse Hilfe ist.
Allerdings taucht dann wieder das Problem auf, dass es Kunden gibt, die 
GUI mit Prozessmodell verwechseln und sich stundenlang mokieren, dass 
der Button der ersten Testversion mit der du testen willst, ob die Leute 
mit der Logik klarkommen, die falsche Farbe hat. Bildlich gesprochen.

SW Entwicklung könnte so schön sein, wenn es keinen Kunde gäbe :-)

Das einzige, was bei mir einigermassen funktioniert (hat), ist ein 
konsequent modularer Ansatz. Möglichst wenig Querverbindungen zwischen 
den Modulen. Keine Funktionalität in die GUI, die dort nicht hingehört. 
Um zb Eingaben zu validieren, hält die GUI konsequent Rücksprache, auch 
wenn das momentan programmtechnischer Overkill zu sein scheint.
Dann kann man Module meistens noch gegen eine andere Implementierung 
austauschen. Aber sobald es zu viele Querverbindungen und Verflechtungen 
gibt, wird das oft schwierig.

[Little B. (lil-b)]

Karl Heinz schrieb:
> ... dann landest du
> eigentlich unweigerlich nach ein paar Monaten in Teufels Küche.

Darauf würde ich mich freun. Die Teufels Küche ist ein super Burger- und 
Steak-Schuppen! http://www.teufelskueche-ab.de/

Aber zum Thema:
Ich habe auch schon erlebt, dass der Kunde gar nicht weiß, was er 
eigentlich will. Und eigentlich will er es auch gar nicht so genau 
wissen.
Eigentlich hast du einfach nur eine Möglichkeit, ein Maßgeschneidertes 
Produkt zu verkaufen, bei dem der Kunde nur die grobe Funktion vorgibt.

Jede detaillierte Dokumentation im Vorfeld tust du also eigentlich nur 
für dich. Der Kunde verlangt meistens nicht mehr als ein paar 
Milestones.

Hast du jedoch einen kompetenten Kunden (sowas soll es auch geben), dann 
wird er dir den Rahmen auch entsprechend vorgeben. Das kann dann 
beliebig detailliert werden und sollte im Lasten/Pflichtenheft 
niedergeschrieben werden

[Karl H. (kbuchegg)]

Noch was:
von irgendwelchen Programmen, mit denen beim Kunden die Anforderungen 
aufgenommen werden, halte ich ehrlich gesagt überhaupt nichts.

Das Problem: 70% der Zeit wird damit verschissen, auszuprobieren welcher 
Font in welcher Größe für Überschriften benutzt werden soll und welche 
Stichworte in welcher Farbe unterstrichen werden sollen. D.h. nachdem 
man 30 Minuten damit verbracht hat, den beschissenen Beamer beim Kunden 
am Laptop anzuschliessen.
Derartige Programme verleiten dazu, sich mehr mit der Form als mit dem 
Inhalt zu beschäftigen. Ich war schon in Besprechungen, die 
hauptsächlich daraus bestanden, dass jemand in Mind Map Punkte von einer 
Ecke des Bildschirms in die andere zu verschieben, weil das besser 
aussieht.

Papier und Kugelschreiber und zu Hause kann man dann meinetwegen das 
alles in elektronische Form bringen und dem Kunden zur Kontrolle 
zusenden.

[c-hater (Gast)]

Karl Heinz schrieb:

> Wobei das Problem beim Prozessmodell darin besteht, dass der Kunde es
> oft selbst nicht versteht.

Sag' ich ja. Manchmal ist es echt erschreckend, daß Produktion 
tatsächlich überhaupt funktioniert, obwohl eigentlich absolut niemand 
der Beteiligten weiß, wie genau sie eigentlich in ihrer Gesamtheit 
funktioniert. Tatsächlich ist das nämlich auf Grund der Vielzahl der 
intelligenten Beteiligten in gewissem Maße ein selbstorganisierendes 
(aber leider nicht unbedingt selbstoptimierendes) stochastisches System.

Das ist allerdings gut für uns Software-Lieferanten. Wenn man erstmal 
"drin" ist, sind Folgeaufträge fast unausweichlich, weil man immer 
derjenige Anbieter sein wird, der die durch die Selbstorganisation oder 
auch äußere Einflüsse nötigen Änderungen zu den geringsten Kosten in das 
bestehende System einpflegen kann. Es sei denn, man hat zwischenzeitlich 
den oder die Entwickler entlassen, die sich mit dem System auskennen. 
Dann ist man oft raus, weil dann der Kostenvorteil massiv 
zusammenschmilzt und die Konkurrenz mit Dumping-Abschlägen zum 
"reinkommen" kalkuliert oder auch einfach nur wild spekuliert und es auf 
einen Gerichtsprozess ankommen läßt. Selbst wenn die den verlieren, 
hilft dir das nicht: du bist raus, denn die Projektkohle ist dann 
bereits verbrannt.

> SW Entwicklung könnte so schön sein, wenn es keinen Kunde gäbe :-)

Wohl wahr...

> Das einzige, was bei mir einigermassen funktioniert (hat), ist ein
> konsequent modularer Ansatz. Möglichst wenig Querverbindungen zwischen
> den Modulen.

Das ist natürlich immer anzustreben. Blöderweise wird genau das eben 
fast immer dadurch unterminiert, daß es Abhängigkeiten gibt, von denen 
du noch garnix weißt, weil halt das Prozessmodell nicht vollständig 
ist...

[Christian B. (casandro)]

Ach ja, lese mal "The Art of UNIX Programming" durch, da stehen viele 
wichtige Hinweise drin.

Auch ist es oft sinnvoll zuerst einen Prototypen zu bauen. Der mal die 
wichtigsten Funktionen abdeckt und nicht schön sein muss. Das kann man 
dann den Nutzern geben um Feedback zu bekommen. Damit kann man auch 
rechtzeitig feststellen ob man nicht total auf dem Holzweg ist.

Die meisten Probleme in der Software sind nicht sehr komplex wenn man 
sie mal richtig verstanden hat. Das Verstehen des Problems dauert die 
meiste Zeit.

Und versuche die Software selbst zu benutzen. Stört Dich dabei was, so 
baue das um so dass es Dich nicht mehr stört.

Baue keine Funktionen um der Funktion selbst wegen ein, es sei denn sie 
ist orthogonal und ermöglicht völlig neue Anwendungen. Im Allgemeinen 
sollten die meisten Funktionen orthogonal sein, sprich sich nicht 
überlappen und dafür gegenseitig ergänzen.
Für immer wiederkehrende Vorgänge können aber auch nicht-orthogonale 
Funktionen notwendig sein die im Prinzip die Arbeit von n anderen 
Funktionen machen. Versuche Wege zu finden, dabei doppelten Codeaufwand 
zu sparen.

[Jürgen H. (jdhenning)]

Das ist auch meine Erfahrung, dass der Kunde zu Projektbeginn nicht 
(genau) weiß, was er eigentlich braucht und der 
System/Software-Ersteller hat nur in Ausnahmefällen eine Ahnung davon. 
Das führt oft zu zwei unschönen Abläufen:

Der Kunde schreibt in seinen Worten das Pflichtenheft, der Realisierer 
schreibt in seinen Worten die Grobspezifikatio, die dann zur 
Vertragsgrundlage wird. Wenn der Kunde das fertige Programm/System 
bekommt, dann fühlt er sich oft über den Tresen gezogen, weil er das 
Ergebnis fast nicht brauchen kann, aber bezahlen muss.

Der Kunde ist projektbegleitend dabei und es fließen laufend 
Änderungswünsche ein ("Die einzige Konstante in diesem Projekt ist die 
Zahl der monatlichen Änderungen!"). Wenn man da keine Gleitklausel im 
Vertrag hat, dann zahlt man als Firma letztlich drauf.

Rapid Prototyping ist, falls anwendbar, ein hervorragendes Mittel, wenn 
man den Kunden dazu bekommen kann, die Funktionen und nicht das Aussehen 
zu bewerten. Mit so einem Prototypen lernen Kunde und Realisierer 
gemeinsam, bevor wirklich kostenintensive Arbeiten angepackt werden.

Von den ganzen Planungswerkzeugen halte ich sehr wenig, denn sie sorgen 
nur dafür, dass man Papier gutaussehend bedrucken kann; den wichtigen 
Teil, nämlich das Nachdenken, können sie nicht ersetzen und bestenfalls 
nur minimal unterstützen. Wenn man weiß, was man wie realisieren will, 
dann kann man solche Tools benutzen, um hübsches Papier zu erzeugen.