Andreas Åkesson Simen Trippestad Roger Ommedal. Ole Marius Thorstensen

Transkript

1 Presentasjon Tittel Gruppemedlemmer Arena Kundereskontro Ashkan Vahidishams Andreas Åkesson Simen Trippestad Roger Ommedal Gruppenummer 25 Oppdragsgiver Kontaktperson hos oppdragsgiver Intern veileder Kredinor SA Direktør Teknologi og Støtte, Ole Marius Thorstensen Tor-Morten Grønli Sammendrag Arena Kundereskontro skal utvikles som en selvstendig modul som kan implementeres i oppdragsgivers eksisterende system. Hovedoppgaven til modulen vil være å holde oversikt over alle økonomiske transaksjoner inn og ut av Kredinor, og hvordan disse regnskapsmessig posteres. I første omgang skal vi ha fokus på erstatte logikken i inkassosystemet, men det er et ønske at modulen skal være så generell at alle eksisterende forretningsområder skal kunne benytte denne på sikt. Alle transaksjoner må være sporbare og ellers oppfylle lovens krav til bokføring (ref. Bokføringsloven). Det skal arbeides tett mot Kredinors økonomiavdeling for å sikre at alle behov dekkes, det finnes ytterligere ønsker utover det som eksisterer i gammel løsning, vi vil søke å løse alt i ny modul. Dagens situasjon Kredinor har pr. i dag tre forskjellige kjernesystem som alle benytter sine egne metoder for å kontere og holde oversikt over transaksjoner. Kredinor er i en løpende prosess hvor det lages nytt system, og eksisterende løsninger flyttes bit for bit over i nytt system. I den sammenheng har de et ønske om å utvikle en ny modul for reskontroføringer, og det danner bakgrunnen for denne prosjektoppgaven. Dagens kjernesystem innenfor inkasso, K90, har vært utviklet over de siste 25 årene, og systemet gjør reskontroføringer på forskjellige måter i forskjellige deler av systemet. Det er derfor litt uoversiktlig og ikke alltid like enkelt å få en total oversikt, eller ha god nok sporbarhet for alle transaksjoner. For å kunne tilfredsstille lovens krav, og ha god dokumentasjon ved eventuelle tilsyn fra Finanstilsynet, så har vi derfor fått i prosjekt å utvikle en ny modul for slike reskontroføringer. Det er ønskelig at denne er så generell at de to andre kjernesystemene, Fakturaservice og Kundekonto, også kan benytte modulen på sikt.

2 Mål, rammebetingelser og løsning 1 Mål Lage en løsning som er generell for alle system. Tilfredsstille spesielle krav på tvers av de forskjellige systemene samtidig som løsningen er generell og uavhengig. Lage en generell databasestruktur som samtidig har mulighet til å behandle forskjellige system. Dersom vi lykkes vil vi gjøre drift og videreutvikling svært enkelt for sluttbrukerne av systemet. En gjenbrukbar løsning vil gjøre det mulig å ta modulen i bruk i ulike deler av systemet, ikke bare den delen vi fokuserer på. Dette vil spare bedriften penger, og gi de som skal overvåke systemet god oversikt. Utelatelse av en generell løsning vil gjøre modulen svært innskrenket og lite tilpasselsesdyktig. Bruk av modulen utenfor systemet vi tilpasser den til vil være vanskelig å implementere uten å gjøre store endringer i koden.

3 2 Mål Alle betalinger skal være sporbare gjennom hele systemet. Å kunne skille hvilket system de ulike transaksjonene tilhører. Knytte GUID til alle transaksjoner, slik at man enkelt finner tilbake til alle transaksjoner knytet til en gitt innbetaling. Lagre hvilket system en transaksjon tilhører for å gi økt sporbarhet. Sporbarhet vil gjøre en betaling enkel å følge, både under og etter utførelse av en transaksjon. Ved å gjøre alle betalinger sporbare gjennom hele systemet vil alle transaksjoner som er registrert i systemet være enkelt tilgjengelige. Sporbarhet er et grunnleggende bokføringsprinsipp og utelatelse vil derfor føre til brudd på bokføringsloven. Overholdelse av bokføringsloven står dessuten som krav fra vår oppgavegiver. Foruten de juridiske følgene vil utelatelse av sporbarhet gjøre systemet svært upraktisk. 3 Mål Betalinger(transaksjoner) skal alltid være i balanse. Sørge for at det aldri er avvik, altså at en transaksjon enten fullføres helt ut, eller ikke kommer inn i det hele tatt. All skriving til databasene skal utføres som transaksjoner. Håndtere feilsituasjoner som systemkrasj. Dersom systemkrasj forekommer midt under innlesing av en fil, skal systemet gjenoppta innlesing fra det punktet hvor krasjen oppstod. Ved å ha alle transaksjoner i balanse til enhver tid vil vi alltid ha et pålitelig system som kun viser transaksjoner som faktisk er gjennomført. Systemkrasj vil ikke ha store følger da innlesing vil kunne gjenopptas og fullføres uten å utelate viktig informasjon. Dersom vi ikke er nøye med å holde alle transaksjoner i balanse til enhver tid kan dette få alvorlige følger. Oppgaver som avbrytes (og dermed ikke fullføres) vil kunne markeres som utførte transaksjoner og skape ubalanse i store deler av systemet. Systemet vil være upålitelig da vi aldri kan være sikre på om loggført data er korrekt.

