SkatteFUNN for programvare
Avgrens programvare og KI-forsøk fra utrulling og drift, med sammenlignbare tester, dataversjoner og sporbare kostnader.
På denne siden
En programvaresøknad bør forklare hva dere ikke vet hvordan dere skal løse, hvilken kjent kunnskap dere starter med og hvordan dere skal undersøke problemet. «Vi bygger en ny plattform» er ikke en tilstrekkelig problemstilling.
Fra kundekrav til en undersøkelse
Kunden ønsker raskere beregning. Teamet må først undersøke om kjent teknologi løser behovet. Dersom utfordringen faktisk krever nye undersøkelser, kan prosjektet beskrives med alternativer og målinger.
| Utsagn | Mer anvendelig grunnlag |
|---|---|
| Vi skal gjøre løsningen raskere | Definert last, referanse, responstid og korrekthetskrav |
| Vi skal bruke KI | Hva kjent metode ikke løser, og hva som må undersøkes |
| Vi skal lage integrasjoner | Hvilket uløst problem som går utover kjent implementering |
| Vi skal teste hos kunder | Hva testene undersøker og hvilke data de kan underbygge |
Forskningsrådets søknadsveiledning er styrende for den faglige beskrivelsen.
Når programvaren bruker kunstig intelligens
Bruk av en ferdig KI-tjeneste er ikke alene en FoU-utfordring. Beskriv begrensningen ved kjent metode og hva dere faktisk må undersøke. Et konstruert prosjekt vil redusere feil ved sjeldne hendelser. Modellen må sammenlignes med en definert referanse på samme, relevant testgrunnlag.
| Kontroll | Hva den beskytter mot |
|---|---|
| Skille mellom trenings- og testdata | At modellen ser testsvaret under utviklingen |
| Fast dataversjon og feildefinisjon | At en lettere test forveksles med en bedre metode |
| Resultat per viktig situasjon | At et godt gjennomsnitt skjuler alvorlige feil |
| Logg over modell og parametere | At et funn ikke kan gjentas eller forklares |
Fagpersonen velger forsvarlig opplegg. Testtilgang, personvern og nødvendige rettigheter må avklares før data deles. Første henvendelse til en rådgiver trenger ikke inneholde kundedata eller personopplysninger.
Databehandling kan også blande FoU og drift. Et konstruert skyuttrekk viser 30 000 kroner: 18 000 gjelder dokumenterte metodeforsøk og 12 000 vanlig kundeproduksjon. Bevar kjørespesifikasjon og fordelingsgrunnlag; ikke før hele kontoen fordi den brukes av utviklingsteamet. Hvilken del som kan inngå i skattekravet må vurderes etter kostnadsreglene.
Et arbeid som kan gi et negativt resultat
Et tenkt prosjekt sammenligner metode A og B på samme avgrensede testgrunnlag. Metode B er raskere, men gir feil svar i én viktig situasjon. Da har forsøket et dokumenterbart funn, selv om B ikke kan tas i bruk.
Forklar om funnet fører til nytt forsøk, justert mål eller stopp. Ikke bruk en senere demonstrasjon med andre data som om den bekreftet den opprinnelige testen.
Skill registreringene fra vanlig utvikling
Bruk en prosjektstruktur der utviklerne kan skille metodeforsøk, referanse og analyse fra kundesupport, vanlig feilretting og utrulling. Spor tid til faktisk aktivitet og kode-/testversjon. Sjekk Forskningsrådets krav til prosjektregnskap for timelister og dokumentasjon.
En måned med 160 tilgjengelige timer er ikke automatisk 160 prosjekttimer. Hvis 90 er kundeoppdrag, 45 forsøk og 25 administrasjon, må planen og registreringen vise det. Hvilke kostnader som kan inngå, må vurderes separat.
Gjør det lett å kontrollere søknaden senere
Bevar den godkjente prosjektbeskrivelsen og knytt arbeidspakkene til senere rapportering. Ved endret metode eller prosjektperiode brukes riktig endringsprosess. Fagpersonen bekrefter innholdet, økonomiansvarlig kontrollerer kostnadsgrunnlaget og revisorrollen avklares separat.
Bruk programvareguiden og arbeidspakker. Vese kan hjelpe med SkatteFUNN-søknaden.