www.dasma.org Foren-Übersicht www.dasma.org
Forum der deutschsprachigen Anwendergruppe für Software-Metrik und Aufwandschätzung
 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen   RegistrierenRegistrieren 
 ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

FPA in der Praxis

 
Neues Thema eröffnen   Neue Antwort erstellen    www.dasma.org Foren-Übersicht -> Aufwandschätzung
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
mat



Anmeldedatum: 15.05.2006
Beiträge: 2

BeitragVerfasst am: 15 Mai , 2006 17:48    Titel: FPA in der Praxis Antworten mit Zitat

Sehr geehrte Damen und Herren,
ich schreibe derzeit meine Diplomarbeit im Bereich Benchmarking/Aufwandschätzuing von Softwareentwicklungsprozessen.
Ich habe folgende Frage an die Praktiker unter euch Wink bezüglich Einsatz der FPA.

Folgende Gründe werden in der Praxis angeführt warum die FP nicht praktikabel ist:

- Erfahrung mit der FPA ist das A und O, oft werden hier Zahlen angeführt die einen umhauen. Schließlich kann man ja in einem Unternehmen nicht erst 300 Projekte schätzen bis man sagen kann es bringt einen Mehrwert.

- Die FP ist eine Analyse die technologieunabhängig arbeitet. Jedoch ist die technische Umsetzung ja auch entscheidend. (Host vs. Client/sServer, etc.)
gewichtete FPs sind aber mittlerweile verpönt.

- Die FP kann erst sinnvoll nach der Erhebung des Fachkonzeptes eingesetzt werden (das leuchtet mir ein), dies ist aber für eine Angebotserstellung viel zu spät.

Die Diplomarbeit wird in Kooperation mit einem IT-Dienstleister (SE) abgewickelt. Da diese noch keine wirkliche Aufwandschätzung besitzen wird in diesem Bereich sehr viel diskutiert. Ich würde gerne die FPA vertreten, doch kommt man gegen die oben genannten Argumente kaum an. Gegenargumente wie Vergleichbarkeit am Markt, etc. sind dann auch nicht mehr schlagkräftig genug.

Wie ist eure Meinung dazu?

Gruß,
Matthias
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Huerten



Anmeldedatum: 23.09.2004
Beiträge: 7

BeitragVerfasst am: 18 Mai , 2006 18:57    Titel: FPA in der Praxis Antworten mit Zitat

Sehr geehrter Matthias,

die Fragen, die Sie stellen, begleiten die Software Metrik und insbesondere die Function Point Analysis seit ihren Anfängen.

Ich habe deswegen der 2. Auflage meines Buches „Function Point Analysis, Theorie und Praxis, 2. Auflage, expert verlag, 2005“ das Kapitel „Warum findet die Function Point Analysis so wenig Akzeptanz?“ hinzugefügt.

In der Computerwoche vom 16.02.2006 erschien ein Aufsatz von mir „Die schlechten Sitten der Vergangenheit hinter sich lassen. Kalkulieren statt Schätzen!“. Hier finden Sie auch Hinweise, die Ihre Fragen zum Teil beantworten.
In meiner Homepage www.huerten-partner.de stehen auch einige kurze Artikel, die auf Ihre Fragen zielen.

Gerne gebe ich Ihnen auch über das Telefon Informationen, die Ihnen bei der Diplomarbeit hilfreich sein könnten.

Mit freundlichen Grüßen
Robert Hürten
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Norbert H.



Anmeldedatum: 27.05.2006
Beiträge: 1

BeitragVerfasst am: 27 Mai , 2006 13:49    Titel: Antworten mit Zitat

Hallo,

ich empfehle die Ermittlung der konkreten Aufwände in den Diskussionen weniger stark zu gewichten. Vermitteln Sie den Kollegen, dass FPA die Komplexität einer Anwendung aus Nutzersicht misst. Damit ist FPA eine Methode, um die notwendige Basis für Aufwandsschätzungen mit unterschiedlichen Verfahren zu erhalten.

