Die aktuell besten Metriken in Bezug auf Anforderungen, Design und Architektur

Also stellte mir mein Chef eine „Recherche- und Find-Frage“:

  • Gibt es irgendwelche (absolut irgendwelche, egal wie dümmsten, aber irgendwelche) Metriken für das Anforderungsmanagement? Z.B. Vollständigkeit, Konsistenz und Produktivität der Anforderungen (was am schwierigsten festzunageln ist, dh was mit Produktivität gemeint ist).

Ähnliche Frage in Bezug auf Metriken auf Design- und Architekturebene. Dh, existieren welche und was sind sie, wenn sie existieren.

Es ist im Moment etwas verschwommen, aber ich wollte wissen, welche Metriken Sie in diesen Phasen häufig verwendet haben (wenn überhaupt) und was Sie für sinnvoll befunden haben. Die Vorstellung ist, dass die meisten Unternehmen proprietäre Metriken entwickeln können (und tun), um Dinge zu messen, die sich auf die Anforderungs-/Design-/Architekturphasen beziehen, aber gibt es irgendwelche „allgemein anwendbaren“ Metriken?

Hinweis : Ich suche nicht nach codebezogenen Metriken wie zyklomatische Komplexität oder Fehler/100 LOC oder Funktionspunkte

Ich bin mir des Produktrückstands in der agilen Community bewusst, zusammen mit Release-Burndown. Release-Burndown-Diagramme geben Ihnen in der Regel eine gute Vorstellung von den Dingen, aber sie funktionieren nicht so gut in einer Umgebung ohne Story-Point-Schätzung, IMO. Sie sind gute Proxys, um die oben genannten Anforderungen hinsichtlich Konsistenz, Vollständigkeit und Produktivität zu messen, sind sich aber nicht sicher, wie gut sie dies erfüllen können.

Ich bin mir bewusst, dass es sich um ein schwieriges Problem handelt. Ich suche keine Lösung, sondern nur Meinungen / Standpunkte dazu, was Sie in dieser Hinsicht verwendet oder gesehen / gehört haben. Referenzen zu Forschungsarbeiten sind auch mehr als willkommen :)

Kein Duplikat, aber ähnlich wie What are good metrics for a SRS?
Jep! Hatte das angeschaut. Die meisten Texte sagen, dass Sie solche Metriken „verfolgen“ sollten, meine Frage ist, „welche Metriken“ in der Lage waren, diese Ideen konkret zu quantifizieren, und welche Erfahrungen mit ihrer Verwendung gemacht wurden. Z.B. Es ist gut, wenn Anforderungen nicht mehrdeutig sind, aber gibt es eine (egal wie obskure, weniger verwendete, dumme) Metrik, die hilft, Mehrdeutigkeit zu quantifizieren?
Die beste und einzige todsichere Methode, die ich kenne, um sicherzustellen, dass eine Anforderung eindeutig ist, besteht darin, die Verifizierungsmethodik zu dokumentieren. Nicht nur die Methode (z. B. Analyse, Text, Inspektion usw.), sondern eine detaillierte Beschreibung dessen, was Sie genau tun werden, und objektive Pass/Fail-Kriterien. Damit ist die Bedeutung der Anforderung klar. Sobald das System die Verifizierungsmethodik durchlaufen und bestanden hat, bedeutet dies, die Anforderung zu erfüllen.

Antworten (3)

In Bezug auf Metriken für eine Reihe von Anforderungen:

  • Die Anzahl der Anforderungen ist ein guter Hinweis auf die Systemkomplexität (es mag zunächst albern erscheinen, da nicht alle Anforderungen die gleiche "Größe" haben, aber insgesamt scheint es nicht schlechter zu funktionieren als das Zählen von Codezeilen für die Softwarekomplexität).
  • Anzahl der TBX sowohl absolut als auch Prozentsatz der Anforderungen, die noch nicht abgeschlossen sind. Es kann auch hilfreich sein, die verschiedenen Geschmacksrichtungen zu verfolgen, da ein TBD (bestimmt) weniger ausgereift ist als ein TBR (esolved/reviewed) oder ein TBS (geliefert).
  • Anzahl von Anforderungen mit Verifizierungsmethoden und -methoden , da Anforderungen, über deren Verifizierung niemand nachgedacht hat, wahrscheinlich noch nicht so gut sind
  • Anzahl der Anforderungen, die in untergeordnete Spezifikationen abgeflossen sind, oder ähnlich die Anzahl der kinderlosen Anforderungen in den Spezifikationen der obersten Ebene oder der Waisen in den Spezifikationen der niedrigeren Ebene