4 4 Mål Det skal ikke være lov å slette transaksjoner Hindre gjennomførte transaksjoner fra å slettes fra systemet Ikke gi mulighet for sletting i databasen. Dersom en postering er feil, skal den motposteres. Alle transaksjoner vil fortsatt være sporbare (krav #2), enten de er motpostert eller gjennomført. Dersom sletting av transaksjoner er mulig vil dette åpne dører for hvit-vasking av penger og potensiell ulovlig virksomhet. Det vil være mulig å skjule sine spor, noe som enkelt kan utnyttes på mange ulike sett. 5 Mål Følge gjeldende lover og forskrifter, ref. Bokføringsloven. Skaffe oversikt over alle lover og regler som er relevante i sammenheng med vårt system, og følge dem. Samarbeide tett med regnskapsavdelingen. Sette oss inn i Bokføringsloven og andre relevante regelverk på egenhånd. Ved å samarbeide med regnskapsavdelingen hos Kredinor vil vi enkelt kunne få tilbakemeldinger og veiledning. Så lenge systemet er plett-fritt og ikke står i strid med relevante lover og forskrifter vil systemet kunne tas i bruk i den offentlige sektoren. Dersom vi bestemmer oss for å blåse i de lover og forskrifter som står sentralt i forhold til vår oppgave vil modulen i verste fall ikke kunne bli tatt i bruk hos Kredinor. All tid og arbeid vil ha vært bortkastet, og løsningen vil være ubrukelig til det formålet den var utviklet til.

5 6 Mål Utvikle et system som gir god ytelse, også over tid. Forutse hvilke løsninger som er best på sikt, og som vil sørge for god ytelse over lang tid. Søke hjelp fra erfarne systemutviklere. Et solid system er et system som gjør jobben sin dag etter dag, år etter år. Dersom vi lykkes i å utvikle en god modul vil løsningen vår være i bruk i lang tid fremover uten at ytelsen reduseres betraktelig. Dersom vi ikke tenker forut vil systemet fort kunne utvikle seg til å yte dårlig, noe som kan gå utover resten av systemet og sørge for forsinkelser/ systemkrasj i mindre eller mer alvorlig omfang. Systemet vil kreve vedlikehold og modifikasjoner, noe som vil koste bedriften penger, og dersom ingenting kan gjøres vil modulen i verste fall byttes ut. Fordeler ved ny løsning Oppdragsgiver får en egen modul med ett enkelt og klart formål, nemlig å holde fullstendig oversikt over alle inn- og utbetalinger samt alle tilknyttede transaksjoner i alle systemer I organisasjonen. Det blir enkelt å hente ut informasjon ved behov. De slipper også risikomomentet med at denne koden ligger spredd utover I andre system, med faren for at den kan blir påvirket av andre endringer I disse systemene. Ulemper ved ny løsning Ved systemkrasj eller andre potensielle feil I modulen så vil alle systemer I organisasjonen som benytter kundereskontroen bli påvirket. Dette er et nytt risikomoment som de ikke har hatt før, siden systemene da var helt avskilt fra hverandre. Dette innebærer at vi må være svært påpasselige med å lage solid kode og sørge for at systemet fungerer 100 % før lansering. Programmeringsspråk Modulen skal programmeres i.net. Det blir også nødvendig å programmere mindre løsninger for testing av modulen, dette kan gjøres i valgfritt språk da det ikke skal brukes av oppdragsgiver i ettertid. Verktøy Programmeringen vil skje i Visual Studio, versjonskontroll i GitHub. Utviklingsmetode Med utgangspunkt i kravspesifikasjonen vil vi planlegge videre fremdrift I prosjektet. Det vil bli opprettet utviklingsoppgaver med underliggende deloppgaver, slik at vi enkelt kan utvikle mindre deler av prosjektet om gangen. Det gjør det også enkelt å se hva som er gjort og hvor mye som gjenstår. Vi kommer til å benytte smidig (SCRUM) utviklingsmetodikk, hvor utviklingen gjøres I mindre sprinter og legger klar til testing fortløpende. En sprint vil typisk vare en uke, og vi vil i ukentlige møter avklare oppgaver som skal utvikles I den neste sprinten, og tildele ansvarlig person. Verktøyet vi skal bruke er Trello. Vi vil ha hovedfokus på å utvikle kjernelogikken I den nye modulen,

6 men vil også prøve å få med eventuelle tilleggs ønsker som skulle dukke opp fra oppdragsgivers side underveis i prosjektet. Analyse av virkninger For oppdragsgiver vil det helt klart ha en positiv virkning å få samlet all logikk knyttet til inn- og utbetalinger i ett system, som tilfredsstiller den sporbarhet som er pålagt. Følgende fordeler vil oppnås: Alt samlet i en modul, i stedet for spredd over flere system. Det gjør det enkelt å vedlikeholde, endre og eventuelt feilrette systemet. Ved å flytte logikken ut av de kritiske kjernesystemene, så kan utviklingsressursene der benytte tiden sin på andre viktige oppgaver. Ressursen som har best greie på logikken i de gamle systemene er pensjonert, og man har derfor behov for å tilpasse dette i nyere teknologi. Ressurssparende å kunne vedlikeholde dette i ett system i stedet for i tre forskjellige system. Sikrer 100% sporbarhet, noe som er lovpålagt. Lett å ta ut rapporter som tilfredsstiller Finanstilsynets krav ved eventuelle tilsyn. Risikoanalyse : svært sannsynlig, sannsynlig, mindre sannsynlig, lite sannsynlig, usannsynlig. Konsekvenser: mindre alvorlig, betydelig, alvorlig, svært alvorlig 1 Uønsket Sykdom forekommer i gruppen. Kaldt vær, dårlig inneklima i arbeidsmiljøet. Arbeid tar lengre tid enn planlagt. Mindre alvorlig. Sannsynlig. Alle medlemmer gjør sitt beste for ikke å bli syk. Gruppemedlem som er mot formodning blir syke kan jobbe hjemme i den grad det lar seg gjøre.

7 2 Uønsket Ujevn arbeidsinnsats i gruppen. Ujevn arbeidsfordeling, ulike motivasjonsnivå, prioriterer andre ting, synes ikke oppgavene er interessante. Gruppen kan oppleve det som urettferdig dersom en/flere gruppemedlem bistår med mindre arbeid enn resten og oppnår samme resultat. Dette kan føre til utsettelser av arbeid og dessuten oppfattes det som en byrde for resten av gruppen. I verste fall kan det gå utover resten av gruppen ved at arbeidet ikke fullføres til planlagt tid, eller ved at resultatet ikke blir så bra som forventet. Betydelig. Gi gruppemedlem som oppfattes å yte dårlig beskjed om at dette må endres, og dersom arbeidsinnsats ikke forbedres tas det i verste fall kontakt med skolen for å ekskludere gruppemedlem fra gruppen på formelt vis. 3 Uønsket Prosjektet fullføres ikke. Gal beregning av tid, problemer underveis opptar mer tid enn forventet, gal prioritering av krav, gal rekkefølge av implementasjon. Resultatet kan bli et halvferdig prosjekt, en modul som ikke kan brukes av oppdragsgiver, som vil lede til dårlig karakter. Svært alvorlig. Planlegge fremgang så detaljert som mulig, forutse og kartlegge fremtidige milepæler og følge disse. Ha så mye som mulig klart før selve implementasjonen begynner, fordele arbeidsoppgaver fornuftig, spørre om veiledning dersom vi ser at det begynner å bli lite tid og arbeidsoppgavene fortsatt er mange.

8 4 Uønsket Systemet leverer ikke i henhold til kravspesifikasjonen. Tiden strekker ikke til, og man klarer ikke å utvikle en modul som leverer i henhold til kravspesifikasjonen. Andre årsaker kan være avsporing underveis, gal prioritering av krav (f.eks. ved at kjernefunksjonalitet kommer etter ekstrafunksjonalitet) og tekniske begrensninger. Systemet kan ikke tas i bruk selv om det er ferdig og levert i tide. Arbeidet må gis til andre, dersom ikke vi settes i arbeid for å fullføre jobben. Dette kan koste bedriften penger og tid, og i verste fall må de starte hele arbeidet på nytt. Svært alvorlig. Spesifisere kravspesifikasjon i samarbeid med oppdragsgiver, samarbeide tett med veileder i bedrift og i skole jevnlig under hele arbeidsprosessen, søke hjelp dersom vi er usikre på prioritering av rekkefølge noe skal implementeres i. 5 Uønsket Arbeid går tapt/ overskrives Naturkatastrofer, menneskeskapte katastrofer, klønete feil Utvikling må starte på nytt, alt arbeid går tapt og systemet kan ikke lengre leveres i tide i henhold til innleveringsfrist. Svært alvorlig Lite sannsynlig Dette unngås ved å ta backup flere steder underveis. Arbeid skal sjekkes inn i GitHUb/TFS kontinuerlig, og man bør også ta backup av det som ligger lokalt (til Dropbox).

9 6 Uønsket Eksisterende kode i systemet overskrives/slettes ved uhell Utdeling av rettigheter tillater tilgang kan gi tilgang til kritiske systemer og databaser. Dersom vi gis tilgang til oppdragsgivers systemer, og skriver over kode eller data der kan dette få store. Dersom filene ikke er lagret i backup og noen blir slettet/overskrevet av oss kan dette medføre svært store skader for bedriften. Svært alvorlig Lite sannsynlig Vi kommer ikke til å få tilgang til andre systemer eller databaser hos Kredinor. De har også backup av alt. 7 Uønsket Mangel på nødvendig kompetanse Oppgaven utfordrer på problem som ligger utenfor vår kompetanse. Vi er ikke i stand til å løse oppgaven på en slik måte at vi leverer god nok kvalitet til oppdragsgiver. Deler av systemet fullføres ikke, eller vi leverer et for dårlig produkt. Oppdragsgiver kan ikke bruke dette uten større tilpasninger/endringer. Mindre alvorlig. Sannsynlig. Det er bra at vi støter på nye problemer underveis som vi kan lære mye av, det vil utvikle og gi oss nyttig erfaring til senere. Dersom vi støter på utfordringer har vi tilgang til internett, veileder både i Kredinor (hvorav Øyvind har mange års erfaring med systemarkitektur/systemutvikling) og til vår veileder hos HIOA. Uansett problem vil vi mest sannsynlig få hjelp og finne ut av det.

10 8 Uønsket Utstyr ødelegges eller forsvinner. Gammelt utstyr slutter å fungere, glatt føre kan gi til uhell, andre ulykker, tyveri. Deler av gruppen kan stå uten mulighet til å bistå med arbeid, arbeid som befinner seg lokalt kan være tapt. Betydelig. Dersom det ikke lar seg gjøre å reparere ødelagt utstyr i tide tilbyr HIOA å låne ut utstyr til sine studenter. Arbeid kan fortsette som normalt. Dersom det ikke lar seg gjøre å gjenopprette arbeid som befinner seg på tapt hardware kan disse nås via skytjenester og public repositories gruppen benytter seg av dersom det er lagret der. Det er derfor viktig å lagre dokument og sjekke inn kode underveis. 9 Uønsket Arbeidsgiver avbryter oppgave. Bedriften Kredinor går konkurs, uforutsette r fører til at gruppen må avbryte arbeidet. Vi som gruppe står plutselig uten en oppgave å løse og må finne en ny i all hast. Dersom dette ikke lar seg gjøre og skolen ikke godkjenner fullføring av gjeldende oppgave må oppgaven gjøres på nytt neste år. Arbeidsgiver kan også være misfornøyd med vårt arbeid og leie inn noen andre til å ta seg av jobben i stedet for å kaste bort tid på oss. Svært alvorlig. Ved å forsikre oss om bedriftens lønnsomhet på forhånd kan vi forutse stabilitet i tiden vi skal gjøre vår oppgave. Ved å ta arbeidet seriøst og samarbeide tett med vår veileder i bedriften vil vi gi et positivt inntrykk av oss som gruppe.

11 10 Uønsket Gruppen greier ikke å sette begrensninger. Uenighet, ulike oppfatninger av prioritet og dårlig planlegging/ dårlig kravspesifikasjon. Dersom vi ikke blir enig om prioritet av oppgaver, eller ikke klarer å begrense omfanget av oppgaven vil vi mest sannsynlig ikke bli ferdig i tide. Dette kan føre til at vi leverer et halvferdig produkt, eller noe som er utenfor scope. Alvorlig. Ved å utrette en gjennomtenkt og detaljert kravspesifikasjon tidlig i prosjektet vil vi ha oversikt over den viktigste funksjonaliteten systemet skal inneholde.. Ved å ta beslutninger om prioritet før oppstart vil vi søke å unngå uenighet om dette senere i prosjektet.