Visste du at vedlikehold står for 50% til 80% av samlede produktet prisen? Vel, gjør det det! Og mens de fleste prosjektledere er ganske flink til dimensjonering nye produktfunksjoner, mange er fryktelig ved å estimere innsatsen som kreves for å støtte et produkt når det blir allment tilgjengelig. Som et resultat, vedlikeholdsprosjekter er ikke tilstrekkelig bemannet, selskaper kan ikke svare på kundeforespørsler på en riktig måte, og produkter nå aldri payback.
Denne artikkelen presenterer en metodikk for å hjelpe deg med å guesstimate og derfor planlegger for vedlikeholdsfase av generelt tilgjengelige produkter. Men først, la oss definere noen vilkår som er viktige for forståelsen av denne artikkelen.
Vedlikehold
Vedlikehold defineres som innsatsen forbundet med feste defekter i et programvaresystem etter general anvendelighet (GA). Med andre ord, hvor mange person-months det tar organisasjonen for å fikse feil som er oppdaget av kundene i feltet?
Vedlikehold kan deles i tre sub-kategorier.
Korrigerende vedlikehold innebærer fikse bugs som er oppdaget i systemet etter at det blir allment tilgjengelig. Et eksempel på en korrigerende Vedlikeholdsaktiviteten er en utvikler fikse en Java-metode som forårsaker en kompileringsfeil.
Adaptive vedlikehold omfatter endring av systemet til å fungere i et annet miljø som en ulik nettverkstopologi, plattform eller operativsystemet. Et eksempel på en adaptiv Vedlikeholdsaktiviteten er en utvikler fikse en Java-metode som fungerer på BEA WebLogic, men ikke på IBM Websphere.
Perfective vedlikehold innebærer endringer som tillater programvaren til å møte de samme kravene, men i en mer akseptabel måte. Utformeren kan for eksempel endre noen kode bare for å gjøre systemet mer effektive og enklere å vedlikeholde.
Forbedringer
Forbedringer, også kjent som endringsforespørsler, defineres som innsatsen forbundet med å legge nye evnen til et programvaresystem, eller å endre et programvaresystem for å møte nylig definert ikke-funksjonelle krav.
Tenk deg et program som krever at brukeren godkjenner ved hjelp av et brukernavn og passord. Ganske standard sσnt, ikke sant? Kanskje, men noen kunder vil kanskje legge til en tredje credential passord mekanismen som et domene. Andre vil kanskje brukernavn å følge en e-postadresse mønster. Til slutt, andre vil kanskje programmet å huske brukerens legitimasjon over økter, og dermed godkjenner brukeren automatisk.
Støtte
Støtte er definert som summen av vedlikehold og forbedringer arbeidet utført etter at produktet er GA. Med andre ord, inkluderer støtte alle aktiviteter som går på etter at et produkt er erklært generelt tilgjengelig.
Metodikk
Tidlig i min karriere, jeg innså at enkel regel av tommelen kan brukes til beregning av kostnaden for støtte for enkelte prosjekter. For eksempel er årlige kostnader for å støtte et statisk webområde etter den går live mer eller mindre tilsvarer kostnaden for å utvikle det. Med andre ord, hvis utvikler en statisk nettsted koster $ 10 000, kan du forvente å tilbringe $ 10 000 per år som vedlikeholder den.
Forstå slike regler er veldig praktisk. Dessverre, noen av dem er overførbar. Med andre ord, vil den samme regelen ikke gjelde for en e-handel aktivert dynamiske webområder fordelt over tre etasjer.
Ulike modeller er utviklet gjennom årene for å forutsi vedlikeholdskostnader basert på defekt tetthet (f.eks Raleigh kurve, Weibull analyse), KLOC og KDSI og utviklingsarbeidet. Dessverre, disse modellene er ikke uten noen svakheter heller. Mange av dem er enten svært unøyaktig eller for komplisert til å bry lære dem. Som et spørsmål om faktum, er noen så komplisert at du trenger å kjøpe et program verdt tusenvis av dollar og skriv inn 100 + parametere for å ha det beregne arbeidet med å opprettholde din produkt.
Etter å ha studert over et dusin prognoser modeller, er det en metode som jeg anbefaler til noen nybegynner eller erfaren prosjektleder.
Boehms modell
Boehms modell er allment akseptert i industrien som en gyldig modell for å forutsi vedlikeholdskostnader. Det er relativt enkelt å forstå, og enda viktigere, det lar deg avgrense prognosen takket være kostnaden multiplikatorer, som vil bli forklart senere i denne artikkelen.
Boehms formel er følgende:
AME = ACT X SDT, der
AME er den årlige vedlikehold innsatsen målt i personen måneder
LOVEN er den årlige endring-trafikken, som utgjør en brøkdel av et programvareprodukt kilde instruksjoner som gjennomgår endres under en typisk året gjennom tillegg eller modifisering
SDT er programvare utviklingstid i person måneder
Si en programvareprosjekt kreves 100 person-months utviklingsinnsats og det ble anslått at 15% av koden ville bli endret på et typisk år. Grunnleggende årlig vedlikehold innsats for anslaget (AVN) er derfor:
AME = 0,15 x 100 = 15 person-months
Med andre ord, bør du planlegge å bruke 15 person-months av innsats per år for å opprettholde dette spesifikke programvare-prosjektet.
Grunnleggende årlig vedlikehold kostnadsestimatet kan være raffinert av bedømme viktigheten av hver faktor som påvirker kostnadene og velge riktig pris multiplikatoren. Grunnleggende vedlikeholdskostnadene er så multiplisert med hver pris multiplikatoren å gi den reviderte vedlikehold kostnadsestimatet.
I forrige systemet var si faktorer som har de fleste effekt på vedlikeholdskostnader produktet kompleksitet (CPLX), som var svært høy, og tilgjengeligheten av støttepersonell med programmet erfaring (AEXP), som var svært lav.
Hvis CPLX = 1.30 og AEXP = 1,29, deretter:
AEM = 15 x 1.30 x 1,29 = 25.2 person-months
Prognoser forbedringer
Den reviderte vedlikeholdskostnadene inkluderer virkningen av kostnader-multiplikatorer men ikke inkluderer produktforbedringer, også kjent som endre forespørsler.
Den dårlige nyheten er at prognoser forbedringer er svært vanskelig fordi det krever at du vet på forhånd hvilke nye ferdigheter din fremtidige kunder vil be om. Den gode nyheten er at du kan lade dine kunder for forbedringer som de krever. Som et resultat, betrakter en god organisering ikke forbedringer til å representere en pris, men heller en kilde til gradvis økende inntekter.
Konklusjon
Når prognoser kostnadene ved å opprettholde et produkt som er allment tilgjengelig, kan du følge disse rådene:
-Lær og bruk denne (forenklet) versjonen av Boehms modellen til å forutsi vedlikeholdskostnader.
-Spore din SDT.
-Måle din handling.
-Definere kostnader multiplikatorer for å avgrense prognosen.
Videre, sørg for at du har et profesjonelle tjenester team å implementere endringsforespørsler kreves av dine kunder, men ikke behandle dem som kostnadene siden de er faktisk en inntektskilde.