Estimering av programvareutvikling - Software development effort estimation
I programvareutvikling er anslagsestimering prosessen med å forutsi den mest realistiske innsatsen (uttrykt i antall timer eller penger) som kreves for å utvikle eller vedlikeholde programvare basert på ufullstendig, usikker og støyende innspill. Effort estimater kan brukes som innspill til prosjektplaner, iterasjon planer, budsjetter, investeringsanalyser, prisprosesser og budrunder.
State-of-praksis
Publiserte undersøkelser om estimeringspraksis antyder at ekspertestimering er den dominerende strategien når man skal estimere programvareutvikling.
Vanligvis er anslagsestimater overoptimistiske, og det er en sterk overtillit i nøyaktigheten. Gjennomsnittlig innsatsoverskridelse ser ut til å være omtrent 30% og ikke avta over tid. For en gjennomgang av innsatsestimeringsfeilundersøkelser, se. Målingen av estimeringsfeil er imidlertid problematisk, se Vurdere nøyaktigheten av estimater . Den sterke overbevisstheten i nøyaktigheten av innsatsestimatene illustreres av funnet at i gjennomsnitt hvis en programvare er 90% sikker eller "nesten sikker" på å inkludere den faktiske innsatsen i et minimum-maksimalintervall, vil den observerte frekvensen av inkludert den faktiske innsatsen er bare 60-70%.
For øyeblikket brukes begrepet "innsatsestimat" for å betegne som forskjellige begreper som mest sannsynlig bruk av innsats (modalverdi), innsatsen som tilsvarer en sannsynlighet på 50% for ikke å overstige (median), den planlagte innsatsen, den budsjetterte innsatsen eller innsatsen som ble brukt for å foreslå et bud eller en pris til kunden. Dette antas å være uheldig, fordi kommunikasjonsproblemer kan oppstå og fordi konseptene tjener forskjellige mål.
Historie
Programvare forskere og praktikere har tatt opp problemene med anslagsestimering for programvareutviklingsprosjekter siden minst 1960 -tallet; se f.eks. arbeid av Farr og Nelson.
Mesteparten av forskningen har fokusert på konstruksjon av formelle estimeringsmodeller for programvareinnsats. De tidlige modellene var vanligvis basert på regresjonsanalyse eller matematisk avledet fra teorier fra andre domener. Siden den gang har et stort antall modellbyggingsmetoder blitt evaluert, for eksempel tilnærminger basert på sakbasert resonnement , klassifisering og regresjonstrær , simulering , nevrale nettverk , bayesiansk statistikk , leksikalsk analyse av kravspesifikasjoner, genetisk programmering , lineær programmering , økonomisk produksjon modeller, soft computing , uklar logisk modellering, statistisk bootstrapping og kombinasjoner av to eller flere av disse modellene. De kanskje vanligste estimeringsmetodene i dag er de parametriske estimeringsmodellene COCOMO , SEER-SEM og SLIM. De har sitt grunnlag i estimeringsforskning utført på 1970- og 1980-tallet og er siden oppdatert med nye kalibreringsdata, med den siste store utgaven COCOMO II i år 2000. Estimeringsmetodene er basert på funksjonalitetsbaserte størrelsesmål, f.eks. Funksjon poeng , er også basert på forskning utført på 1970- og 1980-tallet, men kalibreres på nytt med endrede størrelsesmål og forskjellige tellemetoder, for eksempel use case-punkter eller objektpunkter på 1990-tallet.
Estimering nærmer seg
Det er mange måter å kategorisere estimeringsmetoder på, se for eksempel. Kategoriene på toppnivå er følgende:
- Ekspertestimering: Kvantifiseringstrinnet, dvs. trinnet der estimatet er produsert basert på dømmende prosesser.
- Formell estimeringsmodell: Kvantifiseringstrinnet er basert på mekaniske prosesser, f.eks. Bruk av en formel avledet fra historiske data.
- Kombinasjonsbasert estimering: Kvantifiseringstrinnet er basert på en dømmende og mekanisk kombinasjon av estimater fra forskjellige kilder.
Nedenfor er eksempler på estimeringsmetoder innen hver kategori.
| Estimeringstilnærming | Kategori | Eksempler på støtte for implementering av estimeringsmetode |
|---|---|---|
| Analogibasert estimering | Formell estimeringsmodell | ANGEL, vektede mikrofunksjonspunkter |
| WBS-basert (nedefra) estimering | Ekspertestimering | Prosjektstyringsprogramvare , bedriftsspesifikke aktivitetsmaler |
| Parametriske modeller | Formell estimeringsmodell | COCOMO , SLIM , SEER-SEM , TruePlanning for Software |
| Størrelsesbaserte estimeringsmodeller | Formell estimeringsmodell | Funksjon Point Analysis , Use Case Analysis, Use Case Points , SSU (Software Size Unit), Story points -based estimation in Agile software development , Object Points |
| Gruppeanslag | Ekspertestimering | Planlegger poker , Wideband delphi |
| Mekanisk kombinasjon | Kombinasjonsbasert estimering | Gjennomsnitt av et analogibasert og et Work breakdown strukturbasert innsatsestimat |
| Dømmekombinasjon | Kombinasjonsbasert estimering | Ekspertvurderinger basert på estimater fra en parametrisk modell og gruppestimering |
Valg av estimeringsmetoder
Bevisene for forskjeller i estimeringsnøyaktighet for forskjellige estimeringsmetoder og modeller antyder at det ikke er noen "beste tilnærming", og at den relative nøyaktigheten til en tilnærming eller modell i forhold til en annen avhenger sterkt av konteksten. Dette innebærer at forskjellige organisasjoner drar fordel av forskjellige estimeringsmetoder. Funn som kan støtte valg av estimeringsmetode basert på forventet nøyaktighet av en tilnærming inkluderer:
- Ekspertestimering er i gjennomsnitt minst like nøyaktig som modellbasert innsatsestimering. Spesielt kan situasjoner med ustabile forhold og informasjon av høy betydning som ikke er inkludert i modellen foreslå bruk av ekspertestimering. Dette forutsetter selvfølgelig at eksperter med relevant erfaring er tilgjengelige.
- Formelle estimeringsmodeller som ikke er skreddersydd for en bestemt organisasjons egen kontekst, kan være svært unøyaktige. Bruk av egne historiske data er følgelig avgjørende hvis man ikke kan være sikker på at estimeringsmodellens kjerneforhold (f.eks. Formelparametere) er basert på lignende prosjektsammenhenger.
- Formelle estimeringsmodeller kan være spesielt nyttige i situasjoner der modellen er skreddersydd for organisasjonens kontekst (enten ved bruk av egne historiske data eller at modellen er avledet fra lignende prosjekter og sammenhenger), og det er sannsynlig at ekspertenes estimater vil være utsatt for en sterk grad av ønsketenkning.
Det mest robuste funnet i mange prognosedomener er at kombinasjon av estimater fra uavhengige kilder, foretrukket ved bruk av forskjellige tilnærminger, i gjennomsnitt vil forbedre estimeringsnøyaktigheten.
Det er viktig å være oppmerksom på begrensningene ved hver tradisjonell tilnærming for å måle produktivitetsutvikling av programvare.
I tillegg bør andre faktorer som enkel forståelse og kommunikasjon av resultatene av en tilnærming, brukervennlighet av en tilnærming og kostnadene ved introduksjon av en tilnærming vurderes i en utvelgelsesprosess.
Vurdere nøyaktigheten av estimater
Det vanligste målet for gjennomsnittlig estimeringsnøyaktighet er MMRE (Mean Magnitude of Relative Error), der MRE for hvert estimat er definert som:
- MRE = | (faktisk innsats) - (estimert innsats) |/(faktisk innsats)
Dette tiltaket har blitt kritisert, og det er flere alternative tiltak, for eksempel mer symmetriske mål, vektet gjennomsnitt av kvartiler av relative feil (WMQ) og gjennomsnittlig variasjon fra estimat (MVFE).
MRE er ikke pålitelig hvis de enkelte elementene er skjevt. PRED (25) foretrekkes som et mål på estimeringsnøyaktigheten. PRED (25) måler prosentandelen av forutsagte verdier som ligger innenfor 25 prosent av den faktiske verdien.
En høy estimeringsfeil kan ikke automatisk tolkes som en indikator på lav estimeringsevne. Alternative, konkurrerende eller utfyllende årsaker inkluderer lavkostnadskontroll av prosjekt, høy kompleksitet i utviklingsarbeid og mer levert funksjonalitet enn opprinnelig estimert. Et rammeverk for forbedret bruk og tolkning av estimeringsfeilmåling er inkludert i.
Psykologiske problemstillinger
Det er mange psykologiske faktorer som potensielt forklarer den sterke tendensen til overoptimistiske innsatsestimater som må håndteres for å øke nøyaktigheten av innsatsestimater. Disse faktorene er viktige selv når du bruker formelle estimeringsmodeller, fordi mye av innspillet til disse modellene er dømmebasert. Faktorer som har vist seg å være viktige er: Ønsketenkning , forankring , planlegging av feil og kognitiv dissonans . En diskusjon om disse og andre faktorer kan bli funnet i arbeid av Jørgensen og Grimstad.
- Det er lett å anslå det du vet.
- Det er vanskelig å anslå det du vet at du ikke vet. (kjente ukjente)
- Det er veldig vanskelig å anslå ting du ikke vet at du ikke vet. (ukjente ukjente)
Humor
Den kroniske undervurderingen av utviklingsarbeidet har ført til mynting og popularitet for mange humoristiske ordtak, for eksempel ironisk å referere til en oppgave som et " lite spørsmål om programmering " (når det er sannsynlig mye krefter), og siterer lover om undervurdering:
De første 90 prosentene av koden utgjør de første 90 prosentene av utviklingstiden. De resterende 10 prosentene av koden står for de andre 90 prosentene av utviklingstiden.
- Tom Cargill, Bell Labs
Hofstadters lov: Det tar alltid lengre tid enn du forventer, selv når du tar hensyn til Hofstadters lov.
Det en programmerer kan gjøre på en måned, kan to programmerere gjøre på to måneder.
For å legge til det faktum at det er vanskelig å estimere utviklingsarbeid, er det verdt å si at tildeling av flere ressurser ikke alltid hjelper.
Sammenligning av utviklingsestimeringsprogramvare
| Programvare | Planlegg estimat | Kostnadsberegning | Kostnadsmodeller | Inngang | Rapportutdataformat | Støttede programmeringsspråk | Plattformer | Koste | Tillatelse |
|---|---|---|---|---|---|---|---|---|---|
| AFCAA REVIC | Ja | Ja | REVIC | KLOC , skalafaktorer , kostnadsdrivere | proprietær, tekst | Noen | DOS | Gratis | Proprietær / gratis for offentlig distribusjon |
| Seer for Software | Ja | Ja | SEER-SEM | SLOC , Funksjonspunkter , brukstilfeller, bottom-up, objekt, funksjoner | proprietære, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball | Noen | Windows, Any ( nettbasert ) | Kommersiell | Proprietær |
| SLANK | Ja | Ja | SLANK | Størrelse ( SLOC , funksjonspunkter , brukstilfeller, etc.), begrensninger (størrelse, varighet, innsats, personale), skalafaktorer, historiske prosjekter, historiske trender | proprietær, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, tekst, HTML | Noen | Windows, Any ( nettbasert ) | Kommersiell | Proprietær |
| TruePlanning | Ja | Ja | PRIS | Komponenter, strukturer, aktiviteter, kostnadsdrivere, prosesser, funksjonell programvarestørrelse (Source Lines of Code (SLOC), funksjonspunkter, Use Case Conversion Points (UCCP), Predictive Object Points (POPs) etc.) | Excel, CAD | Noen | Windows | Kommersiell | Proprietær |