Informationen, die die eine Seite hat, damit die andere zu einem guten Ergebnis kommt, sind im Softwareprojekt von besonderer Bedeutung. Solche Situationen beschreibt die ökonomische Forschung mit dem Prinzipal-Agent-Ansatz: Der Agent verfügt über Informationen, die er zum Nutzen des Prinzipals einbringen soll – allerdings kann der Prinzipal das Verhalten des Agenten nicht jederzeit komplett beobachten. So weiß er nicht, ob der Agent wirklich alles tut, um das vereinbarte Ziel bestmöglich zu erreichen. Daraus entstehen Verhaltensunsicherheiten, die der Prinzipal beherrschen möchte. Das soll über ein geeignetes Vertragsdesign geschehen.

In der ökonomischen Forschung zu Softwareprojekten wird bis heute zumeist der Kunde als Prinzipal angesehen, während dem Lieferanten die Rolle des Agenten zufällt. Das scheint auch nahe liegend, denn der Lieferant soll für den Kunden eine Software entwickeln, er verfügt dazu über Informationen, die der Kunde nicht hat, und er kann während der Softwareentwicklung nicht jederzeit beobachtet werden.

Der Kunde als Agent

Allerdings – und das ist der zentrale Punkt der Arbeit von Cornelia Gaebert – gibt es im Softwareprojekt auch den umgekehrten Fall: Der Kunde wird zum Agenten, und zwar dann, wenn die Anforderungsspezifikation nicht vollständig ist, eine Situation, die uns bei komplexen Softwareprojekten zu Beginn zumeist begegnet. Dann verfügt der Kunde über Informationen, die er für den Erfolg des Lieferanten ins Projekt einbringen muss. Das ist grundsätzlich auch klar, aber es gibt eine reihe von Gründen, die dazu führen, dass der Kunde dies nicht ausreichend tut.

Sowohl für die Wissenschaft als auch für die Praxis ist die Frage interessant, welche Möglichkeiten der Vertragsgestaltung es gibt, um dieses Problem beherrschbar zu machen und das Projekt zum Erfolg zu bringen. Die Antwort hängt von den Gründen ab, die dazu führen, dass der Kunde seinen Beitrag nicht leistet. So kann es sein, dass er dazu schlicht nicht in der Lage ist, weil ihm das Know How oder das Wissen um die Notwendigkeit seines Beitrags fehlen. Es kann aber auch sein, dass er seinen Beitrag bewusst nicht leistet, weil er Ziele verfolgt, die dem Projekterfolg entgegenstehen. Dementsprechend unterscheiden sich auch die Möglichkeiten, die konkrete Situation richtig zu beurteilen und die richtigen Maßnahmen abzuleiten.

In diesem Paper (hier der vollständige Text als PDF), die dieser Tage auf einer Konferenz im schwedischen Lund vorgestellt wird, werden die Wege zu einem geeigeneten Vertragsdesign aufgezeigt.

Cornelia Gaebert (2014). Contract Design and Uncertainty in Software
Development Projects Proceedings of the 13th International Conference on Perspectives in Business Informatics Research DOI: 10.1007/978-3-319-11370-8_16

Der Beitrag Die Unsicherheiten im Softwareprojekt beherrschen erschien zuerst auf INDAL Software-Spezialist.

Zeit, die Blickrichtung zu wechseln. Wir sollten, gerade, wenn das Softwareprojekt durch ein externes Softwarehaus realisiert wird, die Vertragsbeziehung zwischen dem Kunden und dem Softwarehersteller in den Blick nehmen. Ist das Scheitern des Projektes vielleicht oft schon in der Vertragsbeziehung angelegt? Werden Pflichten und Anreize möglicherweise schon dort so festgeschrieben, dass das Projekt in Gefahr geraten muss, sobald auch nur “Kleinigkeiten” schief gehen? Das ist die Frage, der das Forschungsprojekt von Cornelia Gaebert nachgeht. Die ersten Ergebnisse wurden von ihr im August auf einer Internationalen Konferenz in Wien vorgestellt. Die Resultate gelten prinzipiell auch für Projekte, die innerhalb des Unternehmens durchgeführt werden, wenn die Verantwortlichkeiten und die zu tragenden Kosten durch klare Regeln (einen Vertrag) zwischen den Abteilungen festgelegt sind.

Anforderungslücken in der Softwarespezifikation

Anforderungslücken, also die unvollständige Spezifikation und die Änderung von Anforderungen, werden von allen Studien als wichtige Gründe des Scheiterns von Softwareprojekten angesehen. Deshalb wird auch viel Kraft in die Verbesserung der Methoden des Requirement Engineering investiert. Es ist aber plausibel, dass Anforderungen niemals zu Projektbeginn vollständig spezifiziert werden können. Deshalb muss man sich fragen, wie mit Anforderungslücken während des Projekts umgegangen wird. Wer ist für das Schließen der Lücken verantwortlich? Wer muss den Aufwand leisten?

