{"id":11463,"date":"2021-06-30T16:05:37","date_gmt":"2021-06-30T14:05:37","guid":{"rendered":"https:\/\/www.software-developer-india.com\/saadan-vurderes-en-estimeret-softwareomkostning-for-ikke-tekniske-personer\/"},"modified":"2021-07-04T11:20:22","modified_gmt":"2021-07-04T09:20:22","slug":"saadan-vurderes-en-estimeret-softwareomkostning-for-ikke-tekniske-personer","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/da\/saadan-vurderes-en-estimeret-softwareomkostning-for-ikke-tekniske-personer\/","title":{"rendered":"S\u00e5dan vurderes en estimeret softwareomkostning (for ikke-tekniske personer)"},"content":{"rendered":"\n

S\u00e5dan vurderes en estimeret softwareomkostning (for ikke-tekniske personer)<\/h2>\n\n\n\n
\"\"<\/a><\/figure><\/div>\n\n\n\n

Det er ret sv\u00e6rt at evaluere et softwareprojekt og s\u00e6tte en pris p\u00e5 det.<\/p>\n\n\n\n

I artiklen nogle udfordringer, og hvordan man g\u00e5r frem til vurdering af softwareomkostningsestimater.<\/p>\n\n\n\n

Introduktion<\/strong><\/h3>\n\n\n\n

If\u00f8lge kaosrapporten, som ofte citeres, fejler omkring 30 procent af alle softwareprojekter. Det betyder, at enten projektets varighed bliver for lang, eller at budgettet ikke holdes.<\/p>\n\n\n\n

Her er nogle udfordringer i softwareprojekter:<\/p>\n\n\n\n

1) Vanskeligt at kontrollere de n\u00f8jagtige krav<\/strong><\/h3>\n\n\n\n

Hvis du vil bygge et specialbygget stort hus, kan en pris kun fasts\u00e6ttes, hvis hver del af arbejdet vurderes korrekt. Op til den sidste skrue, som skal bruges.<\/p>\n\n\n\n

Arkitekten opretter en plan med en n\u00f8jagtig plan, hvor hele huset replikeres enten p\u00e5 papir eller ofte i dag som 3D-model. Og i disse programmer kan det beregnes, hvor mange skruer osv. Der skal bruges til at bygge huset.<\/p>\n\n\n\n

Med disse oplysninger er det muligt at give et n\u00f8jagtigt sk\u00f8n over husbygningsprojektet.<\/p>\n\n\n\n

Men vi ved ogs\u00e5: I meget store byggeprojekter er prisestimaterne normalt ikke korrekte. Og hvad der skulle koste 500 millioner euro, koster 5 milliarder euro eller mere. Berlin lufthavn, Elbphilharmonie i Hamborg og hovedbaneg\u00e5rden i Stuttgart, Tyskland er tre eksempler, i de fleste tilf\u00e6lde var omkostningerne reduceret med en milliard Euro eller mere.<\/p>\n\n\n\n

For hovedbaneg\u00e5rden i Stuttgart var gebyret for arkitekten omkring 36 millioner euro. Selvom arkitekten fik betalt et s\u00e5 stort bel\u00f8b. Ansl\u00e5et projektomkostningsberegning var omkring 1 mia. Euro.<\/p>\n\n\n\n

Lignende udfordringer kan ses i softwareprojekter.<\/p>\n\n\n\n

Is\u00e6r n\u00e5r ikke-tekniske personer er involveret i at videregive kravene til softwaren eller webprojektet. Normalt vil projektbeskrivelserne kun f\u00e5 linier inde i en e-mail. Eller et telefonopkald, hvor den n\u00f8dvendige l\u00f8sning er beskrevet.<\/p>\n\n\n\n

Nogle eksempler p\u00e5 websteder gives som reference. Ikke sj\u00e6ldent er disse eksempelwebsteder bygget i mange \u00e5r og koster hundreder af tusind euro, undertiden millioner.<\/p>\n\n\n\n

Men budgettet for webapplikationen eller softwarel\u00f8sningen vil v\u00e6re omkring 4’000 til 40’000 Euro, og det skal bygges inden for 2 m\u00e5neder, maksimalt 3 m\u00e5neder. (Det er normalt \u00f8nsket fra den ikke-it-person, der sp\u00f8rger om prisen).<\/p>\n\n\n\n

Virkeligheden er denne: Uden et detaljeret foresp\u00f8rgselsdokument fra klienten, der vil v\u00e6re omkring 10 til 50 sider og et detaljeret forslag oprettet af it-firmaet, baseret p\u00e5 det forespurgte dokument, kan en pris for projektet ikke bestemmes.<\/p>\n\n\n\n

Og selvom der er et n\u00f8jagtigt forslagsdokument. Normalt \u00e6ndres kravene under projektet, hvilket g\u00f8r denne \u00f8velse af oprettelse af forslag, som kan tage uger, til en un\u00f8dvendig opgave.<\/p>\n\n\n\n

2) \u00c6ndring af krav under projektet<\/strong><\/h3>\n\n\n\n

Der er n\u00e6sten intet it-projekt, hvor det oprindeligt citerede softwareprojekt forbliver det samme under projektet.<\/p>\n\n\n\n

\u00c5rsagen er, at kun n\u00e5r softwaren begynder at f\u00e5 form, klienten genkender, at der mangler nogle vigtige ting, uden hvilke projektet ikke kan blive en succes, og softwaren ikke hj\u00e6lper forretningsprocesserne.<\/p>\n\n\n\n

