Metrieken

From HaFrWiki
Jump to: navigation, search

Het effectief kunnen managen van processen vereist kwantificering, meetbaarheid en modellering. Software metrieken verschaffen een kwantitatieve basis voor ontwikkeling en validatie van modellen van de ontwikkel processen. Metrieken kunnen leiden tot het verbeteren van de software productiviteit en kwaliteit. 

  Meten is weten
  Gissen is missen

Filosofie

Herhaaldelijk wordt bewezen dat we in een software crisis bevinden: We zijn niet in staat om betrouwbare software op tijd en binnen budget op te leveren.
Als reden wordt vaak de gestegen complexiteit van de software ontwikkeling gegeven, waarvoor geen analytische beschrijving bestaat. Dit kan worden verbeterd door beter software beheer. En dat vereist betere meetmethoden en beter gebruik van de bestaande meetmethoden.
De stelling: Hoe vaker metrieken gebruikt worden, des te meer waardevolle vergelijkbare waarden beschikbaar komen. is dus niet helemaal waar!
Het gebruik van metrieken en de uitkomsten van metrieken moeten met kennis van zaken worden toegepast. [1]

Metrieken

Hoe ziet de ideale metriek eruit:

  • Simpel, precies en definieerbaar
    Het is duidelijk wat mbv de metriek bepaald wordt.
  • Objectief
    Ten aanzien van de uitkomst. Dit in tegenstelling tot subjectieve metingen.
  • Gemakkelijk verkrijgbaar
    Zonder veel inspanning (kosten)
  • Valide (Steekhoudend)
    De metriek meet wat gemeten moet worden.
  • Robust
    Ongevoelig voor veranderingen in processen en/of producten

Classificatie

Ruwweg bestaan:

  • Product metrieken
    Metingen van software producten in alle ontwikkelstadia. Zoals complexiteit van software ontwerp, grootte van de sources en deliverables, totaal aantal pagina´s documentatie.
  • Process metrieken
    Metingen van het Software Ontwikkel Proces. Zoals totale ontwikkeltijd, type methodologie, gemiddeld kennis en ervaring niveau van de ontwikkel staf.

Maar er zijn ook andere indelingen:

  • Objectief
    Resulteren altijd in identieke waarden voor gelijke metriek methoden.
  • Subjectief
    Resulteren in verschillende waarden voor gelijke metriek methoden.

Voorbeeld:

  1. De LOC (Lines of Code) is een objectieve metriek, die dezelfde waarde heeft binnen een gegeven project.
  2. De subjectieve classificatie van Organic, Semi-detached, Embedded zoals gebruikt wordt in het kosten raming model COCOMO (COnstructive COst MOdel).

En

  • Primitief
    Bijv.: LOC, aantal fouten gevonden in unit-test, totale ontwikkeltijd
  • Computed (Berekend)
    Bijv.: LOC gemaakt door een ontwikkelaar per maand, kwaliteit uitgedrukt als aantal fouten per 1000 regels code.

De berekende metrieken hebben meestal meer waarde omdat ze een evaluatie over het software proces bevatten.

Meetschalen voor metrieken

Het verzamelen van metrieken wordt gedaan met een specifiek doel. Voor de gegevens verzameld worden is het van belang te weten welk soort informatie ermbij bertokken is. Door statistici worden 4 typen meetdata onderkend:

Type data Mogelijke
bewerking 		Data
Beschrijving 		Voorbeeld Toelichting
Nominaal =, ≠ Categorieën
Categories		 Database program
Operating System 		Geen rekenkundige operatie, geen natuurlijke ordening.
Alleen gelijk of ongelijk.
Ordinaal <, > Rangorden/Lijsten
Rankings		 Ervaring niveau
(laag, gemiddeld, hoog) 		De verschillen tussen de waardering is niet te bepalen.
Gemiddeld is niet 2x laag.
Interval +, - Verschillen
Differences		 Programma complexiteit Vergelijkbare verschillen. Een complex programma van 6 units is 4 units ingewikkelder dan 2, maar niet per definitie 3x ingewikkelder.
Ratio / Absolute waarde
Absolute zero		 Lines of Code (LOC) Vergelijkbaar en absoluut.
Een programma van 2000 regels is 2x zogroot als een programma van 1000 regels.

State of Software Metrics

De gebruikte software metrieken ontberen vaak:

  • Conceptueel en theoretische basis
  • Statistisch significante experimentele validatie

Voorbeeld: Neem een simpele metriek als LOC. De uitkomsten van LOC verschillen sterk als gekeken wordt naar definities en tel-technieken. Hierdoor wordt vergelijken onmogelijk. Zo ook LOC/Maand en Euros/LOC. Hier zou kunnen uitkomen dat Assembler programmeurs productiever zijn dan High-Level Language programmeurs.

Product metrieken

