Produktivitätsmessung

In anderen Branchen als die Software-Industrie, Produktivitätsmessung ist eine normale Aktivität, die den Erfolg eines Unternehmens antreibt. Mal sehen, zum Beispiel ein Ein-Mann Malerei Unternehmen. Für einen Maler, es wäre logisch, seine Produktivität zu messen Aufwand Stunden pro Quadratmeter. Wahrscheinlich will er die Messung in einigen Kategorien unterscheiden,wie Werkzeuge verwendet (z.B.. Walze / Bürste / Spray / usw.) und malen Objekteigenschaften (z.B.. Wand / Treppe / Tür / usw.). Wenn baut der Maler eine Datenbank mit Produktivitätszahlen nach oben, er kann für neue Lackierarbeiten leicht zitieren, einfach durch die Lackoberfläche in Quadratmetern, mit der richtigen Produktivitätsrate multipliziert und multiplizieren das Ergebnis mit der Rate Stunde fragt er. Wenn da ein ... ist (International) Datenbank verfügbar mit den Produktivitätsraten von Lackierarbeiten durchgeführt von anderen Unternehmen in der Branche, der Maler versteht, wie er gegen die Industrie im Durchschnitt führt und für den Fall, ist er nicht am besten in seiner Klasse bereits, er versteht, dass neue Lackierarbeiten gewinnen er halten muss seine Produktivität zu verbessern (die Stundenrate als Senkung ist in der Regel nicht eine sehr gute Idee).

Er kann all dies tun, aber nur, wenn:

  • Er benutzt ein Standard-Messeinheit, z.B.. Quadratmeter. Nur durch Standards, Produktivitätsraten können verglichen werden (gebenchmarktes) und für Abschätzen;
  • Er benutzt ein Standard Art und Weise der Mühe Stunden aufzeichnen. Beispielsweise, die Mittagspause eingeschlossen oder ausgeschlossen wird, ist die Zeit, um die Kunden zu reden enthielt seine Anforderungen zu verstehen / ausgeschlossen?
  • Er benutzt meaningful Kategorien dass differenzierbare Produktivität. Für einen Maler, es kann nicht zu viel, wenn das Objekt Farbe egal (sagen wir mal eine Wand) ist in einer Villa oder in einem Fischer-Haus. Die Art des Hauses kann keine sinnvolle Kategorie sein. jedoch, das Werkzeug, das er verwendet, ist wahrscheinlich ein Haupt Produktivität Treiber.

Jetzt, Werfen wir einen Blick auf die Software-Industrie.

Die Software-Industrie und Produktivitätsmessung

Unglücklicherweise, Das es (und Software) Industrie ist immer noch recht unreif, wenn es darum geht, Standards zu verwenden, und wenn es darum geht, die Produktivität (Performance) Messung, Benchmarking und kontinuierliche Verbesserung. Die Industrie kam mit, dass für eine lange Zeit, da:

  • Es ist schwer zu messen Ausgabe (Software ist keine physische Sache, kann nicht mit herkömmlichen Messinstrumente berührt und gemessen werden).
  • Software-Projekte sind viel mehr wie ein R&D-Projekt als die Herstellung eines Produkts. R&D ist unglaublich schwer zu messen. Es ist relativ einfach, die Eingänge zu messen, aber die Ausgänge sind schwer zu messen und unvorhersehbar von der Natur.

Jetzt, langsam die Industrie immer mehr und mehr transparent und Kundenorganisationen stellen potenzielle Lieferanten mehr und mehr um ihre Leistung zu quantifizieren, basierend auf historischen Daten. Diesen Weg, wird es möglich, die besten Lieferanten für den Job zu wählen. Bitte beachten Sie, dass die beste Wahl ist in der Regel nicht die billigste Wahl (Projektausfälle häufig zu…oder sogar Katastrophen).

Standards

Zwar mag es einfach scheint Produktivität Messprozess in einer Organisation zu implementieren, Realität zeigt, dass es schwieriger ist, als man vielleicht denken,. Allgemein gesagt, genau wie der Maler, es reicht aus, um Messeingänge (in der Regel Mühe Stunden) und Ausgängen (Maßeinheiten, UoM) pro Software-Projekt, während mit sinnvollen Kategorien, die Projekte zu unterscheiden, wie Technologie (Java / .NET / Oracle / etc.), Projekttyp (Neuentwicklung / Erweiterung) und / oder Umsetzung (Paketimplementierung / Änderung / Maß-Software).

