{"id":11400,"date":"2021-06-30T16:04:14","date_gmt":"2021-06-30T14:04:14","guid":{"rendered":"https:\/\/www.software-developer-india.com\/hvordan-vurdere-en-estimering-av-programvarekostnad-for-ikke-tekniske-personer\/"},"modified":"2021-07-04T15:42:50","modified_gmt":"2021-07-04T13:42:50","slug":"hvordan-vurdere-en-estimering-av-programvarekostnad-for-ikke-tekniske-personer","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/no\/hvordan-vurdere-en-estimering-av-programvarekostnad-for-ikke-tekniske-personer\/","title":{"rendered":"Hvordan vurdere en estimering av programvarekostnad (for ikke-tekniske personer)"},"content":{"rendered":"\n

Hvordan vurdere en estimering av programvarekostnad (for ikke-tekniske personer)<\/h2>\n\n\n\n
\"\"<\/a><\/figure><\/div>\n\n\n\n

Det er ganske vanskelig \u00e5 evaluere et programvareprosjekt og sette en prislapp p\u00e5 det.<\/p>\n\n\n\n

I artikkelen noen utfordringer og hvordan du g\u00e5r frem for \u00e5 vurdere estimater av programvarekostnader.<\/p>\n\n\n\n

Introduksjon<\/strong><\/h3>\n\n\n\n

I f\u00f8lge kaosrapporten, som ofte siteres, mislykkes rundt 30 prosent av alle programvareprosjekter. Det betyr at enten prosjektvarigheten blir for lang eller at budsjettet ikke blir holdt.<\/p>\n\n\n\n

Her noen utfordringer i programvareprosjekter:<\/p>\n\n\n\n

1) Vanskelig \u00e5 sjekke de n\u00f8yaktige kravene<\/strong><\/h3>\n\n\n\n

Hvis du vil bygge et spesialbygget stort hus, kan en pris bare fastsettes hvis alle deler av arbeidet er riktig vurdert. Opp til den siste skruen, som skal brukes.<\/p>\n\n\n\n

Arkitekten vil lage en plan med en n\u00f8yaktig plan, der hele huset replikeres enten p\u00e5 papir eller ofte i dag som 3D-modell. Og i disse programmene kan det beregnes hvor mange skruer osv. Som skal til for \u00e5 bygge huset.<\/p>\n\n\n\n

Med denne informasjonen er det mulig \u00e5 gi et n\u00f8yaktig estimat for husbyggingsprosjektet.<\/p>\n\n\n\n

Men vi vet ogs\u00e5: I veldig store byggeprosjekter er prisantydningene vanligvis ikke riktige. Og det som skulle koste 500 millioner euro, vil til slutt koste 5 milliarder euro eller mer. Berlin lufthavn, Elbphilharmonie i Hamburg og sentralstasjonen i Stuttgart, Tyskland er tre eksempler, i de fleste tilfeller ble kostnaden redusert med en milliard euro eller mer.<\/p>\n\n\n\n

For sentralstasjonen i Stuttgart var gebyret for arkitekten rundt 36 millioner euro. Selv om arkitekten fikk betalt et s\u00e5 h\u00f8yt bel\u00f8p. Prosjektets kostnadsberegning ble redusert med rundt 1 milliard euro.<\/p>\n\n\n\n

Lignende utfordringer kan sees i programvareprosjekter.<\/p>\n\n\n\n

Spesielt n\u00e5r ikke-tekniske personer er involvert i \u00e5 videreformidle kravene til programvaren eller webprosjektet. Vanligvis vil prosjektbeskrivelsene bare ha noen f\u00e5 linjer i en e-post. Eller en telefonsamtale der den n\u00f8dvendige l\u00f8sningen er beskrevet.<\/p>\n\n\n\n

Noen eksempler p\u00e5 nettsteder vil bli gitt som referanse. Ikke sjelden har disse eksempler p\u00e5 nettsteder blitt bygget over mange \u00e5r og kostet hundretusenvis av euro, noen ganger millioner.<\/p>\n\n\n\n

Men budsjettet for webapplikasjonen eller programvarel\u00f8sningen vil v\u00e6re rundt 4’000 til 40’000 Euro, og det skal bygges innen 2 m\u00e5neder, maksimalt 3 m\u00e5neder. (Dette er \u00f8nsket vanligvis av ikke-IT-personen som sp\u00f8r om prisen).<\/p>\n\n\n\n

Virkeligheten er denne: Uten et detaljert foresp\u00f8rselsdokument fra klienten, som vil v\u00e6re rundt 10 til 50 sider og et detaljert forslag opprettet av IT-selskapet, basert p\u00e5 det etterspurte dokumentet, kan en pris for prosjektet ikke fastsettes.<\/p>\n\n\n\n

Og selv om det er et eksakt forslagsdokument. Vanligvis endres kravene i l\u00f8pet av prosjektet, noe som gj\u00f8r denne \u00f8velsen med \u00e5 lage forslag, som kan ta uker, en un\u00f8dvendig oppgave.<\/p>\n\n\n\n

2) Endring av krav underveis i prosjektet<\/strong><\/h3>\n\n\n\n

Det er nesten ikke noe IT-prosjekt, der det opprinnelig siterte programvareprosjektet forblir det samme under prosjektet.<\/p>\n\n\n\n

\u00c5rsaken er at kun n\u00e5r programvaren begynner \u00e5 f\u00e5 form, klienten innser at det mangler noen viktige ting, uten som prosjektet ikke kan lykkes, og programvaren ikke vil hjelpe forretningsprosessene.<\/p>\n\n\n\n

Men hva om det er avtalt en fast pris? Hvordan kan IT-tjenesteleverand\u00f8ren tillate endringer under prosjektet. Dette er nesten umulig, for da vil IT-tjenesteleverand\u00f8ren ikke tjene noe overhodet.<\/p>\n\n\n\n