Size metrices

  1. Lines of Code - LOC
  2. Functie Punt Analyse - FPA or FP
  3. Bang

Complexity metrics

  1. Cyclomatic Complexity - v(G)
  2. Uitbreidingen op v(G)
  3. Knots
  4. Information Flow

Halstead's Product metrieken

In 1977 heeft Maurice Howard Halstead de volgende metrieken geïntroduceerd:

Nr Metriek Formule
1 Program Vocabulary n = n1 + n2
2 Program Length N = N1 + N2
3 Volume V = N * 2log(n)
4 Difficulty D = n = (n1/ 2) * (N2 / n2)
5 Effort E = D * V
Where:
  • n1: Aantal unieke operatoren
  • n2: Aantal unieke bewerkingen
  • N1: Aantal operatoren
  • N2: Aantal bewerkingen

Quality metrieken

  1. Defect Metrics
  2. Reliability Metrics
  3. Maintainability Metrics

Voorbeelden zijn: 

   Maintainability Index (MI) = 171 - 5.2 * ln (PgmVolume) - 0.23 * ExtCycComp - 16.2 * ln (LOC) + 50 * sin (sqrt (2.46 * Comment­Lines/SourceLines))
    PgmVolume: Halstead Volume
    Extended Complexity: Cyclomatic Complexity plus Logische bewerkingen in Condities
    LOC: Lines of Code
    Commentlines: Aantal Commentaar regels
    Sourcelines: Aantal Bronregels

Proces metrieken, Modellen en empirische validatie

Hoewel het definiëren van Software metrieken zonder specifieke referentie kan worden gemaakt (denk aan LOC). In de praktijk worden deze methoden gekoppeld aan een Software Ontwikkel Proces.
Modellen zijn versimpelde abstracties van producten of processen, die wij willen beschrijven. Effectieve modellen maken het mogelijk om de niet interessante onderdelen te scheiden van de essentiële aspecten. De voorkeur gaat uit naar het simpelste model dat de beste beschrijving levert (KISS).
De modellen van de software ontwikkeling zijn van nature analytische constructies of empirische beschrijvend.
De validiteit van software metrieken en modellen moet worden getoetst met de uitkomsten van empirische of experimentele gegevens. Dit vereist veel meetgegevens uit grote en kleinere projecten.
Kennis van Statistiek is essentieel voor het kunnen uitvoeren van betekenisvolle experimenten en het analyseren van uitkomsten. Binnen de software ontwikkeling ontbreekt het in de praktijk vaak aan deze specifieke kennis.

Empirische modellen

Een van de oudste methode om de projectkosten te kunnen schatten is het vergelijken met overeenkomstige projecten. De methodiek is gebaseerd op de 'Waterfall Life Cycle' en maakt gebruik van een projectie van de historische gegevens m.b.v. een 25 x 7 'structural forecast matrix' ([Wolverton 74, TRW).

Statistische modellen

C.E. Walston en C.P. Felix (IBM) hebben gebruik gemaakt van de gegevens van 60 software projecten. Uitgaande van de veronderstelling dat de LOC de voornaamste factor voor de ontwikkel inspanning is: 

 E = aLb
   L: Aantal regels code (x 1000)
   E: Totale inspanning (in man maanden)

Met behulp van regressie analyse zijn de parameters geschat, resulterend in 

 E = 5.2 L0.91

De productiviteit per persoon per maand (pppm) kan worden berekend door L/E. Tevens hebben zij geprobeerd de productiviteit Index te bepalen gebaseerd op maar liefst 68 verschillende verklarende factoren.

Theoretische modellen

Slechts een paar van de gepresenteerde modellen hebben een theoretische grondslag.

PNR

Larry Putnam & Nordan onwikkelden een model gebaseerd op de aanname dat de personeelsinzet gedurende een project zich laat beschrijven als een Rayleigh-curve. De formule van de continue kansverdelingsfunctie van Lord Rayleigh luidt: 

           x -(x^2)/(2σ^2)
 f(x|σ) =  ---------------
                σ2

De vergelijking van de Putnam Nordan Rayleigh (PNR) luidt: 

        Kte-(t^2)/2T^2)
 y(t) = -------------
            T2
   waarbij:
     y: aantal personen op project op tijdstip t
     K: Oppervlakte onder de Rayleigh verdeling curve, gelijk aan totaal levenscyclus inzet in manjaren
     T: Ontwikkeltijd (piek inzet van personen).

Daarbij werd gebruik gemaakt van de relatie tussen grootte en ontwikkeltijd: 

 S = CK1/3T4/3
   waarbij:
     S: Opgeleverde LOC
     K: Levenscyclus inzet in manjaren
     C: Technologie constante

Halstead

De totale inspanning voor de ontwikkeling van software: 

      V 
 E = ---
      L
  waarbij:
    E: Totale inspanning
    V: Programma volume
    L: Programma grootte