> Erfahrung mit der FPA ist das A und O

Für FP-Zähler ist möglichst viel Erfahrung sicher hilfreich. Hunderte gezählte Projekte bis zum ersten Mehrwert für ein Unternehmen sind aber nicht notwendig.

> Jedoch ist die technische Umsetzung ja auch entscheidend.

Für die Aufwandsschätzung spielt die Technik eine Rolle. Statt gewichteter FPs kommen andere Verfahren, die auf FP basieren können, in Frage: CoCoMo, (eigene) Erfahrungskurven je Plattform etc..
Die Komplexität aus Nutzersicht ist unabhängig von der Technik. Die Nutzer interessiert zunehmend, welche Funktionalität sie für ihr Geld bekommen. Wie das technisch realisiert wird und welche Kosten durch die Technik entstehen, wird dem Käufer zunehmend unwichtig.

> dies ist aber für eine Angebotserstellung viel zu spät.

Allerdings gilt das Gleiche auch für die Expertenschätzung. Die wird bei der Angebotserstellung zwar gemacht, die Ergebnisse kennen wir aber zur Genüge. Im Zweifel fragen Sie, was die späteren Entwickler zu den Angeboten der Sales-Leute sagen. Sie müssen die Leute fragen, die von Anfang bis Ende im Projekt waren. Nicht diejenigen, die sich abseilen, bevor das Produkt beim Kunden läuft.
Genau wie die Expertenschätzung können Sie FP auch beim Angebot einsetzen. Die Ergebnisse sind natürlich bei FP und Expertenschätzung um so ungenauer, je ungenauer die Anforderungen bekannt sind.


Stellen Sie folgende Punkte heraus:

1. FP ist eine firmenweit und weltweit einheitliche Methode, wie Anwendungen, Anforderungen usw. in kleine, handliche, überschaubare, möglichst bewertbare Bausteine zerlegt werden.

2. Die Ergebnisse von FP können Kunde und Dienstleister ohne lange Einarbeitung verstehen.

Erläuterung:

Eine solide Aufwandsschätzung, gleich mit welcher Methode, ist nur möglich, wenn sie die geplante Anwendung in einigermaßen verlässlich bewertbare Bausteine zerlegen. Sicher erstellen auch bei Ihrem Dienstleister die guten Schätzer zuerst als Basis ihrer Expertenschätzungen eine Taskliste. Allerdings wird die Granularität und Güte von Entwickler zu Entwickler unterschiedlich sein. Lassen Sie sich die diversen Schmierpapiere, Excellisten, Whiteboardlisten etc. mal zeigen.
FP bringt alle Entwickler zu einer solchen Liste, die zusätzlich weitgehend einheitlich und damit einigermaßen vergleichbar ist. Das gewonnene Schätz-KnowHow bleibt zudem in der Firma, auch wenn ein Experte die Firma wechselt.
Mindestens können die Entwickler ihre Taskliste mit der Liste der Elementarfunktionen aus FP abgleichen. Eine Art Qualitätssicherung, dass möglichst wenig vergessen wurde.
Schon dadurch sollte sich die Qualität der Aufwandsschätzungen verbessern. Und es muss nicht mal mehr Zeit kosten.

Dokumentieren Sie die Zählungen mit einem Tool, dass die Funktionen als Hierarchiebaum darstellt. Es gibt praktisch nichts Besseres, um dem Kunden zu zeigen, was er für sein Geld bekommt. Alle sonst in der IT verwendeten Darstellungen versteht der normale Kunde nicht. Er hat keine Zeit sich da einzuarbeiten. Wenn wir IT’ler es überhaupt wirklich verstehen. Die Missverständnisse werden oft am Ende des Projekts bemerkt. Eine grafische Darstellung "seiner Funktionen" in "seiner Sprache" verstehen Kunden und (meistens) Entwickler problemlos. Wenn die Entwickler es nicht verstehen, gibt es sowieso ein Problem.

