Einführung

Die Softwareindustrie ist eine der größten und erfolgreichsten Branchen in der Geschichte. Softwareanwendungen gehören jedoch zu den teuersten und fehleranfälligsten hergestellten Objekten in der Geschichte. Software benötigt genaue Schätzungen von Zeitplänen, Kosten, und Qualität. Diese sind schwer zu erreichen, wenn die grundlegenden Metriken falsch sind und die Realität verzerren. Ab 2014 Die Softwareindustrie arbeitet unter einer Vielzahl von nicht standardmäßigen und sehr ungenauen Messwerten und Metriken, die durch sehr schlampige Messpraktiken ergänzt werden. Die Fehler bei Softwaremaßnahmen und -metriken führen zu Fehlern bei Softwareschätzungen. Im Folgenden finden Sie Beschreibungen der aus meiner Sicht problematischeren Themen zu Softwaremetriken in alphabetischer Reihenfolge. Zwei von ihnen sind weit verbreitet und problematisch:

• Die Kosten pro Defekt beeinträchtigen die Qualität
• Codezeilen bestrafen Hochsprachen und machen Anforderungen und Design unsichtbar

Problematische Metriken

Kosten pro Defekt Metriken beeinträchtigen die Qualität und lassen die fehlerhafteste Software am billigsten aussehen. Es gibt keine ISO- oder andere Standards zur Berechnung der Kosten pro Fehler. Die Kosten pro Fehler messen nicht den wirtschaftlichen Wert der Softwarequalität. Die urbane Legende, dass es kostet 100 Mal so viel, um Fehler nach der Freigabe zu beheben wie frühe Fehler, ist nicht wahr und basiert auf dem Ignorieren der Fixkosten. Aufgrund fester Kosten für das Schreiben und Ausführen von Testfällen, Die Kosten pro Defekt steigen stetig, da immer weniger Defekte gefunden werden. Dies wird durch eine Standardregel der Fertigungsökonomie verursacht: „wenn ein Prozess einen hohen Prozentsatz an Fixkosten hat und die produzierten Einheiten reduziert werden, Die Kosten pro Einheit werden steigen.Dies erklärt, warum die Kosten pro Fehler im Laufe der Zeit zu steigen scheinen, obwohl die tatsächlichen Kosten für die Fehlerreparatur unverändert sind und sich nicht sehr ändern. Es gibt natürlich sehr störende Mängel, die teuer und zeitaufwändig sind, aber diese sind vergleichsweise selten.

Fehlerdichte Metriken messen die Anzahl der für Clients freigesetzten Fehler. Es gibt keine ISO oder andere Standards zur Berechnung der Defektdichte. Eine Methode zählt nur freigegebene Codefehler. Eine vollständigere Methode umfasst Fehler, die auf Anforderungen und Design zurückzuführen sind, sowie Codefehler, und enthält auch "schlechte Korrekturen" oder Fehler bei der Reparatur von Fehlern. Es kann mehr als eine geben 300% Variation zwischen dem Zählen nur von Codefehlern und dem Zählen von Fehlern aus allen Quellen.

Funktionspunktmetriken wurden von IBM circa erfunden 1975 und in den öffentlichen Bereich circa platziert 1978. Funktionspunktmetriken messen die wirtschaftliche Produktivität mit beiden “Arbeitsstunden pro Funktionspunkt" und "Funktionspunkte pro Monat”. Sie sind auch nützlich, um Qualitätsdaten wie „Fehler pro Funktionspunkt“ zu normalisieren.. Es gibt jedoch zahlreiche Funktionspunktvariationen, die alle unterschiedliche Ergebnisse liefern: Automatisch, nach hinten abgefeuert, COSMIC, Schnell, Fisma, IFPUG, Mark II, NESMA, Unangepasst, etc. Es gibt ISO-Standards für COSMIC, Fisma, IFPUG, Mark II und NESMA. Trotz ISO-Standards produzieren alle fünf unterschiedliche Zählungen. Anhänger jeder Funktionspunktvariante behaupten "Genauigkeit" als Tugend, aber es gibt kein Cäsiumatom oder einen unabhängigen Weg, um die Genauigkeit festzustellen, so dass diese Behauptungen falsch sind. Beispielsweise erzeugen COSMIC-Funktionspunkte für viele Anwendungen höhere Zählungen als IFPUG-Funktionspunkte, dies bedeutet jedoch keine „Genauigkeit“, da es keinen objektiven Weg gibt, die Genauigkeit zu ermitteln.