Men hvad hvis der er aftalt en fast pris? Hvordan kan it-tjenesteudbyderen tillade \u00e6ndringer under projektet. Dette er n\u00e6sten umuligt, for da tjener it-tjenesteudbyderen slet ikke noget.<\/p>\n\n\n\n

P\u00e5 den anden side vil klienten insistere p\u00e5 den faste pris og siger, at \u201dFor denne lille \u00e6ndring er der ikke behov for at \u00e6ndre budgettet. Denne lille \u00e6ndringsanmodning kan du inds\u00e6tte i det oprindelige tilbud \u201d.<\/p>\n\n\n\n

Og her er normalt hvor dilemmaet starter. Denne diskussion om \u00e6ndringsanmodninger vil forts\u00e6tte og forts\u00e6tte. Og projektet sidder fast.<\/p>\n\n\n\n

S\u00e5ledes er det altid bedre at holde projektbudgettet flydende. Hvor kunden betaler s\u00e5 meget, som softwareudviklingen kr\u00e6ver. -> Selvf\u00f8lgelig kan dette virke “som en himmel for softwarefirmaet” for klienten, fordi han \/ hun vil tro, at de vil g\u00f8re flere timer end n\u00f8dvendigt.<\/p>\n\n\n\n

Men sammenlign det med en restaurant. Hvis du bestiller en ekstra coca cola eller en ekstra b\u00f8f, skal du ogs\u00e5 betale for den ekstra ting. Hvorfor skulle det v\u00e6re anderledes i softwareudvikling? Is\u00e6r inden for it, hvor timepriser normalt er meget h\u00f8jere.<\/p>\n\n\n\n

3) Vanskeligheder med at forst\u00e5 kompleksiteten af softwareudvikling af ikke-it-personen<\/strong><\/h3>\n\n\n\n

Det er normalt meget vanskeligt at forst\u00e5 for en ikke-it-person at forst\u00e5 kompleksiteten af softwareudvikling.<\/p>\n\n\n\n

“Min ven byggede dette ene websted p\u00e5 en dag, og det har mange funktioner. Hvorfor har du som ekspert brug for mere end 6 m\u00e5neder til at udvikle disse funktioner?”<\/i><\/p>\n\n\n\n

Mest sandsynligt brugte venen noget Content Management System som WordPress eller Drupal og brugte nogle standard plugins, som normalt bringer mange funktioner. Men dette er ikke brugerdefinerede softwarel\u00f8sninger lavet til venen. Det er systemer og plugins, der normalt bruges af tusindtusindvis af mennesker, der har lignende krav. Disse er ikke specialfremstillede l\u00f8sninger.<\/p>\n\n\n\n

Men: At bygge disse plugins kr\u00e6vede sandsynligvis omkring 2 til 5 eller flere udviklere p\u00e5 fuld tid i flere m\u00e5neder eller endda \u00e5r. S\u00e5 selvom veninden bruger tilsyneladende enkle l\u00f8sninger. De er skabt i en meget kompleks softwareudvikling.<\/p>\n\n\n\n

S\u00e5 hvis klienten har nogle krav, der kan opfyldes af disse plugins og “f\u00e6rdige l\u00f8sninger”. S\u00e5 er det bedre at bruge dem. Men i de fleste tilf\u00e6lde er disse “f\u00e6rdige” softwaresystemer ikke, hvad klienten kr\u00e6ver.<\/p>\n\n\n\n

Det bedste eksempel er Googles s\u00f8gemaskine. I frontenden (hvad brugeren ser) er der kun en s\u00f8gefelt og to knapper. S\u00e5 en ikke-it-person ville sige \u201ddet kunne kun tage en uge at udvikle dette. Der er kun en s\u00f8gefelt og to knapper \u201d. I virkeligheden er der mange “skjulte” backend-funktioner, som er udviklet af tusinder og tusinder af udviklere, og det gennem mange \u00e5r.<\/p>\n\n\n\n

Afh\u00e6ngigt af klientprojektets kompleksitet, skalerbarhed osv. Kan softwareudviklingen tage mere tid end forventet.<\/p>\n\n\n\n

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

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

Der er nogle l\u00f8sninger, hvordan en ikke-it-person kunne henvende sig til foresp\u00f8rgslen til it-tjenesteudbyderen.<\/p>\n\n\n\n

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

Ideelt set ville der v\u00e6re en intern softwareudvikler eller IT-ekspert, der kunne krydstjekke estimatet fra it-serviceselskabet.<\/p>\n\n\n\n

Normalt vil den softwareudvikler r\u00e5de til at holde projektets omfang fleksibelt, s\u00e5 \u00e6ndringer kan im\u00f8dekommes.<\/p>\n\n\n\n

Hvis softwarevirksomhedens sk\u00f8n er plausibel, giver softwareudvikleren gr\u00f8nt lys.<\/p>\n\n\n\n

P\u00e5 den m\u00e5de, som en intern medarbejder vurderer projektet, vil ikke-it-personen ogs\u00e5 v\u00e6re overbevist om indsatsen for udviklingen.<\/p>\n\n\n\n

2) Brug af dedikeret udvikler<\/strong><\/h3>\n\n\n\n

En dedikeret udvikler er en udvikler, der leveres til klienten p\u00e5 fuld tid.<\/p>\n\n\n\n

Fordelen ved dette er, at udvikleren arbejder t\u00e6t sammen med klienten og ogs\u00e5 med klientens team. Dette \u00f8ger gennemsigtigheden. Og klienten eller teamet kan stille sp\u00f8rgsm\u00e5l og f\u00e5 svar i realtid.<\/p>\n\n\n\n

Denne model fungerer p\u00e5 forskellige m\u00e5der:<\/p>\n\n\n\n