Wenn Sie schon das Angebot mit FP unterstützen, wird Auftraggeber und Auftragnehmer klarer, was denn da überhaupt entwickelt wird. Die Kosten explodieren doch meist, weil bei Angebotserstellung (Elementar-)Funktionen schlicht und einfach nicht bedacht wurden bzw. nicht weit genug heruntergebrochen wurden. Der Kunde denkt, sie sind im Angebot enthalten und der Dienstleister nicht einmal ahnt, dass es diese Funktionen geben soll.
Selbst funktionale Spezifikationen sind in der Regel so sperrig, dass niemand wirklich weiß, was später für ein System entsteht. Die funktionale Spezifikation kann mit FP und deren grafischer Darstellung verständlicher werden.

Ein Vergleich der Funktionalität nach Fertigstellung mit dem Angebot kann zeigen, dass die Entwicklung teurer wurde, weil ein ganz anderes System erstellt, als angeboten wurde. Die Änderungswünsche des Kunden sind gut dokumentierbar.

Ganze Angebote etc. auf der Basis FP werden ebenfalls vergleichbarer. Bieten wirklich alle Dienstleister den gleichen Leistungs-(Funktions-)umfang?



Nutzen Sie FP also einfach, um eine bessere Basis als bisher für Aufwandsschätzungen zu erhalten.

Sie haben, auch ohne verbesserte Aufwandszahlen, sofort einen Mehrwert, den sogar das Marketing nutzen kann. „Unsere Angebote und Aufwandsschätzungen basieren auf internationalen Standards, sind transparent“ usw.. Auf Dauer erhalten Sie vielleicht auch wieder verwendbare Erfahrungswerte bzgl. der Aufwandszahlen. Das hängt natürlich davon ab, wie ähnlich sich die Bausteine sind.

Wenn das Argument kommt, dass FP-Zählungen viel zu aufwendig sind, schlagen Sie vor, dass zuerst nur mit Durchschnittswerten gearbeitet wird, ohne einzelne DETs und RETs zu zählen. Das geht dann genau so schnell, wie vorher das Erstellen von Tasklisten.

Bei relativ geringem Einarbeitungsaufwand haben Sie dann einen sofortigen, nicht zu unterschätzenden Nutzen, mit der Aussicht auf langfristig weitere Verbesserungen.

Das Wichtigste und Schwierigste: Nehmen Sie den Entwicklern die Angst, dass FP zeigen könnte, dass ihre Leistungen schlecht sind. Erklären Sie, dass FP und eine spätere darauf basierende „automatische“ Aufwandsschätzung zur Verifikation und Unterstützung der Expertenschätzung dienen, aber diese nicht überstimmen oder gar ablösen. Erklären Sie, dass FP vielleicht helfen kann, eines der dringlichsten Probleme der Entwickler zu lösen: Ständig rechtfertigen zu müssen, warum das Stückchen Software so lange gedauert hat und so teuer geworden ist.

Ist etwas lang geworden, aber Sie wollten ja Diskussionsstoff

Grüße
Norbert
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
mat



Anmeldedatum: 15.05.2006
Beiträge: 2

BeitragVerfasst am: 29 Mai , 2006 11:49    Titel: Antworten mit Zitat

Hallo Herr Hürten, hallo Norbert,
vielen Dank für Ihre interessanten Anwtorten. Sie helfen mir ein ganzes Stück weiter, auch wenn ich derzeit in das Thema Softwaremetrie abgerutscht bin.
Evtl. ist der Vorschlag zunächst "nur" mit Durschschnittswerten zu arbeitet ein geeigneter Start in die Thematik FPA.
Auch wenn mir die Vorgehensweise ohne RETs und DETs noch nicht so ganz klar ist. Ich habe mich bis jetzt bezüglich FP eher "theoretrisch" eingearbeitet. Gibt es hier "recherchierbare Ansätze" ?