Es sagt sich leicht hin, dass am besten beide Partner, Kunde und Softwarehersteller, diesen Aufwand am besten gemeinsam tragen. In der Praxis müssen beide Seiten Kosten sparen, insbesondere, wenn ein Festpreis für die Erstellung sdes Systems vereinbart wurde, und das Schließen von Anforderungslücken verursacht kosten, Experten werden benötigt, die oft keine Zeit haben, Informationen müssen beschafft werden. Um Kosten zu sparen, versuchen oft beide Seiten, den eigenen Aufwand zu reduzieren und die Arbeit den anderen Partner machen zu lassen.

Das Dilemma zwischen Softwarehersteller und Kunden

Man kann zeigen, dass die Projektpartner sich in einer so genannten Dilemmasituation befinden, die in der ökonomischen Forschung als Gefangenendilemma bekannt ist. Im Ergebnis findet im Projekt keine Kooperation zwischen den Parteien statt – obwohl Kooperation zum besten Ergebnis für beide führen würde. Am Ende stehen beide Seiten mit leeren Händen da, weil das Projekt scheitert.

Die Forschung zum Gefangenendilemma kann aber auch den Ausweg weisen. Sie können Wege aufzeigen, wie der Vertrag zu gestalten ist, damit beide Seiten zur Kooperation bereit sind. Das ist natürlich besonders schwierig, wenn es sich um einen autoritären Festpreisvertrag handelt, den der Kunde dominiert. Aber auch dann gibt es Wege, die Beistellungen des Kunden so zu bestimmen und die Anreize so zu setzen, dass Kooperation nicht ausschließlich auf dem guten Willen der Beteiligten basiert, sondern auf ökonomischen Nutzenskalkülen. Dann legt der Vertrag den Grundstein für den Projekterfolg, und ist nicht länger ein Risiko.

Cornelia Gaebert (2014). Dilemma Structures between Contracting Parties in Software Development Projects Proceedings of the 9th International Conference on Software Engineering and Applications DOI: 10.5220/0004996405390548

Den kompletten Text des Forschungsartikels als PDF finden Sie hier.

Der Beitrag Das Scheitern von Softwareprojekten ist oft schon im Vertrag angelegt erschien zuerst auf INDAL Software-Spezialist.

Nach den Vorstellungen des klassischen Wasserfall-Modells müsste der Business Analyst das DV-Konzept abnehmen und die Realisierung müsste auf der Basis dieses abgenommenen DV-Konzeptes erfolgen. Das ist aber nur zum Teil richtig.

Richtig ist, dass der Business Analyst das DV-Konzept eingehend prüfen muss, er soll ermitteln, ob alle Anforderungen der Fachseite im DV-Konzept aufgenommen wurden und ob Richtlinien und Vorgaben berücksichtigt worden sind. Eine Abnahme aber würde bedeuten, dass der Business Analyst die Verantwortung dafür übernimmt, dass das DV-Konzept die Anforderungen der Fachseite erfüllt – und das ist nicht möglich. Dem Lieferanten würde sozusagen eine Zwischen-Entlastung erteilt ohne dass er sicherstellt, dass die Software den Anforderungen der Fachseite wirklich gerecht werden wird. Das aber ist nicht möglich.

Zum einen kann der Business Analyst im Allgemeinen die Spezifikationsdetails des DV-Konzeptes nicht einschätzen, da es sich dabei um Vorgaben an den Entwickler handelt, dessen technische Know How der Business Analyst nicht hat und nicht haben muss. Zum Anderen kann eine Spezifikation nicht getestet werden wie eine Software, und nur wenn das möglich wäre, wenn man durch einen Test, durch Ausprobieren könnte, ob die Spezifikation “funktioniert”, könnte man auf das technische Know How zur Prüfung des DV-Konzeptes verzichten.

Das heißt jedoch nicht, dass das DV-Konzept nicht abgenommen werden sollte. Die Abnahme soll prüfen, ob die Anforderungen berücksichtigt werden, ob nicht-funktionale und funktionale Anforderungen abgestimmt sind, ob Richtlinien eingehalten wurden. Die Abnahme stellt fest, dass keine Mängel gefunden wurden – nicht, dass keine Mängel vorhanden sind.

Werden im Software-Abnahmetest Fehler gefunden und stellt sich heraus, dass diese Fehler bereits im DV-Konzept vorhanden sind, so hat der Auftraggeber ein Nachbesserungsrecht sowohl auf das DV-Konzept als auch auf die Software. Optimal ist allerdings, wenn vereinbart wird, dass dies nur für Fehler gilt, die der Business Analyst bei der Abnahme des DV-Konzeptes nicht finden konnte.

Das klingt kompliziert – und ehrlich gesagt, das ist auch kompliziert. Wie ein solcher Vertrag ausgestaltet werden kann, hängt sehr stark vom konkreten Projekt ab. Letztlich ist natürlich das Vertrauensverhältnis zwischen den Partnern und die Bereitschaft zum pragmatischen Kompromis ausschlaggebend – aber das lässt sich im Vertrag nicht festschreiben.

Der Beitrag Spezifikationen abnehmen? erschien zuerst auf INDAL Software-Spezialist.