Um der Lage sein, sinnvolle und vergleichbare Produktivität Metriken aufzubauen, es ist wichtig, dass (International) Standards verwendet werden. Eine Reihe von Entscheidungen gemacht werden müssen:

Messtaster

Einige Entscheidungen, die gemacht werden müssen:

  • Effort Stunden in / out Bereich der Mess, zum Beispiel
    • Technisches Design, Verschlüsselung, Gerätetest, Systeme Test, andere Anbieter Tests, Overhead in Rahmen;
    • Funktionelles Design, Unterstützung Abnahmeprüfung, Umsetzungsaktivitäten außerhalb des Bereichs.
  • Überstunden in / out Bereich der Mess;
  • Reisezeiten, Treffen Stunden, Kopf Stunden in / out Umfang;
  • Im Fall von Paketen, Portale / CMS oder andere konfigurierbare Software, kann es erforderlich sein gesonderten Aufwand Registrierungsaktivitäten, die individuell gestaltet haben, Parameter und maßgeschneiderte Software, die nicht Teil des Pakets Einstellung.

Um die Produktivität eines Lieferanten zu analysieren, Abteilung oder ein Team, der Aufwand Registrierungssystem sollte in üblicher Weise umgesetzt werden. Wenn die Wahl getroffen wird, dass funktionale Design Stunden Anwendungsbereich sind out, Alle Projekte sollten ihre Anstrengungen von funktionalem Design getrennt von den anderen Aufwand Stunden registrieren. Es wird nachdrücklich empfohlen, einen Standard ‚Projektstrukturplan erstellen empfohlen (PSP)’ pro Projekttyp und implementieren dieses PSP in dem Bemühen Registrierungssystem. Jeder, den Aufwand Stunden registriert sollte ihre Anstrengungen der Buchung bewusst, wie wichtig sein im System korrekt.

Messausgänge, Methoden, die vermieden werden sollten

Messausgänge ist etwas härter als die Eingänge Mess, aufgrund der immateriellen Natur von Software. Viele Unternehmen messen die gelieferten Quellencodezeilen (slocs) des Softwareproduktes nach Fertigstellung und Nutzung Produktivität Metriken wie Aufwand Stunden geliefert pro 1000 slocs. Dies scheint ein guter Weg zu gehen, aber in der Tat gibt es viele Gründe, warum dies nicht empfohlen ist:

  • Es gibt kein (ISO oder andere) Standard für Source Lines of Code. Das Ergebnis ist, dass verschiedene automatische Codezählung Werkzeuge erzeugen (sehr) unterschiedliche Ergebnisse für den gleichen Code.
  • Es ist nicht klar, ob mehr Code ‚gut’ oder schlecht'. Source Codezeilen sind nicht von Wert für die Kundenorganisation. Die Funktionalität ist der Wert. Kunden, nie sagen,:”Bitte geben Sie mir 100000 Quellencodezeilen”. Nein, es ist Funktionalität in Bezug auf die Funktionen, die sie benötigen. Mehr Funktionalität ist besser und kostet mehr, mehr slocs ist vielleicht nicht besser.
  • Verschiedene Programmiersprachen (und Mischungen davon) führen zu sehr unterschiedlichen Quellencodezeilen Ergebnisse.

Amerikanische ‚Guru Software-Metriken’ Capers Jones schrieb in einem Papier ‚Software Defect Origins und Abbaumethoden (2013) dass sloc Messungen sind so ungenau, dass slocs in Software Messung verwendet, ist in der Tat ‚Berufliche Fehler‘.