Ziel- / Fragenmetriken (GQM) wurden von Dr.. Victor Basili von der University of Maryland. Das Konzept ist ansprechend. Die Idee ist, eine Art konkretes Ziel anzugeben, und dann denken Sie an Fragen, die beantwortet werden müssen, um das Ziel zu erreichen. Dies ist ein gutes Konzept für alle Wissenschaft und Technik und nicht nur für Software. jedoch, da jedes Unternehmen und Projekt dazu neigt, eindeutige Ziele zu spezifizieren GQM-Methode eignet sich weder für parametrische Schätzwerkzeuge noch für das Benchmarking der Datenerfassung. Es wäre nicht schwierig, GQM mit Funktionspunktmetriken und anderen effektiven Softwaremetriken wie der Effizienz der Fehlerbeseitigung zu verschmelzen. Zum Beispiel könnten mehrere nützliche Ziele sein: „Wie können wir Fehlerpotentiale von weniger als erreichen? 1.0 pro Funktionspunkt?" oder "Wie können wir Produktivitätsraten von erreichen? 100 Funktionspunkte pro Monat?"Ein weiteres gutes Ziel, das eigentlich ein Ziel für jedes Unternehmen und jedes Softwareprojekt auf der Welt sein sollte, wäre"Wie können wir mehr erreichen als 99% in der Fehlerbeseitigungseffizienz?”

Zeilen von Code (ORT) Metriken bestrafen Hochsprachen und lassen Niedrigsprachen besser aussehen als sie sind. LOC-Metriken machen auch Anforderungen und Design unsichtbar. Es gibt keine ISO- oder andere Standards zum Zählen von LOC-Metriken. Etwa die Hälfte der Artikel und Zeitschriftenartikel verwendet physisches LOC und die Hälfte logisches LOC. Der Unterschied zwischen der Anzahl der physischen und logischen LOCs kann oben liegen 500%. LOC-Metriken machen Anforderungen und Design unsichtbar und ignorieren auch Anforderungen und Designfehler, welche Anzahl Codefehler übersteigt. Obwohl es Benchmarks gibt, die auf LOC basieren, Die intrinsischen Fehler von LOC-Metriken machen sie unzuverlässig. Aufgrund fehlender Standards für die Zählung des LOC, Benchmarks von verschiedenen Anbietern für dieselben Anwendungen können sehr unterschiedliche Ergebnisse enthalten.

Story Point Metriken werden häufig für agile Projekte mit „User Stories“ verwendet. Story-Punkte haben keine ISO-Norm zum Zählen oder eine andere Norm. Sie sind sehr vieldeutig und können um so viel wie variieren 400% von Unternehmen zu Unternehmen und von Projekt zu Projekt. Es gibt nur wenige nützliche Benchmarks, die Story Points verwenden. Offensichtlich können Story Points nicht für Projekte verwendet werden, in denen User Storys nicht verwendet werden. Daher sind sie für Vergleiche mit anderen Entwurfsmethoden wertlos.

Technische Schulden ist eine neue Metrik und verbreitet sich schnell. Es ist eine brillante Metapher, die von Ward Cunningham entwickelt wurde. Das Konzept von "Technische Schulden”Ist, dass Themen, die während der Entwicklung im Interesse der Zeitplangeschwindigkeit verschoben wurden, nach der Veröffentlichung mehr kosten, als sie anfänglich gekostet hätten. Es gibt jedoch keine ISO-Standards für technische Schulden und das Konzept ist sehr vieldeutig. Es kann um mehr als variieren 500% von Unternehmen zu Unternehmen und von Projekt zu Projekt. Schlechter, Die technische Verschuldung umfasst nicht alle Kosten, die mit schlechter Qualität und Entwicklungsverknüpfungen verbunden sind. Technische Schulden lassen stornierte Projekte aus, Folgeschäden oder Schäden für Benutzer, und die Kosten für Rechtsstreitigkeiten wegen schlechter Qualität.

Anwendungsfallpunkte werden von Projekten mit Designs verwendet, die auf „Anwendungsfällen“ basieren und häufig den Rational Unified Process von IBM verwenden (RUP). Es gibt keine ISO-Standards für Anwendungsfälle. Anwendungsfallpunkte sind mehrdeutig und können um mehr als variieren 200% von Unternehmen zu Unternehmen und von Projekt zu Projekt. Offensichtlich sind Anwendungsfälle für die Messung von Projekten wertlos, bei denen keine Anwendungsfälle verwendet werden, Sie haben also nur sehr wenige Benchmark-Daten.

Softwareproduktivität definieren

Für mehr als 200 Jahre war die wirtschaftliche Standarddefinition der Produktivität, „Waren oder Dienstleistungen, die pro Arbeitseinheit oder Aufwand hergestellt werden.”Diese Definition wird in allen Branchen verwendet, war aber in der Softwareindustrie schwer zu verwenden. Bei Software besteht Unklarheit darüber, was unsere „Waren oder Dienstleistungen.”

Die älteste Einheit für Software "Waren" war eine "CodezeileOder LOC. In jüngerer Zeit wurden Software-Waren definiert als „Funktionspunkte”. Noch neuere Definitionen von Waren umfassen „Story-Punkte" und "Anwendungsfallpunkte”. Das Vor-und Nachteile von diesen Einheiten wurden in der Literatur weitgehend diskutiert.

