Kostenabschätzung für Software-Entwicklung

[Lkas86]

Guten Tag,
Wir sind auf der Suche nach ein paar Erfahrungsberichten oder allgemeinen Informationen.
Es geht um ein Uni-Projekt zur Abwicklung von Steuererklärungen und Behördengängen für Exsitentzgründer.
Bei diesen Vorgängen ist eine Vielzahl an bürokratischen Hindernissen zu überwinden und laut Statistiken sind ein Drittel aller Kleinunternehmer mit diesen Vorgängen überfordert.
Da Kleinst- / und Kleinunternehmen sehr häufig keine eigenen Angestellten für bürokratische Angelegenheiten haben müssen sich die Einzelunternehmer auf eigene Faust darum kümmern.
Die Software soll sich orientieren an bekannten Stuersoftwares, zusätzlich sollen oben genannte Bürokratie-Angelegenheiten bei Neu-Gründungen berücksichtigt werden.
Wichtig zu wissen wäre es, wie man den Kosten / und Zeitaufwand für ein solches Projekt richtig einschätzt.
Da es sich um ein Projekt für die Universität handelt geht es nur zweitrangig um die tatsächliche Umsetzung und mehr um eine vernünftige Einschätzung, um den Business-Plan dafür vor zu legen.

 

[pizza4ever]

100 Millionen Euro.

Im ernst, was erwartest du hier? Eure Recherchearbeit musst du schon selbst machen.

 

[species_0001]

mal gaaaaanz grob und ins Blaue hinein:
1MJ BWLer für die inhaltlicher Arbeit = 12*160h*70€ = 134.400€
1MJ Programmierer für Programmierung = 12*160h*70€ = 134.400€
+ unbekannte Kosten für eventuelle Patent/Lizenzgeschichten an Dritte.
+ x
Also ne halbe Mio sollte man schon mitbringen.

 

[SoftMaxx]

Ich denke eben diese "Vielzahl an bürokratischen Hindernissen zu überwinden" zieht so viele Unwägbarkeiten nach sich, dass das Projekt nicht wirklich kalkulierbar ist. Außerdem hat jedes Unternehmen eine andere Situation/Bedürfnisse, das macht es nur noch komplizierter und als Unternehmer würde ich mich da schon garnicht auf so eine Software verlassen, gerade wenns um Behörden geht. Klingt für mich nach einer Mammutaufgabe, bei der man fast nur verlieren kann..

 

[HorstSch87]

Ohne konkretes Pflichtenheft kann man dazu keine wirkliche Aussage treffen. D.h. es wird zuerst eine Anforderungspezifikation erstellt ("Was soll die Software genau können?"), dann dazu passend ein Pflichtenheft ("Wie wollen wir die Anforderungen umsetzen?"). Das machen Kunde und Entwickler in enger Zusammenarbeit, je sorgfältiger sowas gemacht wird, desto besser. Aus den einzelnen Punkten des Pflichtenhefts kann man dann die Kosten abschätzen. Erfahrungsgemäß kriegt man die besten Ergebnisse mit der Pi mal Daumen Methode aus Erfahrungswerten plus kundenspezifischen Zuschlägen (für die Kunden, die zunächst einen Toaster bestellen und am Ende doch lieber ein Raumschiff wollen...), gerade wenn es um agile Entwicklungsprojekte geht. Es gibt natürlich auch tolle Verfahren wie Funktionspunktanalyse oder Cocomo, die aber hauptsächlich die BWLer glücklich machen.

 

[ayngush]

"Pflichtenheft" und "Agil" geht eigentlich nicht zusammen. Agil fängt mit User Storys und einem Business Case an und nicht mit einem Pflichtenheft und lebt davon, dass am Anfang eben nicht alle funktionalen Anforderungen, Qualitätsmerkmale und Rahmenbedingungen gefunden wurden.

Zur groben Einschätzung solcher Projekte bedient man sich auch nicht der "Pi mal Daumen" Methode, sondern aus einem Mix aus Analogien, Schätzklausuren / Delphi, Mehrpunktschätzungen und Expertisen.

Im Detail verfeinert man erst Später im Projektverlauf, wenn dann agil vorgegangen wird, nachdem man mittels eines Requirements Engineering Prozesses die Anforderungen usw. erarbeitet und Dokumentiert hat, dann mittels der "agilen" Schätzmethoden (Team Estimation, Planning Card Game, usw.) und der Performancebeobachtung (Velocity) die Schätzungen kontinuierlich. Hat man ein erfahrenes Developer Team und ein gut ausgearbeitetes Product Backlog zum Start, kann man zu diesem Zeitpunkt eine erste recht genaue Einschätzung der Aufwände bekommen.
Bis dahin gilt, vor allem für vorab eingeschätzte Projekte und traditionelle Vorgehensmodelle, laut der "Cone of Uncertainty" ein Schätzfehlerfaktor von +-4. d.h. ein Projekt mit 1.000.000 EUR geschätzten Kosten kann 250.000 kosten oder 4.000.000...

Grüße

 

[HorstSch87]

Du hast natürlich recht, den Halbsatz zu agilen Vorgehensweisen hatte ich erst später reineditiert, der macht in Kombination mit dem Anfang so keinen Sinn.
Einig sind wir uns ja aber, dass man zunächst mal Anforderungen und mögliche Umsetzungen ausfürhlich diskutieren muss, bevor die ganze Schätzerei überhaupt in die richtige Richtung gehen kann.

 

[ayngush]

Absolut. Ich orientiere mich, agil hin oder her, bei Projekten immer an den Phasen des DIN-Projektmanagements. Einfach, weil es gar nicht so schlecht ist. Die Umsetzungsphase und teile der Planungsphase gestalte ich dabei dann agil aus.
Grundsätzlich fängt ein Projekt aber immer mit der Idee an, daraus formuliert man mit Hilfe von Skizzen und einer Beschreibung einen Business Case (das Vorhaben und den Nutzen). Wer BWL mag kann dann hier schon erste Break Even und Nutzen-Leistungspunktbetrachtungen anstellen.
Soll es dann zu präziseren Aussagen kommen muss ja einiges an Arbeit geleistet werden (IST / SOLL (Requirements Engineering), ggf. Prototypen erstellen, Risikobeurteilung, Machbarkeit -> User Storys. Und die will ja auch bezahlt werden und dauert mitunter auch einige Zeit.