Andere Größe Maßnahmen, die häufig in der Industrie verwendet werden,, sondern sind auch nicht empfohlen Produktivitätsmessung verwenden:

  • Story-Punkte (SP) in agilen Projekten: Eine sehr subjektive Maßnahme, den Wert nur innerhalb eines Teams hat. Vergleich zu anderen Teams, Abteilungen und Organisationen sind nicht möglich. Bitte beachten Sie, dass SP Plan Sprint nützlich sind und die Geschwindigkeit für ein Team verfolgen, aber für die Produktivität ist Messung SP Nähe von nutzlos.
  • usecase Punkte (UCP): Nur anwendbar, wenn die Dokumentation von usecases besteht. UCP ist auch ein sehr subjektives Verfahren, vor allem, wenn es darum geht, die technische Komplexität Faktor und der Umweltfaktor zu etablieren. Ebenfalls, es gibt keine Standardmethode usecases schreiben, siehe zum Beispiel die fünf möglichen Ebenen der Granularität, wie beschrieben Hier.
  • Komplexität Punkte: Subjektive und nicht standardisierte Methode, um die Komplexität einer Anwendung zu messen.
  • IBRA Punkte: Nicht Verfahren standardisiert die Geschäftsregeln in einer Anwendung zu messen. Wenn nach dem Handbuch angewendet, das Ergebnis ist Null für alle Anwendungen.
  • Schneller Function Points (FFPA) (von Gartner): Eine Meßmethode von Gartner eingesetzt, die nicht auf die ISO standardisierten Funktionspunkt Analyseverfahren verglichen werden,. FFPA wahrgenommen wird eine kommerzielle Methode zu sein, die eine theoretische Basis fehlt und ist zum Teil subjektiven. Das Verfahren hat sich nicht schneller sein als die Methode Nesma geschätzt und hat sich nicht mehr genau zu sein. Leider ist es oft auf höhere Management-Ebene, ohne die Unterstützung der Spezialisten geschoben, die mit ihm zu arbeiten haben.

Messausgang – dringend empfohlen Methoden

Es ist ein sehr empfehlenswerte Praxis verwenden ein ISO / IEC-Norm für funktionelle Größenmessung in Produktivitätsmessung von Software-Projekten. Es gibt fünf funktionale Größe Messmethoden, die die ISO / IEC-Norm:

  • NESMA Funktionspunkte (ISO / IEC 24570);
  • IFPUG Funktionspunkte (ISO / IEC 20926);
  • COSMIC Funktionspunkte (ISO / IEC 19761);
  • Mark II Funktionspunkte (ISO / IEC 20968);
  • FISMA Funktionspunkte (ISO / IEC 29881).

Vorteile einer dieser funktionellen Größe Meßmethoden für Produktivitätsmessung unter Verwendung sind:

  • Zielsetzung, wiederholbar, nachprüfbar, vertretbarer Weg, um die Größe der Software zu bestimmen,;
  • Eine klare Beziehung zwischen funktionaler Größe und Aufwand erforderlich, um die application.This zu erkennen, wurde untersucht und verifiziert viele Male;
  • Die Maßnahme ist für beide Kundenorganisationen und Lieferantenorganisationen klar. Mehr Funktionalität bedeutet mehr Wert, mehr Aufwand und ein höherer Preis;
  • Funktionelle Größe ist unabhängig von der technischen Lösung und / oder den nicht-funktionalen Anforderungen. Eine Anwendung von 500 NESMA Funktionspunkte in Java realisiert ist nur so groß wie ein Wordpress-Website 500 FP. Dies ermöglicht den Vergleich und Benchmarking über technische Bereiche und die Verwendung von historischen Projektdaten (wenn sie richtig klassifiziert) in neue Software-Projekte Abschätzen.

Nützliche Kategorien für die Datenerfassung

Um der Lage sein, zu vergleichen und vergleichen Sie Ihre Produktivität, es ist wichtig, Standardkategorien, um Daten aus Ihren Projekten zu verwenden. Nesma empfiehlt dringend, die Definitionen und Kategorien zu verwenden, die die International Software Benchmarking Standards Group (ISBSG) in ihrer Datenerhebung verwendet.

Die International Software Benchmarking Standards Group (ISBSG) ist ein ‚nicht-for-Profit’ Organisation, dass die Industrie Daten Software sammelt und wächst, aufrecht erhält und nutzt zwei Verwahrungs: ‚Neue Entwicklungen und Verbesserungen’ und Wartung & Unterstützung'. ISBSG kann dies nur tun, wenn Daten in üblichen Weise gesammelt. Die ‚Data Collection Fragebögen’ kann von dem heruntergeladen werden ISBSG Website und zeigen bereits viele Definitionen und Kategorien. Auch die Glossare, die mit den Repositories zur Verfügung gestellt werden, sind hilfreich.

Implementierung von Software Produktivitätsmessung

So, genau wie der Maler aus dem obigen Beispiel, es ist möglich, die Produktivität von Software-Projekten zu messen. Sehen Sie diese Seite für ein paar Beispiele.

Um erfolgreich Software Produktivitätsmessung zu implementieren, es wird dringend zu verwenden, um das Dokument ‚Grundlage von Messungen empfohlen’ Das ist in der Liste aufgeführten Veröffentlichungen.