De schatter van E is: 

      n1n2 (n12log(n1) + n22log(n2) ) 2log(n)
 E = --------------------------------------
                  2n2
  waarbij:
    n1: Aantal unieke bewerkingstekens
    n1: Aantal unieke bewerkingen in het programma

Composite Models

Parameter vergelijking
File:EffortEquations.gif
Model vergeleken
File:EffortEquations Table.gif
Inspanningsvergelijkingen

Het kunnen schatten van de kosten en het aantal benodigde mensen is erg belangrijk.
Modelvergelijkingen in het engels.

COCOMO

Barry Boehms COnstructive COst MOdel (COCOMO) is het meest bekende model en erg goed gedocumenteerd. Het onderscheidt 3 model niveaus:

  • Basis (Basic)
  • Tussen liggend (Intermediate)
  • Gedetailleerd (detailed)

en 3 product ontwikkeling modes:

  • Op zichzelf staand (Organic)
  • Halfvrijstaand (Semidattached)
  • Ingebed (Embedded)

Deze gegevens moeten helpem om de de moeilijkheidsgraad van een project te bepalen. De ontwikkel inspanning vergelijking: 

  E = a Sbm
     waarbij:
       a en b constanten zijn voor iedere model en mode niveau
       S: totale waarde van de bron LOC
       m: multiplier die bepaald wordt uit 15 kosten attributen.

Daarnaast kunnen de ontwikkel duur 

  D = c Ed
    waarbij:
      c en d constanten zijn voor iedere model en mode niveau
      D: Ontwikkeltijd in maanden

en het aantal personen kunnen worden berekend: 

 P = E/D
Software project a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Er bestaan implementatie van COCOMO, zoals COSTAR, SPC.

SLIM

Gebaseerd op PNR en onwikkeld door Putnam. De gebruikte vergelijking: 

 E =  (S / P)3 . (1 / T)4
   waarbij:
     E = Ontwikkel inspanning in manjaren
     S = Grootte, Putnam gebruikt hier de Effectieve LOC
     P = Productiviteit van de organisatie om software te maken
     T = Tijd van het project in jaren

Er bestaat een commerciële implementatie van SLIM door QSM.

Estimacs

Is een inspanning schatter die de inspanning berekebt van:

  • Systeem ontwikkeling
  • Personeel (kennis en kunde, productiviteit) en kosten
  • Hardware
  • Risico
  • Portfolio analyse

Commerciele implementatie was te koop bij Computer Associates (CA), maar is inmiddels ge-cash-cow-ed.

Coolsoft

Maar 't kan allemaal ook in Microsoft Excel. Zie de website van Coolsoft voor implementaties van COCOMO, COTS en Reuse. Hiernaast is zeer verkleind een vergelijking tussen verschillende methode getoond afkomstig van het DACS.

Betrouwbaarheid modellen

Verschillende dynamische modellen zijn ontwikkeld om het optreden van software fouten van een systeem in een tijdsaanduiding te kunnen beschrijven. Hiermee kan tevens de betrouwbaarheid van een systeem(R van Reliability) worden bepaald en de gemiddelde tijd waarop een fout optreedt (MTTF).

Gebaseerd op de aannames:

  • Invoertesten zijn willekeurige voorbeelden van de invoer omgeving
  • Alle software fouten worden geobserveerd
  • De tijd tussen het optreden van fouten is exponentieel verdeeld

wordt de relatie afgeleid: 

  d(t) = D (1 - e-bct)
    waarbij:
       b en c zijn constanten die door historische gegevens bepaald wordt
       D: Totaal aantal fouten
       d(t): cumulatief totaal van fouten op tijdstip t
 
Dan wordt de gemiddelde tijd dat een fout optreedt:
 
         ebct 
 MTTF = -----
        c . D

Implementatie

Het is bewezen dat gebruik van contentieus gebruik van metrieken het begrip en managen van software processen significant verbeteren. Voor nieuwe projecten, die niet veel verschillen van historische, zijn de gehanteerde schattingsmethode zeer goed bruikbaar. Voor projecten die gebruik maken van nieuwe omgevingen, talen en methodologieën helaas niet. Gebruik van een schattingsmodel of metriek moet dus met zorg en gekalibreerd worden toegepast.

Planning

Het invoeren van metrieken vereist een nauwgezette planning.

  1. Definitie van de planning
    Wat zijn de doelen, hoe kunnen ze en hoe worden ze bereikt. Hiervoor wordt de Goal/Question/Mextric (GQM) paradigma voor gebruikt.
  2. Commitment en draagvlak
    Het gebruik van metrieken kost tijd en geld. Ze zijn niet gratis en voor niets.
    1. Initiële implementatie
    2. Doorlopende kosten

