Wie nützlich sind Funktionspunkte? [geschlossen]

Wie nützlich ist es, Funktionspunkte zu messen ?

Wir verwenden Funktionspunkte bei meinem neuen Job. Ich habe von Funktionspunkten gehört, aber noch keine Ausbildung oder Erfahrung gehabt ... aber ich habe nicht viel Vertrauen in Dinge, die nicht kurz erklärt werden können.

Persönlich habe ich nie eine explizite Antwort auf die Frage "Was ist ein Funktionspunkt?" Gefunden. Ohne solche zögere ich WIRKLICH über eine Schätzmethode, die behauptet, irgendetwas mit Funktionspunkten zu tun.

Der wichtigste Teil einer seriösen Software-Schätzmethode ist die "regelmäßige Neukalibrierung auf die tatsächlichen Werte". Dies bedeutet, dass Sie Ihre Schätzung vornehmen, sie aufschreiben und nach Abschluss des Projekts Ihre tatsächlichen Ergebnisse mit Ihrer Schätzung vergleichen und Überarbeiten Sie gegebenenfalls Ihren Schätzprozess. Darin enthalten ist der Vergleich Ihrer EINGÄNGE mit Ihrem Schätzprozess mit den IST-EINGÄNGEN.

Wenn Sie beispielsweise die Quellcodezeilen (SLOC) schätzen und von dort aus fortfahren, müssen Sie Ihren tatsächlich gelieferten SLOC mit Ihrem geschätzten SLOC vergleichen und feststellen, ob, wie weit und wo und warum Sie vom Weg abgekommen sind. Ein Schätzer, der die Arbeitsstunden bei einer genauen und präzisen SLOC-Schätzung in perfekt vorhersagt, wird Ihnen nichts nützen, wenn Ihre SLOC-Schätzungen wertlos sind. Müll rein, Müll raus. (Gleiches gilt für Funktionspunkte.)

Wenn Ihre SLOC- (oder Funktionspunkt-) Istwerte mit Ihren ursprünglichen Schätzungen übereinstimmen, können Sie Ihre Kosten-Istwerte mit Ihren geschätzten Kosten vergleichen und Ihre Schätzerparameter anpassen, um Ihre Ergebnisse zu verbessern. Die General Dynamics / Fort Worth Division führte diese Übung Anfang der 1980er Jahre im Detail für die Entwicklung von F-16C / D-Software durch und setzte dann mehrere Jahre lang routinemäßig das Unternehmensergebnis auf diese Schätzungen. GD / FW war eine ganze Weile GDs Cash Cow und hielt den Rest der Firma über Wasser, also müssen sie etwas richtig gemacht haben.

Und beachten Sie, dass Anforderungen und Feature Creep DER FEIND der Software-Schätzung sind.

(Dies ist eine spätere Bearbeitung.) Bernds letzter Punkt verdient eine Antwort. Er fragt, was bei Projekten zu tun ist, die früh eingehen, und verbringt nicht alle zugewiesenen Arbeitsstunden.

Dies ist ebenso ein Schätzfehler wie die (weitaus häufiger auftretenden) Zeitplanüberschreitungen. Tatsache ist: Wenn alle Ihre Projekte ihren Zeitplan überschreiten, machen Ihre geschätzten Leute ihre Arbeit nicht.

Wenn Ihre geschätzten Leute alles richtig machen und Ihre Manager alles richtig machen, werden einige Projekte früh eingehen, zusammen mit denen, die spät kommen. Schätzungen sind Wahrscheinlichkeiten. Schattieren Sie Ihren Schätzer, um Zeitplanüberschreitungen zu vermeiden, und Sie erhöhen DEFINITION die Wahrscheinlichkeit von Zeitplanüberschreitungen. Wenn Ihr Management Pläne und Schätzungen mit Null Möglichkeit Underrun verlangt, dann werden Sie Pläne zu liefern , die WILL Überschreitung sein, die garantiert, und dann werden Sie beginnen Anforderungen für Todesmärsche zu sehen, und dann beginnen Sie Rücktritte zu sehen, und Ihre Überschreitungen erhalten viel, viel schlimmer, wenn Sie versuchen, Ersatz zu rekrutieren (und es wird bekannt, dass Ihr Unternehmen ein Sweatshop ist).

Wenn Sie sich mit dem Umfang eines Projekts befassen, ist es im Allgemeinen besser, ein Maß für Funktionspunkte anstelle von Codezeilen zu verwenden . Da Softwareprojekte mehr als Millionen von LOC haben können (einschließlich LOC in Bibliotheken), wird die Anzahl relativ bedeutungslos.

