Größenbestimmung in vielen Metriken

[Kapern Jones]

Größe bleibt im Softwarebereich schwierig und mehrdeutig.

Ab 2015 es scheint zu geben 23 übliche Größenkennzahlen, mit wenigen Konvertierungsregeln darunter.
Soweit ich weiß, gibt es in keiner anderen Branche so viele Metriken für denselben Wert. Software hat auch 2,700 Programmiersprachen, auch aus unbekannten gründen. Meiner Ansicht nach bedeuten all diese Sprachen und Metriken, dass keine vollständig zufriedenstellend ist, sonst hätten wir nicht so viele.
Unten eingefügt sind die Metriken, die ich kenne. Wenn jemand andere kennt, lass es mich wissen oder poste es in diesem Blog.

1. IFPUG 4.3
2. Automatisierter Code basiert
3. Automatisiert UML-basiert
4. Nach hinten losgegangene Funktionspunkte
5. KOSMISCHE Funktionspunkte
6. Schnelle Funktionspunkte
7. Feature-Punkte
8. FiSMA-Funktionspunkte
9. Volle Funktionspunkte
10. Funktionspunkte Licht
11. IntegraNova-Modelle
12. Funktionspunkte markieren II
13. Nesma-Funktionspunkte
14. RICE-Objekte
15. SCCQI-Funktionspunkte
16. Einfache Funktionspunkte
17. SNAP nicht funktionale Metriken
18. SRM-Musterabgleich
19. Story-Punkte
20. Nicht angepasste Funktionspunkte
21. Anwendungsfallpunkte
22. Logische Codeanweisungen
23. Physische LOC (leer, Kommentare)

Vielen Dank,
Kapern Jones
SRM-Größenmetriken

[Ian Alyss]

Liebe Kapern,

Schöne Liste! Gut, dass Sie unterscheiden “Automatisierter Code”, “Automatisierte UML” und “Fehlzündung”, da sie wesentlich anders sind. Es gibt verschiedene Geschmacksrichtungen von “Schnell”, welches meinst du? Wenn Sie nicht die Fast Function Points von Gartner meinen, dann sollten Sie FFPAi hinzufügen (Das ist die Kombination ihrer traditionellen FFPA, Konfigurationspunkte und IBRA-Punkte). Ich denke, die Full Function Points sind nicht mehr gültig, da es durch COSMIC ersetzt wurde. ich weiß nur IntegraNova als Entwicklungsumgebung, aber nicht als Größenmaß. In diesem Fall sollten Sie auch hinzufügen Agile Netzwerkgröße von OutSystems (JAHRE) und dergleichen.

Grüße aus Irland

[Frank Vogelezang]

Liebe Kapern,

Ich sehe definitiv eine Verbesserung in der Liste gegenüber einer ähnlichen Liste, in der Sie veröffentlicht haben 2008. Siehe meinen persönlichen Blog “Der Preis der IT” über das. Du erwähnst es nur Nesma-Funktionspunkte in einer Zeile. Ich vermute du meinst die Gemäß ISO/IEC 24570 Standard zur detaillierten Zählung der Funktionspunkte. Aber wussten Sie, dass Nesma auch zwei Methoden zum schnellen Zählen hat?:

• Indikative FPA-Methode für ROM-Schätzungen
• High-Level-Zählung für eine schnelle, aber immer noch sehr genaue Zählung

Diese beiden Methoden, die auch in der Norm beschrieben sind, sind sehr hilfreich, wenn Sie schnell eine Größenschätzung benötigen. Sehen diese Seite für eine kurze Einführung.

Nesma hat auch eine Reihe von Methoden, die für bestimmte Umgebungen/Zwecke gedacht sind:

• FPA zur Softwareverbesserung
• FPA angewendet auf Data Warehousing
• Functional Sizing in einer SOA-basierten Umgebung (nur auf niederländisch)

Vielleicht können Sie in der nächsten Version Ihrer Liste einige zusätzliche Zeilen für Nesma-basierte Methoden reservieren.

Und, Vielleicht bin ich selbst schuld, dass du es aufgenommen hast SCCQI, aber soweit ich weiß, gibt es nur eine Person auf der Welt, die diese Methode anwendet.

Grüße, Frank

[Luigi Lavazza]

Liebe Kapern,
Ihre Liste könnte tatsächlich in zwei Listen aufgeteilt werden: eine mit den verschiedenen Größenmaßen, und die andere enthält die Prozesse, die für die Maßnahmen in der ersten Liste vorgeschlagen wurden.
Tatsächlich, Die von Frank erwähnten indikativen und hochrangigen Zählungen wurden nicht vorgeschlagen, um ein weiteres Größenmaß zu definieren, sondern um den Prozess der Messung bereits vorhandener Größenmetriken zu vereinfachen (nämlich, Nesma-Funktionspunkte). Es gibt mehrere solcher Vorschläge, einschließlich Früh&schnelle Funktionspunkte, die Tichenor-Methode, die Methode basiert auf ISBSG-Durchschnittsgewichten, etc. Persönlich, Ich würde dies nicht als neue Maßnahmen betrachten, sondern als neue vereinfachte Prozesse, um FPA-Größenmessungen schneller und früher zu erreichen (z.B., wenn die funktionalen Spezifikationen der zu entwickelnden Software noch nicht vollständig vorliegen, wodurch die Anwendung von Standardmessverfahren unmöglich gemacht wird).
Ähnlich, Einige UML-basierte Maße sind nur Vorschläge für Prozesse, um die üblichen Maße abzuleiten (IFPUG, COSMIC, etc.) aus funktionalen Spezifikationen, die über UML-Diagramme bereitgestellt werden.

