Java Lastenheft -> Systemauswahl -> Pflichtenheft

[standi]

Hallo Leute,

ich hätte eine kleine Frage zum üblichen Verlauf zwischen Lasten- und Pflichtenheft, da ich denke, dass hier viele Mitglieder mit Erfahrung anwesend sind.


Im Lastenheft sind die Anforderungen (bsp. Software oder Hardware), die vom Auftraggeber (AG) gefordert werden.

Der Auftragsnehmer (AN) antwortet mit einem Pflichtenheft, wie er gedenkt diese Anforderungen umzusetzen.

Nun meine Fragen:

1. Je nach Beziehung zwischen AG und AN, kann das Pflichtenheft dementsprechend detailliert sein (schon mit Lösungsvorschlägen, Klassendiagramme, welches Produkt was zum Beispiel für eine Anforderung eingekauft wird usw) oder weniger detailliert. Habe ich das "grob" richtig verstanden oder schreibt man generell im Pflichtenheft nichts, sondern kopiert die Anforderungen vom Lastenheft und übernimmt es fürs Pflichtenheft?

2. Eine Systemauswahl macht aber der AG sicherlich schon vor dem Pflichtenheft ne? (Bsp. welche Software für die Anforderung richtig wäre und führt Recherchen durch, was sich eignet oder evtl. Eigenentwicklung. Dazu gehört sicherlich auch Nutzwertanalyse, Kosten-Nutzen-Rechnung, Punktebewertung usw.


Falls ich falsch denke, würde ich mich über Anregungen freuen.

Grüße

 

[Tumbleweed]

Da gibt es keine einheitliche Lösung. Die von dir genannten Begriffe sind natürlich gute Anhalts- und Ausgangspunkte, wenn man noch kein eigenes System hat. Mit der Zeit macht man aber eigene Erfahrungen und entwickelt den Prozess somit weiter.
Wo ich im Moment arbeite, geht es zum Beispiel von einem ersten "Wunsch"/Idee eines Kunden in eine Grobschätzung (für Aufwand), dann in eine Feinspezifikation und währenddessen gibt es viel hin und her und Austausch mit dem Kunden. Da es in meinem Fall ein fester Kunde ist (was ja bei dir anders sein kann) hat sich der Prozess schon gut eingeschliffen und man spricht die gleiche Sprache. Irgendwann ist die Feinspezifikation abgeschlossen und die Implementation läuft los. In ihr enthalten sind auch test cases, anhand derer die Vollständigkeit und Funktionalität dann am Ende bewertet wird. Damit sichert man sich ab, dass der Kunde nicht in der wall of text irgendwo implizit Funktionalitäten versteckt und später darauf besteht.

Wie gesagt, ich denke das macht jeder anders und so wie es am effektivsten erscheint.

 

[standi]

Hi,
danke für die schnelle Antwort. Deine Vorgehensweise hört sich nicht schlecht. Du würdest deinen Vertrag dann nach der Grobschätzung aufsetzen oder? Oder erst später? Wie viel gibst du dann bei der Feinspezifikation preis?

Zu meinem Beitrag zurück. Liege ich da mit dem Systemauswahl vor dem Pflichtenheft richtig?
Ich spreche da nicht in meinem (privaten, Einzelunternehmung) Fall, sondern eher von größeren Firmen, da zum Beispiel nach bestimmten Vorgehensmodellen (v-Modell..) agieren.

Grüße

 

[Tumbleweed]

Naja, der Vertrag besteht bei mir insofern bereits, dass das Produkt schon existiert (Web-Plattform) und nun quasi Wartung, Modifkation und Erweiterungen anstehen. Da ist es dann so, dass die Grobschätzung (die nicht all zu lange dauern sollte) als Service durchgeht (sowas wie ein Kostenvoranschlag) und dann ab Feinspezifikation der Taxameter mitläuft, für die benötigte Zeit (da das durchaus unterschiedlich ist, je nach Aufwand).
Und noch für dich zur Einordnung - ich arbeite in einem kleinen Unternehmen (< 20 Leute), allerdings mit recht großen, internationalen Kunden.

Bei dir klingt es so, dass du ein Produkt (lokale Anwendung?) für einen Kunden erstellen willst. Daher passt der Vergleich mit mir nicht. Zur Systemauswahl würde ich sagen, dass das sehr darauf ankommt, mit was für Kunden du zu tun hast. Wenn dich ein KMU anspricht und z.B. eine Lagerverwaltungssoftware haben will, dann ist denen vermutlich egal, wie du das bewerkstelligst. Du musst etwas liefern, was auf deren Systemen läuft und ihre Daten importieren kann.
Gibt aber auch Kunden, die sehr genaue Vorstellungen haben oder die z.B . von einem anderen Dienstleister zu dir wechseln und dir dann ihre Altlasten (so Typo3-Monster und solche Späße) überhelfen. In dem Fall müsstest du dann eher eine Machbarkeitsanalyse machen, um herauszufinden, ob das mit der gewünschten Technik (für dich) umsetzbar ist.

Willst du das wissen, weil du dich selbstständig machst oder nur generell mal interessiert?

 

[standi]

Hi,

bei mir geht es um generelles Interesse. Bin nicht selbstständig, das Interesse kommt mehr aus schulischem Interesse. Der Lehrer meinte, dass die Antwort auf ein Lastenheft per Pflichtenheft erfolge. Das Pflichtenheft wäre auch die Basis des Vertrags zwischen AG und AN.

Nun wollte ich mich etwas vertiefen und Google bringt hier wenig Standards (ISO, DIN, usw.). (Wäre auch schwierig bei so vielen verschiedenen Produkten, Ansätzen und Vorgehensmodellen etwas universelles zu schaffen)


Bei den Anforderungen des Kunden hatte ich mir zum Beispiel überlegt, wenn dies eine DMS, Groupware, CRM oder ähnliches wäre. (Hier wäre Eigenentwicklung oder Beschaffung möglich)

Wenn dich ein KMU anspricht und z.B. eine Lagerverwaltungssoftware haben will, dann ist denen vermutlich egal, wie du das bewerkstelligst. Du musst etwas liefern, was auf deren Systemen läuft und ihre Daten importieren kann.

Genau so ähnlich. Wie würde das Pflichtenheft dann in etwa aussehen. Je nach Beziehung zum Kunden unterschiedlich detailliert? Auch mit Lösungsansätzen oder nur, dass die Anforderung 1 bis 10 einfach nur schlicht erfüllt wird.

Machbarkeitsanalyse hört sich schon gut an, ob die Anforderungen auch erfüllt werden können. Danke für das Stichwort. Nun stelle ich mir noch die Frage, ob Kusten-Nutzen-Rechnung, Nutzwertanalyse usw. auch schon beim erstellen des Pflichtenheftes erfolgt, oder danach, bzw. weitaus davor?

 

[Tumbleweed]

Also dass das nicht so mein Fachgebiet ist, weißt du ja, aber wenn sich hier keiner aus der Sparte zu Wort meldet, kann ich ja mal mitphilosophieren.

Ich glaube, dass das enorm von der Zielgruppe/dem Kunden abhängt. Entweder hat der Kunde selbst Ahnung von/Interesse an der Materie oder will er nur den Dienst haben, egal wie du es löst. Gibt es beides. Die Kosten-Nutzen-Rechnung sehe ich dann auch mehr beim Kunden, als bei dir, denn die Kosten, die entstehen (z.B. Hosting eines web service), die liegen ja nicht bei dir, sondern die hilfst du komplett dem Kunden über. Ebenso die Wartungskosten. D.h. du legst dem Kunden vor, was es kosten würde (aus deiner Sicht). Dann entscheidet er, ob es ihm das wert ist. Er kann natürlich auch einen anderen Dienstleister um den Kostenvoranschlag bitten und dann vergleichen, daher solltest du einen Mittelweg finden zwischen Gewinn für dich und Dumpinglohn.

Dann noch zu dem was du in der Schule so lernst - es ist alles sehr theoretisch und leider erfahrungsgemäß weit von dem entfernt, was in freier Wildbahn praktiziert wird. Man tut sich keinen gefallen, wenn man an solch theoretischen Konstrukten auf Teufel-komm-raus festhält. Akademiker haben oft tolle Ideen, aber wenig Sinn für die freie Wirtschaftswelt. Was anderes ist es, wenn du an einem Seminar teilnimmst bzw. ein Buch liest von jemandem, der in der Software-Entwicklung gearbeitet hat.

 

[estre]

Aus meiner Erfahrung sage ich dir mal wie das üblicherweise in der Praxis abläuft (am Beispiel eines CRM-Systems, bei einem ca. 400 Mitarbeiter großem Unternehmen).

Zunächst stellt der Fachbereich (eine bestimmte Abteilung im Unternehmen (Marketingabteilung, etc.)) fest, dass man zur Kundenaquise neue Instrumente benötigt um diese effizienter zu gestalten. Man setzt sich also zusammen und beschließt mit dem Abteilungsleiter, dass man für diese Anforderungen gerne eine Softwarelösung hätte.
Sofern das Unternehmen eine eigene Stabstelle/Abteilung für Projektmanagement besitzt (ansonsten externe Projektbetreuung) wird der Fachbereich seine Wünsche dort zunächst einmal kundtun.
In vielen Sitzungen und in enger Zusammenarbeit mit der IT-Abteilung, entsteht nun ein Lastenheft in dem von völlig abstrakten Anforderungen, bis hin zu wirklich detaillierten Dingen alles drin steht (z.B. dass die Software ein Webfrontend haben muss, oder dass man Newsletterkampagnen fahren kann, what ever ....). Üblicherweise stehen hier z.B. auch schon detaillierte Schnittstellenanforderungen zu bestimmten Systemen, die im Unternehmen eingesetzt werden, drin. Denn man darf nicht vergessen -und das ist der nächste Schritt- dass anschließend dieses Lastenheft an diverse Softwareanbieter verschickt wird und die sich anschließend auf Basis dieser Anforderungen im Lastenheft bewerben können. Im Rahmen der Bewerbung erhalten die Softwareanbieter eine sogenannte Compliancematrix in der sie den Erfüllungsgrad der jeweiligen Anforderung bewerten.
Sind alle Angebote eingegangen findet in anhand der Ergebnisse in den Compliancematrixen ein Entscheidungsprozess innerhalb der Projektbeteiligten statt, sodass am Ende aus einer Longlist an Softwareanbietern eine Shortlist aus vlt. nunmehr 5 Anbietern wird.
Diese 5 Anbieter werden nun zu Terminen eingeladen an denen sie ihre Software im Unternehmen vorstellen können. Nach vielen Terminen verständigen sich die Projektbeteiligten nun auf vlt. 2, max. 3 Anbieter die an der finale Entscheidungsphase teilnehmen.
D.h. jetzt entscheiden nur noch Nouancen. Deswegen finden nun Referenzbesuche statt. Das bedeutet, dass die Projektbeteiligten sich jeweils einen Kunden der Softwareanbieter (der ungefähr die gleichen Anforderungen erfüllt) anschauen, Fragen stellen und sich ggfs. auch mal selbst mit dem System vertraut machen.
Ist dies abgeschlossen finden die finale Entscheidung statt. Anschließend wird die Entscheidung an den Vorstand des Unternehmens herangetragen und das Ganze abgesegnet (oder eben nicht) und budgetiert.

Ist die Entscheidungsphase erst einmal abgeschlossen, wird in Zusammenarbeit mit dem Softwareanbieter ein Pflichtenheft erstellt. Dies ist dann auch verbindlich und alle dort niedergeschriebenen Dinge müssen genau so umgesetzt werden. Anpassungen , oder Erweiterungen müssen meistens extra bezahlt werden. Im Idealfall ist das Pflichtenheft eine detailliertere Beschreibung des Lastenheftes. Allerdings ist es in der Praxis so, dass der Fachbereich in der Entscheidungsphase feststellt, dass er eigentlich noch ganz andere Dinge haben möchte, sodass im Pflichtenheft erfahrungsgemäß noch ganz andere Dinge stehen. Grundsätzliche soll es aber die Punkte im Lastenheft konkretisieren und eine Umsetzung der Anforderungen beschreiben (Es ist also die Frage nach dem Wie, nicht nach dem Was!).
Nach etlichen Monaten, vielen zusätzlichen Kosten, einer Testphase und Workshops für die Anwender wird die Software produktiv geschaltet und im Idealfall ein Abnahmeprotokoll unterschrieben. Damit ist das Projekt dann beendet


Diesen Ablauf habe ich persönlich so erlebt, ich denke, dass es in vielen anderen Unternehmen auch so gehandhabt wird ....

 

[standi]

hey,
vielen Dank euch beiden für die tiefen Einblicke und den Informationen zum Ablauf. Ich hoffe, dass ich mit kleinen Gegenfragen den Thread nicht komplizierter mache. Ich habe aber schon einen sehr guten Überblick über den Ablauf bekommen. Nochmals vielen Dank. Will aber trotzdem noch ein paar kleine Rückfragen stellen.


@estre

Sind alle Angebote eingegangen findet in anhand der Ergebnisse in den Compliancematrixen ein Entscheidungsprozess innerhalb der Projektbeteiligten statt, sodass am Ende aus einer Longlist an Softwareanbietern eine Shortlist aus vlt. nunmehr 5 Anbietern wird.

Wird zum Compliancematrix von den Softwareanbietern auch grob die Kosten genannt?

Diese 5 Anbieter werden nun zu Terminen eingeladen an denen sie ihre Software im Unternehmen vorstellen können.

Bei vorhandenen Fertiglösungen können diese 5 Anbieter Kleinigkeiten vorstellen. Bzw. eine Basis demonstrieren und noch anfallende Veränderungen/Entwicklungen, die aufgrund der Lastenhefts gefordert werden, aufzeigen.

Ist die Entscheidungsphase erst einmal abgeschlossen, wird in Zusammenarbeit mit dem Softwareanbieter ein Pflichtenheft erstellt.

Das ist die Stelle, die mich nun ein wenig irritiert. D.h., in diesem Ablauf wurde bis zur Entscheidung kein Pflichtenheft erstellt, sondern erst, wenn man sich für den "einen" Softwareanbieter entschieden hat.
D.h., während der Verfassung des Pflichtenhefts könnten noch Unstimmigkeiten, Meinungsverschiedenheiten oder nicht 100%'ige Abdeckung des Lastenhefts kommen.

Allerdings ist es in der Praxis so, dass der Fachbereich in der Entscheidungsphase feststellt, dass er eigentlich noch ganz andere Dinge haben möchte, sodass im Pflichtenheft erfahrungsgemäß noch ganz andere Dinge stehen. Grundsätzliche soll es aber die Punkte im Lastenheft konkretisieren und eine Umsetzung der Anforderungen beschreiben (Es ist also die Frage nach dem Wie, nicht nach dem Was!).

Ahja, okey, dann hat sich meine vorherige Frage erübrigt.

(Es ist also die Frage nach dem Wie, nicht nach dem Was!).

Genau. Das hatte unser Lehrer auch so herübergebracht. In seinem Ablauf jedoch, haben die Firmen kein Compliancematrix erstellt, sondern auf das Lastenheft gleich mit einem Pflichtenheft geantwortet. (Wie das Lastenheft gedenkt wird zu lösen).

 

[estre]

Hi,

Wird zum Compliancematrix von den Softwareanbietern auch grob die Kosten genannt?

Die Compliancematrix selbst beinhaltet keine Kosten. Du kannst sie dir eher als eine Exceltabelle vorstellen in der die Anforderungen aus dem Lastenheft aufgelistet sind und in die der Softwareanbieter im Rahmen seiner Bewerbung dann jeweils den Erfüllungsgrad zu den einzelnen Anforderungen einträgt (z.B. in Prozent).
Die Kosten gibt der Softwareanbieter zwar auch im Rahmen seines Bewerbungsangebotes ab, allerdings sind diese in der Regel keineswegs final.

Bei vorhandenen Fertiglösungen können diese 5 Anbieter Kleinigkeiten vorstellen. Bzw. eine Basis demonstrieren und noch anfallende Veränderungen/Entwicklungen, die aufgrund der Lastenhefts gefordert werden, aufzeigen.

Also in der Regel läuft es so ab, dass die möglichen 2-3 Softwareanbieter auf der Shortlist vorab Anwendungsfalldiagramme erhalten. Diese beinhalten konkrete Prozesse die das Unternehmen gerne mit der Softwarelösung abdecken möchte.
Für die Vorstellung der eigenen Software versuchen die Softwareanbieter diese Anwendungsfälle nun so gut wie möglich umzusetzen. Natürlich kann man nicht davon ausgehen, dass schon sämtliche Schnittstellen zu anderen Systemen vorhanden sind, oder das wirklich jedes Detail abgebildet ist, allerdings sollte man schon den Eindruck vermitteln, wie man gedenkt die Anforderungen des Unternehmens umzusetzen.

Das ist die Stelle, die mich nun ein wenig irritiert. D.h., in diesem Ablauf wurde bis zur Entscheidung kein Pflichtenheft erstellt, sondern erst, wenn man sich für den "einen" Softwareanbieter entschieden hat.
D.h., während der Verfassung des Pflichtenhefts könnten noch Unstimmigkeiten, Meinungsverschiedenheiten oder nicht 100%'ige Abdeckung des Lastenhefts kommen.

Genau, das Pflichtenheft wird erst erstellt, wenn man sich für einen Softwareanbieter entschieden hat, vorher geht das auch gar nicht. Denn jeder Hersteller bietet andere Möglichkeiten und setzt z.B. bestimmte Schnittstellen anders um. Oder ob man sich für eine Standardlösung, oder eine Individualsoftware entscheidet. Beides bietet völlig unterschiedliche Voraussetzungen.

In seinem Ablauf jedoch, haben die Firmen kein Compliancematrix erstellt, sondern auf das Lastenheft gleich mit einem Pflichtenheft geantwortet. (Wie das Lastenheft gedenkt wird zu lösen).

Meiner Meinung nach ist diese Vorgehensweise nicht praxisnah. Denn stell dir vor du erarbeitest ein Lastenheft mit deinen individuellen Anforderungen an das neue System und schickst dieses dann anschließend an "wildfremnde" Softwarehersteller.
Wie soll nun der Bewerber auf dieser Basis ein aussagekräftiges Pflichtenheft erstellen ohne die genauen Unternehmensprozesse zu kennen? Das wäre alles ziemlich Wischi Waschi und mMn keine saubere Projektdurchführung.

 

[standi]

Hallo,
vielen Dank für Eure ausführlichen Beiträge. Ich habe nun einen guten Einblick in die Durchführung, bzw. Schnittstelle zwischen Lasten- und Pflichtenheft erhalten.


Nebenbei:
Ein Grobüberblick über Lasten- und Pflichtenheft habe ich zumindest erhalten. Da ja im Pflichtenheft nicht nur die Anforderungen aufgelistet sind, die der Auftragnehmer erfüllen wird, bzw. soll, sondern auch, wie er diese erfüllt (Bsp. mit Software A wird anforderugnen 1, 2, 3 und Software B Anfoderungen 4, und Eigenentwicklung Anforderungen 5 abgedeckt).

Bei der Gesamtsystemspezifikation (V-Modell), bzw. Software Requirements Specification (SRS) und Software Design Description (SDD) wird ja zwischen Anforderungen und Design (also das WIE) getrennt.