Wie messen Sie den LOC, wenn Sie Funktionen aus Bibliotheken aufrufen? Schließen Sie LOC aus Bibliotheken ein? Wenn Sie kein LOC aus Bibliotheken einschließen, schreibt Ihr Chef dann nicht genug LOC?

Im Allgemeinen ist es besser zu sagen "Ich habe die XXX-Funktionalität abgeschlossen" als "Ich habe XXX-Codezeilen geschrieben".

Aber ich schlage vor, Sie sehen selbst. Ist es für Sie einfacher, Funktionspunkte oder Codezeilen zu schätzen ? Stecken Sie diese Ergebnisse in das COCOMO II-Modell und sehen Sie, welches einfacher zu verwenden ist.

Außerdem enthält dieses COCOMO II-Handbuch eine detaillierte Beschreibung der Funktionspunkte und des LOC auf Seite 11. Hoffentlich reicht dies aus, um fortzufahren.

Ich arbeite in einer Organisation, in der wir Funktionspunkte für die Berechnung von Festpreisprojekten eingeführt haben, dh Kunden, und wir zählen anhand von Spezifikationen, stimmen der Zählung zu und multiplizieren dann den #FP mit einem FP-Preis, um den Projektpreis zu bestimmen. All dies in einem Umfeld mit einem zweistelligen Projektumsatz von einer Million Millionen Euro pro Jahr. Es ist beabsichtigt, Unklarheiten und Verhandlungen aus der Preisermittlung zu entfernen, die eine ständige Ursache für Reibung war.

Wir haben eine Erstkalibrierung durchgeführt und dabei etwa zwei Jahre Projektgeschichte im Wert von zweistelligen Millionen Euro ausgewertet.

Wir sehen deutlich, dass #FP- und Projektkosten sehr indirekt korrelieren. Abweichungen von +/- 50% sind vernünftigerweise möglich. Wir sehen jedoch (wir erwarten oder besser: wir hoffen), dass auf lange Sicht die Anzahl der Funktionspunkte und die Projektkosten konvergieren.

Wir sind gerade dabei, dies auf die Organisation und Erfahrung auszudehnen (aus Sicht der Lieferanten):

• Diskussionen über die Anwendung von FP-Zählregeln. Hierfür gibt es Standards, die jedoch vernachlässigt werden, wenn man nicht direkt über Preise streiten kann.

• Kunden haben den Eindruck, dass die Preise trotz der Anstrengungen, die wir unternommen haben und die wir für die Kalibrierung und Überprüfung der Kalibrierung aufgewendet haben, gestiegen sind. Der vermutete Grund ist, dass dieses Verfahren die Kosten brutal klar macht und es nicht möglich ist, Kosten in einigen "Nicht fragen" - oder strategischen Projekten zu verbergen, zu verschieben oder zu decken.

• Sie müssen Projekte bearbeiten, die ihre Kosten nicht decken (50% Unterschreitung ...).

Sie scheinen nur geringfügig nützlich zu sein, um die Komplexität eines bestimmten Systems / einer bestimmten Komponente auszudrücken, und können Managern / Teamleitern bei der Aufteilungsarbeit helfen, aber sie sind nicht wirklich nützlicher als alle anderen synthetischen / willkürlichen Metriken (SLOC, Cyclomatic Complexity usw.) Das heißt, sie geben möglicherweise einen Hinweis auf den relativen Aufwand, der für bestimmte Teile eines Systems erforderlich ist, aber es gibt keine Möglichkeit, sie konkreten Schätzungen zuzuordnen.

Durch die Verwendung von Funktionspunkten zugunsten von Codezeilen sollen mehrere zusätzliche Probleme behoben werden:

• Das Risiko einer "Inflation" der erstellten Codezeilen und damit einer Verringerung des Werts des Messsystems, wenn Entwickler Anreize erhalten, produktiver zu sein. FP-Befürworter bezeichnen dies als Messung der Größe der Lösung anstelle der Größe des Problems.

• LOC-Maßnahmen (Lines of Code) belohnen Sprachen auf niedriger Ebene, da mehr Codezeilen erforderlich sind, um einer Sprache auf höherer Ebene eine ähnliche Funktionalität zu bieten. C. Jones bietet in seiner Arbeit eine Methode an, dies zu korrigieren.

• LOC-Maßnahmen sind in frühen Projektphasen nicht sinnvoll, in denen die Schätzung der Anzahl der zu liefernden Codezeilen eine Herausforderung darstellt. Funktionspunkte können jedoch aus Anforderungen abgeleitet werden und sind daher bei Methoden wie der Schätzung durch Proxy nützlich.

Weglaufen.

Nach meiner Erfahrung sind die Unternehmen, die Funktionspunkte verwenden, nur einen Schritt über dem reinen Wahnsinn.