Was mich auch brennend interessiert, ist die Frage wie viele dt. Unternehmen die FPA aktuell nutzen bzw. evtl sogar voraussetzen. Ist es denkbar, dass (gerade große, globale) Unternehmen in Zukunft die FPA als Lieferantenkriterium voraussetzen (Angebotsvergleichg, etc.)? Ich kann mir das gut vorstellen, da sie für eine Lieferantenbewertung bestens geeignet ist.

Ich werde versuchen, den Thread aktuell zu halten und werde bei erfolgreicher Recherche meine Ergebnisse einstellen.

Gruß,
Matthias
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Pechlivanidis



Anmeldedatum: 05.10.2004
Beiträge: 11
Wohnort: Bonn

BeitragVerfasst am: 29 Mai , 2006 16:50    Titel: Antworten mit Zitat

Hallo Matthias,

der erste Schritt zur Beantwortung der Frage, wer alles FP macht, kannst du ja mit der Mitgliederliste der DASMA machen. Eine vollständige Liste ist mir nicht bekannt.

Zum Vorgehen am Anfang des Projektes und den Durchschnittswerten:

Durchschnittswerte:
Nach der Identifikation der Transaktionen EI, EO, EQ werden nicht die RET und DET gezählt, die evtl. noch gar nicht bekannt sind, sondern es wird die Annahme getroffen, dass immer Average-Komplexität rauskommt.
Mein eigenes Vorgehen ist hier grob die RET zu identifizieren und anhand dessen die Komplexität zu schätzen (wenn man diese Infos überhaupt hat Wink )

Zur Angebotserstellung:
Die Angebotserstellung, also der Preis wird ja bisher auch ohne FP gemacht. Dieser Preis sollte ja auf irgendwelchen (groben) Anforderungen basieren. Hier kann man dann genausogut die einzelnen Transaktionen und Datenstrukturen erfassen und Durchschnittswerte annehmen.

Es gibt auch Verfahren, in denen man basierend auf Durchschnittswerten (bspw. ISBSG Daten) einzig die fachlichen Entitäten (!=ILFs) zählt und dann mit einem Faktor multipliziert. Diese Art der Schätzung ist zwar schneller aber auch gröber als die oben erwähnte Durchschnittsmethode.

Gerade in Angebotssituationen hat dieses Vorgehen große Vorteile, auch wenn man zur Aufwandsermittlung "nur" allgemeine Produktivitätsfaktoren hat.

Beispiel: Mit der Entitätenschätzung ist man auf etwa 1000 FP gekommen. Dieses Zahl +/- 50% zu verstehen, wobei man mit dieser Methode eher unterschätzt als überschätzt. (Annahme: halbwegs vollständige Beschreibung der Anforderungen!)
Jetzt nimmt man sich einen geeigneten Produktivitätsfaktor, bspw. ISBSG Faktor für Java-Projekte (aus dem Kopf etwa 20 FP/100 h (Median)). Dieser mag jetzt nicht den speziellen Anbieter wiederspiegeln.

Also haben wir 5000 h Aufwand, x Kostensatz des Anbieters, bspw. 100 €/h = 500.000 €.

Wenn nun das Angebot ohne FP in diesem Bereich liegt, so bedeutet dies, dass alle Ungenauigkeiten (+/- 50% in FP, fremder Produktivitätsfaktor, etc.) auch im Angebot liegen, egal ob dieses "schöner" beschrieben wurde.

Hier ist es dann eine Management-Entscheidung, ob man diesen Preis bietet, oder nicht. Ein Fixpreis macht das ganze dann noch interessanter, da der mögliche Verlust durchaus in Sphären von 250.000 € liegen kann. (+50% FP!!!) oder sogar mehr, falls die vorhandenen Anforderungen nur einen kleinen Teil der tatsächlichen Anforderungen repräsentieren.