Wenn Sie über die Messung der Effizienz Ihrer Anforderungsmanagementprozesse sprechen:

  • Stunden, die pro freigegebener Änderungsanforderung berechnet werden
  • Verifizierungs-Burndown-Plan vs. tatsächlicher Fortschritt
  • Prozentsatz der Spezifikationen im Spezifikationsbaum, die freigegeben sind und unter Konfigurationsmanagement stehen
Schönes Set! Ich hatte vorgeschlagen, die Anzahl der ursprünglich erfassten Anforderungen zu zählen, die in den endgültigen Ergebnissen enthalten sind, und so weiter. Aber die Frage war "gibt es irgendetwas in der Literatur oder sollten wir uns etwas einfallen lassen" :) Und das ist es, was mich am Kopf kratzen lässt (und hoffentlich auch der Community :)
Wenn es eine Menge Literatur zu Anforderungsmetriken gibt, weiß ich nicht, ob dies durchaus möglich ist. Aber die meisten großen Unternehmen, die ich kenne, haben ihr institutionelles Wissen erfasst und in interne Prozesse umgewandelt. Das heißt, ich wäre nicht überrascht, wenn Sie nichts in der Literatur finden und entscheiden würden, dass es am besten wäre, wenn Sie über Ihre eigenen nachdenken und sie für die zukünftige Verwendung festhalten, wie es mehrere andere Unternehmen getan haben.
Absolut! Das ist "genau" das, was ich meinem Chef gesagt habe :)

Obwohl es sich nicht ausschließlich um Requirements Engineering oder Design- und Architekturphasen handelt, kann die Effektivität der Fehlerbeseitigung verwendet werden, um herauszufinden, wie effektiv Ihre Requirements Engineering- und Designaktivitäten sowie alle anderen Aktivitäten während des gesamten Lebenszyklus sind.

Die Idee ist, dass Sie eine Tabelle erstellen, die zeigt, wo Fehler gefunden wurden, wo sie behoben wurden und woher sie kamen. Anhand dieser Informationen können Sie herausfinden, wie viele Anforderungsmängel in Anforderungen gefunden wurden, im Design gefunden wurden oder bis zum Einsatz im Feld durchgeschlüpft sind. Sie können dies pro Iteration (da sich jede Iteration mit dem Requirements Engineering bis hin zum Deployment befasst) sowie pro Projekt nachverfolgen. Sie müssen jedoch einige Iterationen durchführen, um ausreichende Informationen über die Wirksamkeit Ihrer Praktiken in jeder Phase zu erhalten und Korrekturen vorzunehmen.

Andere Messungen und Metriken beziehen sich auf Änderungsraten von Anforderungen, wie beispielsweise hinzugefügte, entfernte und geänderte Anforderungen. Auch Anforderungen bezüglich Implementierungszeit oder Testabdeckung können geeignet sein. Ich denke jedoch, dass die Antwort von Adam Wuerl dies ziemlich gut beschreibt .

Jep! Das machen wir derzeit sehr gut! Das sind genau (und wahrscheinlich nur) Arten von Metriken, die wir verfolgen ... Ich bin mehr daran interessiert, andere, direktere herauszufinden, wie ich im OP erwähnt habe
@Nupul Die einzige andere Sache, die ich interessant gefunden habe, wäre die Korrelation der Kundenzufriedenheit mit den Anforderungen. Wahrscheinlich gibt es einen Zusammenhang zwischen „wie gut die Anforderungen sind“ und „wie zufrieden die Kunden und Anwender mit der Software sind“. Leider konnte ich keine aussagekräftige Forschung in dieser Richtung finden. Vielleicht könnte ein Blick auf die Forschung und Studien zu TQM etwas in diese Richtung liefern, ich bin tatsächlich ein wenig überrascht über den Mangel an leicht zu findenden und/oder bekannten Arbeiten zu nachgelagerten Aktivitäten und Softwarequalität.
Stimme voll und ganz der Schwierigkeit zu, sie zu finden...

Das Kostenschätzungsmodell von Revic 9.2 schätzt auch die Anforderungen und Überprüfungsphasen. Beachten Sie jedoch, dass es auf Codezeilen basiert, es handelt sich also um eine ungefähre Schätzung. Außerdem ist es ein Modell der US Air Force, also für militärische Projekte gedacht.

Die aktuell besten Metriken in Bezug auf Anforderungen, Design und Architektur
AntwortenHierDatenschutz-Bestimmungen1y, 0v