Selectie model/Metrieken

Op basis van de gedefinieerde doelen en de kosten worden de te hanteren metrieken geselecteerd. Belangrijke overwegingen in het selectie proces zijn:

  1. Is wat gepland is ook uitvoerbaar
    Voldoen de gekozen metrieken aan de doelen waaraan ze moeten voldoen.
  2. Geschatte data vereisten en kosten
    Voldoen de gekozen modellen aan de gestelde data vereisten en de kosten. Zoals eerder gesteld zijn goedkope modellen gewenst.

Data vereisten & Database onderhoud

Een gedetailleerde planning van de gespecificeerde modellen en verfijningen. Denk hierbij aan de volgende stappen:

  1. Specifieke data vereisten
    Welke specifieke informatie is wanneer vereist!
  2. Procedure voor het vergaren van de gegevens
  3. Database onderhoud
    De gevonden mtrieken moeten worden opgeslagen en onderhouden worden.

Initiële Implementatie

Aangenomen dat aan de bovenstaande eisen is voldaan, dan kunnen de onderstaande punten worden aangescherpt:

  1. Uitleg over gebruik
    Het gewenste gebruik van de metrieken moet in een vroeg stadium duidelijk zijn.
  2. Verantwoordelijkheid
    Tijdens (dus niet erna) het project moeten mensen verantwoordelijke personen zijn voor het verzamelen van de gegevens.

Ononderbroken gebruik & verfijning

Om het metrieken programma met succes te gebruiken, moeten ze constant worden toegepast en worden herzien.

  1. Evaluate
    Vergelijk de uitkomsten met wat er is gebeurd.
  2. Model aanpassingen
    De parameters van metrieken moeten worden geijkt (constanten, mutipliers etc) met de empirische gevonden waarden.

Definities van Metrieken

Zonder een definitie hebben getallen geen waarde. Het is daarom er belangrijk aandacht te besteden aan de gebruikte definities.

See also

top

Internal

External

  • Thomas Fetcke Metrics with papers, books and links.
  • Verisoft Halstead Metrics
  • Coding Standards, Internal Wiki Site (English)
  • McCabe IQ-Research Metrics.
  • CodeHaus, Sonar Metrics Definitions, Calculations & Documentation. Metrics are the heart of Sonar, using Sonar efficiently means perfectly understanding the definition and calculation algorithm of each one.
  • Sonar Source Coding Rules, CodeHaus FindBugs, Jetty, Nemo, Sonar, Squale and SunProfiles/Rules for Computer Languages. Such as C, C#, CoBOL, Flex, Java, Natural, PHP, PL/SQL, Python VB and Web.
  • Frank Oppedijk, Master Theses Software Engineering 2008, Comparison of the SIG Maintainability Model and the Maintainability Index (PDF).


Tools

  • IBM Test Planning and Optimization Workbench (TPOW) [2]
  • Lines Of Code, also know as LoC.
  • NDepend, Metric Tools for .net.
  • Simian, Red Hill Consulting copy and paste detection (dublicate code checker).

Fun

Instituten

  • ASMA/SQA, Australian Software Metrics Association/Software Quality Association, currently Charismatek.
  • CSSE, Center for System and Software Engeneering, (current director Professor Boehm)
  • Centre for Software Reliability, City University of London
  • CS IMSE, Computer Science Information Management & Software Engineering at the Vrije Universiteit Amsterdam (Chris Verhoef).
  • DACS, Data & Analysis Center for Software
  • DASMA Deutschsprachige Anwendergruppe für Software-Metrik und Aufwandschätzung e.V.
  • ESEG, Experimental Software Engineering Group of the University of Maryland
  • ESI, European Software Institute is a non profit organisation launched as initiative of the EC.
  • Fraunhofer IESE, Institut Experimentelles Software Engeneering
  • IFPUG, International Function Point User Group
  • ISBSG, International Software Benchmarking Standards Group
  • IT Service CMM, IT Service Maturity Model.
  • PSN, Practical Software and Systems Measurement
  • SEI, Software Engineering Institute at the Carnegie Mellon University
  • SML, Software Measurement Laboratory at the university of Magdeburg
  • Software Engineering Research Laboratory at the university of Quebec at Montreal

Reference

top

  1. ↑ Software Metrics, SEI Curriculum Module SEI-CM-12-1.1, December 1988
  2. ↑ IBM Asset Hub, TPOW (Test Planning and Optimization Workbench) is a tool for defining and optimizing test strategies & test plans. It combines a risk based planning approach with IBM's Defect Reduction Methodology (DRM) to form an integrated and cross life cycle test solution built upon the Rational Jazz platform and developed collaboratively by IBM Research, IBM Testing Services and IBM Software Group.
Retrieved from "https://www.harmfrielink.nl/wiki/index.php?title=Metrieken&oldid=4200"