P\u00e5 den andre siden vil klienten insistere p\u00e5 den faste prisen og si at \u201cFor denne lille endringen er det ikke n\u00f8dvendig \u00e5 endre budsjettet. Denne foresp\u00f8rselen om liten endring kan du legge inn det f\u00f8rste tilbudet \u201d.<\/p>\n\n\n\n

Og her er vanligvis hvor dilemmaet starter. Denne diskusjonen om endringsforesp\u00f8rsler vil fortsette og fortsette. Og prosjektet vil bli sittende fast.<\/p>\n\n\n\n

Dermed er det alltid bedre \u00e5 holde prosjektbudsjettet flytende. Der klienten betaler s\u00e5 mye, som programvareutviklingen krever. -> Selvf\u00f8lgelig kan dette virke «som en himmel for programvareselskapet» for klienten, fordi han \/ hun vil tro at de vil gj\u00f8re flere timer enn n\u00f8dvendig.<\/p>\n\n\n\n

Men sammenlign det med en restaurant. Hvis du bestiller en ekstra coca cola eller en ekstra biff, m\u00e5 du ogs\u00e5 betale for den ekstra tingen. Hvorfor skal det v\u00e6re annerledes i programvareutvikling? Spesielt innen IT der timepriser vanligvis er mye h\u00f8yere.<\/p>\n\n\n\n

3) Vanskeligheter med \u00e5 forst\u00e5 kompleksiteten i programvareutvikling av ikke-IT-personen<\/strong><\/h3>\n\n\n\n

Det er vanligvis veldig vanskelig \u00e5 forst\u00e5 for en ikke-IT-person \u00e5 forst\u00e5 kompleksiteten i programvareutvikling.<\/p>\n\n\n\n

«Min venn bygget dette nettstedet p\u00e5 en dag, og det har mange funksjoner. Hvorfor trenger du som ekspert mer enn 6 m\u00e5neder for \u00e5 utvikle disse funksjonene?»<\/i><\/p>\n\n\n\n

Mest sannsynlig brukte vennen noen Content Management System som WordPress eller Drupal og brukte noen standard plugins, som vanligvis gir mange funksjoner. Men dette er ikke tilpassede programvarel\u00f8sninger laget for vennen. Dette er systemer og plugins som brukes av vanligvis tusen og hundre tusen mennesker, som har lignende krav. Dette er ikke skreddersydde l\u00f8sninger.<\/p>\n\n\n\n

Men: \u00c5 bygge disse pluginene krevde sannsynligvis rundt 2 til 5 eller flere utviklere p\u00e5 heltid i flere m\u00e5neder eller til og med \u00e5r. S\u00e5 selv om vennen bruker tilsynelatende enkle l\u00f8sninger. De er opprettet i en veldig kompleks programvareutvikling.<\/p>\n\n\n\n

S\u00e5 i tilfelle klienten har noen krav som kan oppfylles av disse plugins og «ferdige l\u00f8sninger». Da er det bedre \u00e5 bruke dem. Men i de fleste tilfeller er ikke disse «ferdige» programvaresystemene det kunden krever.<\/p>\n\n\n\n

Det beste eksemplet er Googles s\u00f8kemotor. P\u00e5 fronten (det brukeren ser) er det bare en s\u00f8kefelt og to knapper. S\u00e5 en ikke-IT-person vil si «det kan bare ta en uke \u00e5 utvikle dette. Det er bare en s\u00f8kefelt og to knapper \u201d. I virkeligheten er det mange «skjulte» backend-funksjoner, som er utviklet av tusenvis og tusenvis av utviklere, og det gjennom mange \u00e5r.<\/p>\n\n\n\n

Avhengig av kompleksiteten, behovet for skalerbarhet etc. i klientprosjektet, kan programvareutviklingen ta mer tid enn forventet.<\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

Mulige l\u00f8sninger<\/strong><\/h3>\n\n\n\n

Det er noen l\u00f8sninger hvordan en ikke-IT-person kan n\u00e6rme seg henvendelsen til IT-tjenesteleverand\u00f8ren.<\/p>\n\n\n\n

1) Involver en programvareutvikler<\/strong><\/h3>\n\n\n\n

Ideelt sett ville det v\u00e6re en egen programvareutvikler eller IT-ekspert, som kunne kryssjekke estimatet fra IT-tjenesteselskapet.<\/p>\n\n\n\n

Vanligvis vil den programvareutvikleren r\u00e5de seg til \u00e5 holde prosjektomfanget fleksibelt, slik at endringer kan im\u00f8tekommes.<\/p>\n\n\n\n

Hvis estimeringen fra programvareselskapet er sannsynlig, vil programvareutvikleren gi gr\u00f8nt lys.<\/p>\n\n\n\n

P\u00e5 den m\u00e5ten, som en intern ansatt vurderer prosjektet, vil ikke-IT-personen ogs\u00e5 v\u00e6re overbevist om innsatsen som er involvert for utviklingen.<\/p>\n\n\n\n

2) Bruk av dedikert utvikler<\/strong><\/h3>\n\n\n\n

En dedikert utvikler, er en utvikler som blir gitt til klienten p\u00e5 heltid.<\/p>\n\n\n\n

Fordelen med dette er at utvikleren jobber tett med klienten og ogs\u00e5 med teamet til klienten. Dette \u00f8ker gjennomsiktigheten. Og klienten eller teamet kan stille sp\u00f8rsm\u00e5l og f\u00e5 svar i sanntid.<\/p>\n\n\n\n

Denne modellen fungerer p\u00e5 forskjellige m\u00e5ter:<\/p>\n\n\n\n