Bei FP ohne den Produktivitätsfaktor geht es meiner Meinung nach um eine genauere Analyse, an deren Ende ein Dokument mit den offenen Punkten und getroffenen Annahmen rauskommt.

Bzgl. der Ängste der Entwickler:
Ich stimme Norbert zu, dass diese Ängste angegangen werden müssen. Man sollte auch herausstellen, dass nicht die Produktivität der Entwickler, sondern des gelebten Anwendungsentwicklungsprozesses gemessen wird.
Die Qualität des AE-Prozesses hat eine viel größere Auswirkung auf die Gesamtproduktivität, als die eines einzelnen Menschen.

Reale Projekt-Bremsen sind ineffiziente Kommunikation zu Stakeholdern (bspw. Fachbereich). Entscheidungsängste im Fachbereich oder auf IT-Seite, ineffiziente Deployment-Prozesse, fehlende oder von der Produktion verschiedene Testumgebungen, Fehlende Schnittstellen-Absprachen, etc.

Gruß,

Stavros
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Manfred Bundschuh



Anmeldedatum: 11.05.2004
Beiträge: 50
Wohnort: D-51465 Bergisch Gladbach

BeitragVerfasst am: 15 Jul , 2006 08:55    Titel: Function Point Schätzungen Antworten mit Zitat

Hallo Matthias,
- Erfahrung mit der FPA ist das A und O, oft werden hier Zahlen angeführt die einen umhauen. Schließlich kann man ja in einem Unternehmen nicht erst 300 Projekte schätzen bis man sagen kann es bringt einen Mehrwert.
----> eine gewisse Erfahrung muß man aufbauen. In meinem Buch ahbe ich beschrieben, dass erste Nutzen bereits sehr früh bei der Einführung mit Nachkalkulation von 18 Projekten erreicht wurden - es wurde eien FunctionPoint Prognose darauf absierend entwickelt.

- Die FP ist eine Analyse die technologieunabhängig arbeitet. Jedoch ist die technische Umsetzung ja auch entscheidend. (Host vs. Client/sServer, etc.)
gewichtete FPs sind aber mittlerweile verpönt.
----> Das steht auch in meinem Buch: Man muß zwischen Umfangmessung (FP's) und Aufwandschätzung (darauf basierender 2. Schritt) trennen. (Kap. 1.1.6) Im 2. Schritt kommt dann Technik mit ins Spiel. Gewichtete FP's sind der 2. Schritt. Im IFPUG Standard mußten in Vs. 4.1 die gewichtete FP's entfernt werden damit die IFPUG FP Vs. 4.1 ISO Norm werden konnten (...zur Messung von funktionalem Umfang). In IFPUG 4.2 sind sie wieder drin, d.h. IFPUG 4.2 ist keine ISO Norm!

- Die FP kann erst sinnvoll nach der Erhebung des Fachkonzeptes eingesetzt werden (das leuchtet mir ein), dies ist aber für eine Angebotserstellung viel zu spät.
----> siehe dazu in meinem Buch die Kapitel 10.1 (FP Prognose(n) (diese wird bereits 1 Jahr vor Projektbeginn eingesetzt !) und 10.2 Umsetzen der FP's in Personenemonate. Buch: Manfred Bundschuh, Axel Fabry, Aufwandschätzung von IT-Projekten, 2. Auflage, MITP Verlag, Bonn 2004.
Freundliche Grüße,
Manfred Bundschuh
_________________
Manfred Bundschuh
Sander Höhe 5
D-51465 Bergisch Gladbach
Tel.: 02202-35719 (20 - 21 Uhr Telefonsprechstunde)
email: Manfred.bundschuh@netcologne.de
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    www.dasma.org Foren-Übersicht -> Aufwandschätzung Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Sie können keine Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum nicht antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht teilnehmen.


Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de