Zur ersten Liste, könnten Sie möglicherweise hinzufügen Klasse Punkte, obwohl sie von Forschern vorgeschlagen wurden, aber –so weit ich weiß– nie in der Praxis angewendet.

Mit freundlichen Grüße
Luigi

[Kapern Jones]

Luigi,

Danke für deine Kommentare. Entschuldigung für die Verzögerung – Ich bin auf einer Reise und war reisebedingt offline.

Ich habe eine zum Patent angemeldete Größenmethode, die auf Musterabgleich basiert. Es kann vor den Anforderungen verwendet werden und benötigt nur wenige Minuten, um jede Anwendung zu dimensionieren. Wir haben es für Projekte im Bereich von ca. verwendet 1 Funktion zeigen auf 300,000..

Wir beginnen damit, das Projekt in unsere formale Taxonomie aufzunehmen. Dann wählen wir Projekte mit demselben Taxonomiemuster aus unserer Wissensdatenbank von about 25,000 Projekte. Zufällig sind Projekte mit demselben Taxonomiemuster in Funktionspunkten ungefähr gleich groß, aber nicht in Codezeilen. Aber wir können auch Codezeilen verarbeiten für 79 Sprachen plus Kombinationen wie Java und SQL.

Die gleiche Mustervergleichsmethode wird von anderen Branchen wie z Zilow und Trulia zum Vergleich von Immobilien und der Kelley Blaues Buch zum Vergleich der Gebrauchtwagenpreise.

Unsere Methode ist ein Standardmerkmal unserer Software-Risiko-Master (SRM) Werkzeug, was auch die Größe vorhersagt 23 Metriken gleichzeitig. Wir bieten Kunden in vielen Ländern Größen-, Qualitäts- und Kostenschätzungen als Dienstleistung an: China, Kanada, Peru, Israel, Japan, etc.

Ich kann keine Klassenpunkte hinzufügen, da keiner meiner Kunden die Metrik verwendet und ich keine Daten habe.

Grüße,
Kapern Jones

[Kapern Jones]

Luigi,

Unsere Größenbestimmungsmethode basiert auf einer formalen Taxonomie. Es ist auch eine Standardfunktion unseres Software Risk Master (SRM) Schätzungstool.

Wir platzieren zu dimensionierende Projekte in unserer proprietären Taxonomie und extrahieren dann ähnliche Projekte aus unserer Wissensdatenbank und aggregieren ihre Größe. Zufällig sind Projekte mit denselben Taxonomiemustern ähnlich groß.

Unsere Methode erfordert keinen Zugriff auf Anforderungen oder interne Informationen.

Dadurch können wir jedes Softwareprojekt dimensionieren, und zwar sehr schnell.

Hier sind 150 Beispiele, die ich zusammengestellt habe, um nur zu veranschaulichen, dass jedes Softwareprojekt mit unserer zum Patent angemeldeten Methode dimensioniert werden kann.
>>150 Examples

Natürlich ist die Dimensionierung an sich nur ein Teil dessen, was Kunden brauchen. Ebenfalls beigefügt sind Beispielprojektergebnisse unter Verwendung von Potenzen von 10 von 10 zu 100,000 Funktionspunkte. Die Stichproben sind keine vollständigen SRM-Schätzungen, sondern nur interessante Auszüge.
>>Powers of 10

Grüße,
Kapern Jones

[Wim Viser]

Liebe Kapern,

Ich stimme Luigi zu, dass Ihre erste Liste mehrere Elemente enthält, die keine unterschiedlichen Metriken sind, sondern dieselben Metriken mit nur unterschiedlichen Zähl- / Messverfahren. Leider reagieren Sie nicht auf die Kommentare von Frank und Luigi. Meiner Meinung nach enthält Ihre Liste dann weniger 23 Metriken und ich bin sehr gespannt auf Ihre Meinung zu ihren Kommentaren.

Mit freundlichen Grüßen

Wim Viser

[Marder Eisma]

Liebe Kapern,

Ich sehe, dass es viele Methoden dafür gibt (Produkt) Dimensionierung. Ich verwende die Produktgröße hauptsächlich zum Schätzen (neue Projekte und neue Releases für Anwendungswartungszwecke). Die geschätzte Produktgröße liegt meistens zwischen 300 FP und 5.000 FP mit viel Unsicherheit.

Die Produktgrößenschätzung wird meist für Aufwandsschätzungen verwendet / Teamgröße), Dauer und Mängel.

Die Projektschätzungen basieren hauptsächlich auf Geschäftsanforderungen, so wird auch die Produktgröße als Wahrscheinlichkeit geschätzt (mit einer Reichweite).

Meine Frage wäre:
Gibt es auch ein Modell / Methode zur Bewertung, um zu Beginn eines Projekts die relevanteste Methode für die Produktdimensionierung auszuwählen / Freisetzung, wissend, dass eine Genauigkeit von +/- 10% ist akzeptabel.

Marder Eisma

[Autor]

Beiträge