IFPUG-News-Ankündigung
Jetzt hat IFPUG veröffentlicht Zitieren #3, Die Anwender der IFPUG-Methode haben nun offiziell grünes Licht erhalten, Methoden zur Größenschätzung zu verwenden, die früher im Lebenszyklus eines Softwareprojekts als zum Zeitpunkt eines abgeschlossenen funktionalen Designs verwendet werden können. Im Tipp #3 die Methoden High Level FPA (In Nesma oft als „globale FPA“ oder „geschätzte FPA“ bezeichnet) und Indikative FPA werden beschrieben. Sie sind in der Tat sehr hilfreiche Methoden, um die Größe einer Anwendung abzuschätzen (oder Projekt) und viele kommerzielle Organisationen und Regierungen weltweit verwenden diese Methoden seit vielen Jahren. Tatsächlich, In der Praxis ist die funktionale Dokumentation sehr selten vollständig und detailliert genug, um eine detaillierte FPA so früh im Lebenszyklus des Softwareprojekts durchzuführen, wie es für die Schätzung des Projekts erforderlich ist. Dies ist tatsächlich ein Argument vieler Projektmanager, FPA nicht zu verwenden, da sie fälschlicherweise davon ausgehen, dass eine FPA-Messung nur an einem vollständigen funktionalen Design durchgeführt werden kann, was zu spät im Projektlebenszyklus ist, um für sie zu Schätzungszwecken nützlich zu sein.
Vor allem, da sich die Branche von den traditionellen Entwicklungsmethoden zu den agileren Methoden bewegt, Funktionsdokumentation, die vollständig und detailliert genug ist, um eine detaillierte FPA durchzuführen, wird immer seltener, man hat also keine andere Wahl, als eine geschätzte Methode anzuwenden, um die funktionelle Größe messen/schätzen zu können.
Na sicher, Bei jeder Schätzung von irgendetwas … sollte man sich fragen, wie genau die Schätzung wäre und welche Unsicherheit durch die Schätzung eingeführt wird. Die gute Nachricht ist, dass Studien veröffentlicht wurden, in denen die Genauigkeit der High Level FPA-Methode und der Indicative-Methode im Vergleich zu einer detaillierten FPA untersucht wurde. In Sogeti Niederlande zum Beispiel, die Abteilung Dimensionierung, Abschätzen & Kontrolle (SEK) präsentiert a Papier auf dem Software Measurement European Forum in Rom (Italien), im Juni 2009, in dem die Genauigkeitsverlust und die Aufwandsersparnis über die Verwendung von hochrangigen FPA und indikativen FPA von 42 Projekte wurden im Vergleich zu detaillierten FPA-Messungen untersucht.
Obwohl die Nesma-Methode für diese Studie verwendet wurde, die Ergebnisse dieser Studie sollten auch mit der IFPUG-Methode vergleichbar sein, wie es gibt sehr geringe unterschiede zwischen den beiden Methoden in der heutigen Praxis.
Das Papier, einschließlich der Messdaten, ist verfügbar auf der Artikel Seite. Die wichtigsten Schlussfolgerungen der Studie sind in der folgenden Tabelle aufgeführt:
| Methode | Genauigkeit | Genauigkeitsverlust | Bemühung | Aufwand gewinnen |
|---|---|---|---|---|
| Durchschnittlich | Durchschnittlich | |||
| Detailliert | 100% | 100 normale Std | ||
| Hohes Level* | 98.5% | 1.5% | 67 normale Std | 33% |
| Indikativ | 83.5% | 16.5% | 18 normale Std | 82% |
* Die High Level FPA wird in der Nesma-Methode auch als „globale FPA“ oder „geschätzte FPA“ bezeichnet
Es stellt sich heraus, dass die Verwendung der High Level FPA-Methode im Durchschnitt nur zu Ergebnissen führt 1,5% Genauigkeitsverlust, was normalerweise zu Beginn des Softwareprojektlebenszyklus keine große Sache ist. Die indikative Methode ist im Durchschnitt etwas ungenauer, sondern da diese Methode sogar noch früher im Lebenszyklus des Softwareprojekts verwendet werden kann (wenn nur die Anzahl der logischen Dateien bekannt ist oder ermittelt werden kann), Diese Methode ist sehr nützlich, um eine frühe „grobe Größenordnung“ zu erstellen (Rom)’ Schätzung der erwarteten Funktionsgröße.
Die Spalte Aufwandsstunden zeigt normalisierte Stunden anstelle von echten Stunden. Dies bedeutet, dass die geschätzte Methode im Durchschnitt dauert 67% der Messzeit im Vergleich zu einer detaillierten FPA-Messung. Die indikative FPA-Methode dauert im Durchschnitt 18% des Aufwands einer detaillierten FPA-Messung.
Über die Autoren
Harold van Heeringen, Edwin van Gorp und Theo Prins sind Berater für Softwaremetriken / Softwarekosteningenieure für Sogeti Nederland B.V. Sie veröffentlichen regelmäßig auf internationalen Konferenzen über praktische Aspekte der Softwaremessung. Die meisten ihrer Artikel sind auf der zu finden Artikel Seite.
Wie viel Prozent Ihrer FP-Analysen verwenden die detaillierte Methode? Teilen Sie uns dies mit Forum.
Harald und Theo: Danke, dass du das gepostet hast.
Ich habe die leichte FPA-Methode in den letzten zehn Jahren aus mehreren Gründen verwendet:
– Frühe Schätzungen erfordern eine allgemeine Sicht auf die funktionale Größe. Eine detaillierte fp-Analyse würde zu der Annahme führen, dass es Genauigkeit gibt, wo es keine geben kann.
– Auch in einer Basisanalyse, meine Kunden können oft keinen detaillierten Überblick über die Implementierung einzelner Attribute geben. Fehlende Dokumentation, Mangel an Wissen, Mangel an irgendetwas…. die gründe sind vielfältig.
– In der Regel biete ich Festpreisangebote an, somit kosteneffizient sein, High-Level-Analyse ist die beste Wahl.
– Ich will das Publikum nicht langweilen. Kunden sind sehr zufrieden, wenn ich eine riesige SAP-Anwendung fertigstelle 2 Tage (“Wir dachten immer, es würde Wochen dauern, … Wie kann es sein, dass das Schätzen nur dauert 2 Tage….”). Und wollen wir nicht alle zufriedene Kunden??
Nur einmal fing ich fast an zu schwitzen: Ich hatte Mitarbeiter eines großen Telekommunikationsunternehmens in der Light-FPA-Analyse geschult. Wir hatten das Volumen der 12-monatigen Entwicklungsergebnisse der Organisation gezählt. Nach Meldung der fp-Ergebnisse, Das Management wagte weder mir noch seinen eigenen Mitarbeitern zu vertrauen, Wer weiß? Also flogen sie in eine andere Metrikfirma (sie fliegen sie immer von weit her ein, in der Hoffnung, dass es dadurch effektiver wird) um die gesamte Analyse mit der detaillierten IFPUG-Methode zu wiederholen.
Sie ahnen, was dann passiert ist, du nicht? Sie fanden weniger als 1% Abweichung zwischen unserer Lichtanalyse und ihrer detaillierten Analyse!
Ich denke, der angegebene Aufwandsgewinn ist eher konservativ und kann von Ihren Berichtsstandards abhängen. In ihrem Vergleich (2 Wochen vs 2 Tage) Eva zeigt einen Aufwandsgewinn von 80% für eine High-Level-Analyse. Meine Erfahrung ist ähnlich: eine High-Level-Analyse ist zumindest 4 mal schneller als eine detaillierte Analyse.
Auf der IT-Vertrauenskonferenz (Tokio, Oktober 2014), Japanische Forscher hielten eine Präsentation, die der Nesma High Level FPA-Methode zuschrieb, dass sie für das gesteigerte Interesse an der Verwendung von funktionaler Größenbestimmung in der japanischen Industrie verantwortlich sei. Ich versuche, die Präsentation zu bekommen, aber es gibt bereits ein kurzes Papier, auch über ISBSG slideshare: http://www.slideshare.net/ISBSG/matsumoto-towards-an-early-software-effort-estimation-based-on-the-nesma-method-estimated-fp
Ich war sehr überrascht zu hören, dass IFPUG FPA uTIP#3 „Early FPA“ angekündigt hat.. Über mehr als 10 Jahre NESMAs geschätzte Analyse’ (die mit der High-Level-Analyse identisch ist) ist in der niederländischen Metrik-Beratungsszene gängige Praxis.
Die Tabellen im Blog zeigen eindeutig, dass es nur einen geringen Größenunterschied zwischen detaillierter Analyse und geschätzter Analyse gibt. Daraus kann geschlossen werden, dass die Genauigkeit auf „hohem Niveau“ liegt’ Analyse ist fast so gut wie detaillierte Analyse, mit erheblichem Aufwandsgewinn.
Meiner Meinung nach liegt der wirkliche Vorteil in diesem „hohen Niveau“.’ FPA kann auf grobkörnigere Spezifikationen angewendet werden, also früher im Projekt. In meiner Praxis bedeutet dies, dass am Ende der Anforderungsanalyse schnell eine ziemlich genaue Größenschätzung und Projektschätzung geliefert werden kann (und vor dem Detaildesign). Ich bin sehr gespannt auf die „Konsequente Kostenschätzung“.’ von IFPUG.
Danke für diesen Beitrag; es ist ziemlich nützlich. Wir haben Quick FPA in vielen Situationen eingesetzt, und die Genauigkeit der Schätzung wird immer diskutiert. Diese Analyse würde sich als nützlich erweisen!