Ein weiteres wichtiges Thema aus der Fertigungsökonomie hat einen großen Einfluss auf Softwareproduktivität das ist auch in noch nicht gut verstanden 2014: Fixkosten.

Ein Grundgesetz der Fertigungsökonomie, das für alle Branchen einschließlich Software gilt, ist das Folgende: „Wenn ein Entwicklungsprozess einen hohen Prozentsatz an Fixkosten hat, und es gibt einen Rückgang der Anzahl der produzierten Einheiten, Die Kosten pro Einheit werden steigen.”

Wenn ein "CodezeileWird als Fertigungseinheit ausgewählt und es wird von einer einfachen Sprache wie Assembler zu einer höheren Sprache wie Java gewechselt, Die Anzahl der entwickelten Einheiten wird sich verringern.

Die nicht codierten Aufgaben von Anforderungen und Design wirken jedoch wie Fixkosten. Daher steigen die Kosten pro Codezeile für Hochsprachen. Dies bedeutet, dass LOC keine gültige Metrik zur Messung der wirtschaftlichen Produktivität ist.

Für Software gibt es zwei Definitionen von Produktivität die den wirtschaftlichen Standardkonzepten entsprechen:

1. Produktion einer bestimmten Menge lieferbarer Einheiten für die niedrigste Anzahl von Arbeitsstunden.
2. Produktion der meisten lieferbaren Einheiten in einem Standardarbeitszeitraum wie einer Stunde, Monat, oder Jahr.

In der Definition 1 Die zu liefernden Waren sind konstant und die Arbeitszeiten sind variabel.

In der Definition 2 Die zu liefernde Ware ist variabel und die Arbeitszeiten sind konstant.

Softwarequalität definieren

Wie wir alle wissen, ist das Thema „QualitätIst in jeder Branche etwas mehrdeutig. Definitionen für Qualität können subjektive ästhetische Qualität sowie präzise quantitative Einheiten wie die Anzahl der Mängel und deren Schweregrad umfassen.

Im Laufe der Jahre hat Software eine Reihe von alternativen Definitionen für Qualität ausprobiert, die eigentlich nicht nützlich sind. Eine Definition für Softwarequalität war beispielsweise „Konformität mit den Anforderungen.”

Die Anforderungen selbst sind mit Fehlern oder Fehlern gefüllt, die ungefähr umfassen 20% der Gesamtfehler in Softwareanwendungen gefunden. Die Definition von Qualität als Konformität mit einer Hauptfehlerquelle ist Zirkelschluss und eindeutig ungültig. Wir müssen Anforderungsfehler in unsere Definition von Qualität einbeziehen.

Eine andere Definition für Qualität war „Gebrauchstauglichkeit.Diese Definition ist jedoch nicht eindeutig und kann nicht vorhergesagt werden, bevor die Software veröffentlicht wird, oder sogar gut nach der Freisetzung gemessen.

Eine andere Definition für Softwarequalität war eine Reihe von Wörtern, die mit „… ility“ enden, wie z. B. Zuverlässigkeit und Wartbarkeit. Wie lobenswert diese Attribute auch sein mögen, Sie sind alle mehrdeutig und schwer zu messen. Des Weiteren, Sie sind schwer vorherzusagen, bevor Anwendungen erstellt werden.

Eine effektive Definition für die Softwarequalität, die sowohl vor dem Erstellen von Anwendungen vorhergesagt als auch nach der Bereitstellung von Anwendungen gemessen werden kann, lautet: „Softwarequalität ist das Fehlen von Fehlern, die dazu führen würden, dass die Anwendung nicht mehr funktioniert, oder zu falschen Ergebnissen führen.”

Weil gelieferte Mängel die Zuverlässigkeit beeinträchtigen, Wartbarkeit, Benutzerfreundlichkeit, Gebrauchstauglichkeit, Konformität mit den Anforderungen, und auch die Kundenzufriedenheit Jede effektive Definition der Softwarequalität muss die zentrale Bedeutung der Erzielung eines geringen Volumens an gelieferten Fehlern erkennen. Softwarequalität ist ohne geringe Anzahl gelieferter Fehler nicht möglich, unabhängig davon, welche Definition verwendet wird.

 

Über den Autor:

Kapern Jones ist CTO von Namcook Analytics, Ein Unternehmen, das ein fortgeschrittenes Risiko aufbaut, Qualität, und Tools zur Kostenschätzung. Dieser Blogpost wurde ursprünglich im Namcook Analytics-Blog veröffentlicht.

Ein Blogbeitrag repräsentiert die persönliche Meinung des Autors
und muss nicht unbedingt mit den offiziellen Nesma-Richtlinien übereinstimmen.