Hovedprosjekt. Anvendt Datateknologi, Avdeling for ingeniørutdanning. Høgskolen i Oslo Våren 2010

Transkript

1 P R O S J E K T N R. 38 Hovedprosjekt Anvendt Datateknologi, Avdeling for ingeniørutdanning Høgskolen i Oslo Våren 2010 VARSLINGSSYSTEM FOR KONKURSER Tommy Alvestad s Jan Eric T. Gløpstad s Thomas Hage s Håvard Ostnes s D A T O:

2 PROSJEKT. NR 38 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKTETS TITTEL Konkursvarsling PROSJEKTDELTAKERE Håvard Ostnes s HOVEDPROSJEKT Jan Eric Torres Gløpstad s Thomas Hage s Tommy Alvestad s TILGJENGELIGHET Åpen DATO Telefon: Telefaks: ANTALL SIDER / BILAG 96 INTERN VEILEDER Kyrre Begnum OPPDRAGSGIVER Gruppen selv KONTAKTPERSON Håvard Ostnes SAMMENDRAG Oppgaven har gått ut på å utvikle et overvåkningssystem for næringslivet som skal varsle om konkurser. Systemet skal være enkelt, rimelig og effektivt, og resultatet er konkursvarsling.no som er blitt utformet etter kravspesifikasjonen som gruppen har utviklet. Systemet henter ned daglige kunngjøringer fra Brønnøysundregisteret, og registrerer dem i en konkursdatabase. Deretter settes det i gang prosesser som søker gjennom alle brukernes porteføljer og sjekker om det er noen av deres oppføringer som er gått konkurs. Denne kontrollen utføres ved å sammenligne organisasjonsnumrene i konkurstabellen mot brukernes porteføljer. Dersom det oppdages treff vil systemet varsle brukerne ved hjelp av SMS, e-post og med visuell varsling på nettsiden. Web-applikasjonen er utviklet ved hjelp av PHP, SQL, XML, Perl, HTML/XHTML og CSS, og som databaseverktøy er PHPmyAdmin og MySQL blitt benyttet. Apache web-server er benyttet som web-tjener i dette prosjektet. Dette prosjektet har vært svært omfattende, men det har vært god fremdrift underveis. 3 STIKKORD Konkursvarsling Web-Applikasjon Bedriftsovervåkning 2

3 Forord Denne rapporten tar for seg hvordan vi har jobbet i vårt prosjekt. Her vil vi fortelle om prosessen, hva vi har gjort og hvilke valg vi har tatt. Vi vil utdype og redegjøre for hvilke teknikker og metoder som er brukt for å komme frem til de ulike løsningene. Rapporten er skrevet for sensor, veileder og oppdragsgiver, samt andre som har interesse for å sette seg inn i vår arbeidsmetodikk. Den inneholder en del faglige uttrykk som krever visse kunnskaper innenfor forretnings- og dataområder. Prosjektet har vært omfattende, og arbeidsmengden har vært stor. Dette har resultert i at medlemmene har fått benytte alle de kunnskaper som er opparbeidet gjennom studiets tre år, og alle føler at de har fått bidratt på alle områder av prosjektet. Utfordringene har vært mange og interessante, og for å løse disse har gruppemedlemmene også opparbeidet seg ny kunnskap innenfor flere nye områder innenfor IT. Denne rapporten består av kapitlene introduksjon, bakgrunnskapittel, systemutviklingsmetode, kravspesifikasjon, design, prototyping, brukertesting, diskusjon og konklusjon. Vi ønsker å takke for samarbeidet med veileder Kyrre Begnum, og for det gode samarbeidet med Brønnøysundsregisteret som har opprettet en kostnadsfri brukerkonto for oss under definisjonen forskning. 3

4 Innholdsfortegnelse Forord Introduksjon Problemområde Problemstilling Milepæl og ansvarsfordeling Bakgrunnskapittel Finanskrisen Konkurser Vilkår for konkurs Virkninger av en konkurs Konkurs Case Det norske konkursregisteret Brønnøysundregisteret Konkursovervåkning Risikoanalyser Markedsundersøkelse Resultat fra markedsundersøkelse Nøkkelbegreper Gründerbedrifter på internett Markedet I dag Fremtiden Systemutviklingsmetode Agile Unified Process (AUP) AUPs Disipliner Valg av metode Kravspesifikasjon Oppbygging av kravspesifikasjonen Overordnet systembeskrivelse Abonnementtyper Rammekrav

5 4.5. Systemets funksjonelle egenskaper Logisk datamodell Krav til systemkonstruksjonen Krav til dokumentasjon Krav til manuelle funksjoner Design LAMP Utviklingsmiljø Detaljert systembeskrivelse Tilkoblinger Filbehandling Databaser Tilgangsrettigheter ACL Loggføring Sikkerhet Tabellstruktur Brukergrensesnitt Prototyping Maskinvare Programvare Systemfiler Tilkoblinger Filbehandling Databaser Loggføring Sikkerhet Prototypedesign Brukertesting Deltakere Resultat Diskusjon Systemutviklingen Prosess

6 7.3. Prototypen Samfunnsnytte Konklusjon Kilder Litteraturliste

7 Kapittel 1 1. Introduksjon Gruppemedlemmer Håvard Ostnes s haostnes@gmail.com Jan Eric Torres Gløpstad s janeric_torres@hotmail.com Thomas Hage s hagethomas@gmail.com Tommy Alvestad s ta@tomalv.com Veileder Kyrre Begnum kyrre.begnum@iu.hio.no Nettside Samarbeid i gruppen Prosjektgruppen har fungert som en Gründerbedrift og i dette prosjektet ønsker vi å utvikle et konkursvarslingssystem for næringslivet. Oppdragsgiver i prosjektet er gruppen selv. Gruppens medlemmer har erfaring fra prosjekter i alle 3 år av studiet Anvendt Datateknologi, og har i løpet av disse årene hatt et godt samarbeid i de forskjellige kursene som har vært avholdt. Mål for prosjektet Vårt hovedmål var å lage en konkursvarslingstjeneste på nett med e-post og SMS varsling. Ved å implementere SMS varsling kan brukeren også varsles dersom han ikke har e-post eller datamaskin tilgjengelig. Som egen oppdragsgiver har vi som mål å ha ferdigutviklet en fungerende prototype til skolens frist for levering av hovedprosjektet. 7

8 1.1. Problemområde Ikke siden det store børskrakket i 1929 har det vært registrert flere konkurser i Norge. Konkurser inntreffer ofte uventet og kan ha store ringvirkninger. Derfor kan rask og effektiv konkursvarsling bidra til å sikre arbeidsplasser, og bidra til at lokalsamfunn ikke mister viktige nøkkelbedrifter i kjølvannet av en konkurs. Finanskrisen har vist hvor sårbar verdensøkonomien er, og Norge er intet unntak. I Norge er det konkursregisteret som inneholder en komplett liste med alle konkurser, og siden registeret ble opprettet har det aldri før vært registrert et høyere antall konkurser i Norge som i Bedrifter taper også voldsomme summer dersom en av deres kunder eller leverandører går konkurs, og dette kommer av at næringslivet er langt mer sårbart enn før. Årsakene til dette skyldes økt konkurranse, høyere kostnader og lavere inntekter. Flere bedrifter har i løpet av 2009 fått føle effekten av de sterke svingningene i finansmarkedet ved at inntektene har sunket betraktelig, samtidig som utgiftene har økt. Klesbransjen er et eksempel på dette, hvor driftsmarginen til 41% av kjedebutikkene ligger på på under 1,5%. For de frittstående butikkene ligger marginen på rundt 0,9%, ifølge Reidar G. Mueller, bedriftsrådgiver i Hartmark Consulting AS. Dette viser hvor sårbare mange bedrifter er for å gå konkurs. (Dun & Bradstreet, 2009) Konkursvarslingssystemer er nyttige verktøy som gir bedrifter et viktig hjelpemiddel som kan brukes for å sikre sine verdier fra å gå tapt. Et varslingssystem som oppdaterer bedriften om viktige endringer i deres kundedatabase ved hjelp av mobiltelefon, e-post og internett gjør det enkelt for bedrifter å holde seg løpende oppdatert på konkurskunngjøringer. Slike varslinger vil gi bedriften særdeles viktig informasjon som er nødvendig for raskt å kunne innføre sikringstiltak som kan motvirke eller avverge de negative følgene av en konkurs. Slike sikringstiltak kan være at leverandører holder tilbake leveransen av varer og produkter, eller at man holder tilbake utbetalinger, og avslutter samarbeidet med konkursbedriften. Varslingssystemer for konkurser eksisterer allerede, men de er ofte dyre og kompliserte i bruk. Flere bedrifter velger derfor ikke å benytte seg av disse tjenestene, og utfører manuelle søk på Brønnøysundregisteret. Ved slike søk kan imidlertid problemer oppstå som en følge av menneskelig svikt, og integriteten til kundeporteføljen er dermed utsatt. Flere bedrifter oppretter ofte egne rutiner og setter av ansatte til denne oppgaven. 8

9 1.2. Problemstilling Hvordan varsle næringslivet på deres egne premisser om konkurser i deres portefølje på en enkel, rimelig, og effektiv måte? Vårt mål er å utvikle et varslingssystem som automatiserer og forenkler konkursvarsling. Dette systemet skal bli et nyttig verktøy for bedrifter som har behov for å vedlikeholde porteføljene sine, og som har behov for å benytte de ansatte på andre og mer pressende oppgaver. Slik kan systemet være med på å spare næringslivet for store lønnskostnader, og ringvirkningene av konkurser hvor underleverandører og kunder går konkurs. Viktige begreper Næringslivet er alle små-, mellomstore- og større bedrifter som har en portefølje de ønsker å overvåke. Premisser er ment å være de forutsetninger som en bedrift har vedrørende konkursvarsling. Dette omfatter alt fra selve varslingen, til vedlikehold av porteføljen som skal overvåkes. Spesialtilpasning av tjenesten kan være en forutsetning for flere bedrifter. Det er derfor ment å utvikle et fleksibelt system som skal ta hensyn til brukervennlighet og tilpasning. Konkurser er en rettslig framgangsmåte der boet til en betalingsudyktig blir beslaglagt og realisert, og utbyttet fordelt mellom fordringshaverne. Portefølje er en database som inneholder kundeinformasjon. I dette tilfellet bedriftsinformasjon som består av et firmanavn og et organisasjonsnummer. Enkel vil si at systemet er lettfattelig og brukervennlig, uten noe unødvendig tillegg. Rimelig vil si at systemet skal ligge i et billig til moderat prissjikte overfor systemeierne og kundene. Effektiv vil si at systemet skal utføre de oppgavene det er satt til å gjøre på en hensiktsmessig og praktisk måte. Varsel vil si å informere bedriften om endringer hos sin bedriftsforbindelse. I vårt tilfelle er det snakk om å informere en bedrift dersom en av deres forbindelser blir rapportert med en hendelse innenfor kunngjøringstypene konkursåpning, oppheving av konkurs, avslutning/innstilling/fortsettelse av bobehandling, tvangsoppløsning, oppheving av tvangsoppløsning, tvangsavvikling, oppheving av tvangsavvikling, 9

10 1.3. Milepæl og ansvarsfordeling En prosjektplan er en viktig del av planleggingsarbeidet, men planleggingen har også en annen viktig hensikt. Den skal gi oss en felles forståelse for de oppgavene vi skal utføre sammen. Det er gjennom denne planleggingen vi skal utvikle et felles syn på målene vi skal oppnå, og hvordan vi skal gå frem for å få til dette. Prosjektgruppen har laget en milepælsplan for å fastsette rammeverket for prosjektet, og denne er også et nyttig arbeidsverktøy for å vite hvordan man til enhver tid ligger an i prosjektets faser. Det avholdes jevnlige møter hvor det skrives møterapporter underveis. Rapportene hjelper til med å holde oversikt over situasjonen i prosjektet, og hver rapport skal kontrolleres opp mot prosjektplanen, og i tillegg til dette vil det skrives en rapport for hver milepælsavslutning slik at den avsluttede fasen kan evalueres. Dette er samtidig et nyttig hjelpemiddel for å kunne avdekke potensielle avvik og problemer som kan oppstå underveis. Dersom det ikke er progresjon i prosjektet er det viktig å treffe beslutninger som bringer det på rett spor igjen. Det er ikke uvanlig at en prosjektgruppe mislykkes i å følge milepælplaner og ansvarskart, og det er mange uforutsette begivenheter som kan inntreffe. Dersom man oppdager at planene ikke blir overholdt må den uheldige situasjonen vurderes, og nødvendige tiltak må iverksettes. God planlegging er viktig for å få konkrete kontrollpunkter underveis, noe som bidrar til å kunne redde seg inn fra potensielle krisesituasjoner som kan oppstå. Det er mange viktige oppgaver som skal utføres i et prosjektarbeid, og det er derfor svært viktig å ha en ansvarlig person for hver milepæl. Det å være arbeidsleder innebærer å fordele de konkrete arbeidsoppgavene, følge opp at oppgavene blir utført, og ha det formelle ansvaret for at milepælen blir nådd til rett tid. Selv om det er utnevnt en arbeidsleder for hver milepæl betyr det ikke at vedkommende skal ha ansvaret for alt selv, men han skal arbeide for at hver enkelt gjør jobben han er satt til å utføre. Det finnes en detaljert milepælsplan med ansvarsoversikt i vedlegg C i prosjektrapporten. Denne oversikten inneholder navn på de som har ansvaret for de forskjellige fasene i prosjektet. 10

11 Kapittel 2 2. Bakgrunnskapittel Dette kapittelet setter fokus på hvordan behovet for konkursvarsling har vokst fram, sett i lys av finanskrisen. Bakgrunnsinformasjon om finanskrisen, og hvordan konkurser påvirker næringslivet vil også komme fram i dette kapittelet. Kapittelet vil så godt det lar seg gjøre forsøke å forklare viktige uttrykk brukt i prosjektet slik at det ikke skal være nødvendig med avanserte forkunnskaper for å kunne sette seg inn i rapporten. En introduksjon av Brønnøysundregisteret er også inkludert, da meningen er å vise troverdigheten denne tjenesten har overfor næringslivet, samt dens mange samfunnsnyttige funksjoner. De eksisterende konkursvarslingssystemene beskrives nærmere sammen med en beskrivelse av hvem disse leverandørene er. Leseren vil i dette kapittelet få et blikk på dagens situasjon vedrørende konkursvarslingstjenester, og mer om veien inn i fremtiden for disse Finanskrisen Det var i årene en mørk periode for verdens finansielle system, og da spesielt med tanke på banker og andre finansforetak. Det startet som en bankkrise som endte med flere bankkonkurser i blant annet Danmark og Island, og andre land som ikke var sikret ved omfattende bankreguleringer. Finanskrisens kjennetegn var at flere verdipapirer ble priset for høyt, samtidig med at investorene påtok seg for stort ansvar uten å ta seg betalt tilsvarende for den risikoen som de utsatte seg for. Mange av investorene var forretnings- og investeringsbanker, og i tillegg visse former av fond. Figur 1 Finanskrisen _g61-money_ball_p12070.html Det første tegnet på at noe var alvorlig galt var relatert i misforholdet mellom reelle og noterte verdier i gjeldspapirer knyttet til amerikanske boliglån, og da i første rekke såkalte subprime-lån. Dette misforholdet førte til at deler av det internasjonale finansmarkedet brøt helt sammen i høsten 2008 fordi investeringsbankene kviet seg for å låne ut penger til hverandre. I de landene som hadde omfattende bankregulering og sikringskrav, som Norge og Sverige, 11

12 gikk ingen banker konkurs. I USA derimot, gikk et stort antall banker konkurs, og Islands økonomi ble knust. På senhøsten det samme året gikk verdensøkonomien for alvor inn i en generell nedgangskonjunktur, og dette er muligens den største siden den store depresjonen på tallet. I flere land gikk det offentlige inn med såkalte redningspakker for å forbedre den mørke situasjonen. I Norge gjennomførte Regjeringen og Norges Bank flere tiltak for å innføre en mer ekspansiv penge- og finanspolitikk, deriblant lavere rente. Dette ga nordmenn mer penger å rutte med, og sikret samtidig at næringslivet med sine mange arbeidsplasser og store verdiskapning ikke ble rammet av et stort antall konkurser. (Wikipedia, Finanskrisen, 2010) 2.2. Konkurser En konkurs er et juridisk begrep som innebærer at fordringshavere som har utestående hos en skyldner tar beslag i alle eiendelene og realiserer verdiene gjennom salg av disse. Det er Tingsretten som behandler konkurser, og de lover og regler som regulerer dette finner man i Konkursloven. Ved konkursåpningen er det bobestyreren som blant annet tar kontroll av bedriftens Figur / bankkonti og sørger for forvaltningen av den konkursrammedes eiendeler. Det er ni forskjellige kunngjøringstyper fra Brønnøysund som omfatter konkurser, og disse er: Konkursåpning Oppheving av konkurs Avslutning/Innstilling/Fortsettelse av bobehandling Tvangsoppløsning Oppheving av tvangsoppløsning Tvangsavvikling Oppheving av tvangsavvikling 12

13 2.3. Vilkår for konkurs Er noen insolvent - det vil si at en ikke er i stand til å innfri sine økonomiske forpliktelser etter hvert som de inntreffer - er ett av vilkårene for konkurs blitt oppfylt. (Wikipedia, Insolvens, 2010) Dette inntreffer når vedkommendes faktiske og fremtidig forventede inntekter ikke er tilstrekkelig for å kunne dekke løpende utgifter. Noe som også kalles illikviditet. Det er også et krav at vedkommende ikke kan dekke de løpende utgiftene ved å selge sine aktiva (eiendeler av verdi). For at det nå skal kunne åpnes en konkurs må det i tillegg ha kommet inn en rettsbegjæring om konkursåpning. Selv om man også kan slå seg selv konkurs, er det vanligst at denne begjæringen kommer fra en fordringshaver. Det er viktig å få fram at det i visse tilfeller også kan være straffbart å unnlate å slå seg selv konkurs dersom den økonomiske situasjonen er prekær, og at man dermed burde forstått dette Virkninger av en konkurs Det er spesielt viktig å merke seg at ved en konkurs hvor det er snakk om et selskap (AS) vil bortfall av restgjeld etter konkursen falle bort da selskapet i realiteten ikke lenger eksisterer. Dermed er det ikke lenger noen å rette kravene mot. Et eksempel på dette er når en leverandør går konkurs, og i tillegg ikke har noen verdier i boet. Nå har ikke leverandørene noen mulighet for å kunne hente ut noen verdier fra selskapet, da gjelden har falt bort. I slike tilfeller kan det nevnes konkursen i bedriften Dataimport i 1995, hvor 52 kreditorer hadde en totalgjeld på 14 millioner kroner (1995 verdi), og hvor boet disponerte en bankkonto med knappe kr. -- Lønnsgarantifondet, bobestyrers salær og andre fortrinnsberettigede massekrav spiser opp pengene flere ganger. Øvrige kreditorer har neppe noe å hente, sier en nøktern Torstein Røed. (Rønningen, 1995) Kreditorene så ingenting av pengene sine, og måtte innfinne seg med tapene de var påført. Unntak gjelder dersom det er snakk om et ANS (ansvarlig selskap), eller andre selskapsformer hvor deltakerne har påtatt seg et personlig ansvar for selskapets forpliktelser. I slike selskapsformer vil deltakerne selv hefte for gjelden inntil den foreldes eller faller bort på andre måter Konkurs Case Bedriften Sprudlevann AS er et lokalt bryggeri som baserer mye av omsetningen sin på faste kunder. En av de største kundene er en årlig sommerfestival, og bestillingen utgjør en livsviktig del av omsetningen til bedriften. 13

14 Festivalen har sendt inn sin årlige bestilling, og ved en standard kredittsjekk finner ikke Sprudlevann AS noe negativt som skulle tilsi at festivalen kan gå konkurs. Tiden går, og bryggeriet har produsert drikkevarene til sommerfestivalen og sendt varene som avtalt. Det bryggeriet ikke visste var at arrangøren hadde brukt opp selskapets egenkapital, og i tillegg hadde tatt opp et større lån kort tid før arrangementet ble avholdt. Denne forverringen i den økonomiske situasjonen førte til at en annen leverandør sendte inn en konkursbegjæring, men på tross av dette ble drikkevarene solgt. Først en uke etter sommerfestivalen hadde blitt avholdt kom nyheten om konkursen ut i media, hvorpå den slo ned som en bombe blant leverandørene og lokalsamfunnet. Leverandørene ble til kreditorer, og ønsket omgående å sikre seg verdier i boet slik at de kunne få dekket tapene mest mulig som en følge av konkursen. Dessverre viste det seg også at straks festivalen ble avsluttet hadde den ansvarlige overført salgsinntektene til en hemmelig utenlandsk bankkonto. Sprudlevann AS hadde tatt seg opp et lån for å ansette flere arbeidere, og anskaffet mer råvarer enn de vanligvis gjorde. De havnet nå i en situasjon hvor de hadde tapt millioner av kroner, og de stod nå selv i fare for å bli slått konkurs, og et titalls arbeidsplasser var i fare. Hadde Sprudlevann AS fått varsling om konkursen før festivalen hadde blitt avholdt kunne de sikret seg ved stoppe leveransen av varene, eller hente dem tilbake før arrangementet var i gang. Dersom bryggeriet hadde hatt tilgang på et konkursvarslingssystem ville konkursmeldingen blitt meddelt på et tidligere tidspunkt, mest sannsynlig før festivalen, og drikkevarene kunne blitt solgt til andre av bryggeriets kunder. Dermed hadde de kunnet unngå store deler av tapene de nå hadde blitt påført Det norske konkursregisteret I Norge er det konkursregisteret som inneholder opplysninger om konkursbo og tvangsavviklinger som er åpnet etter 1. september Registeret ble opprettet for å avdekke og bekjempe økonomisk kriminalitet, og både bobestyrere, politi, domstoler og andre interesserte kan skaffe seg viktig informasjon her. I tillegg kan man også kontrollere om noen er ilagt konkurskarantene via tingsretten. En slik karantene ilegges dersom en person med skjellig grunn mistenkes for å være i befatning med en straffbar handling i forbindelse med konkursen, eller virksomheten som førte til konkursen. Tingretten kan også ilegge konkurskarantene dersom den finner en person uskikket til å drive en virksomhet i form av å stifte, være varamedlem, styremedlem eller daglig leder i et nytt selskap. 14

15 Informasjonen om en konkurs ligger offentlig tilgjengelig i fem år fra konkursavslutningen, og for å få tilgang til denne må du ha et organisasjonsnummer eller et fødselsnummer. På Brønnøysundregisterets nettside ligger også konkursopplysningene fritt tilgjengelig for søk i opp til ett år for personkonkurser og tre år for selskaper Brønnøysundregisteret For å bidra til økonomisk trygghet, effektivitet for næringslivet og samfunnet generelt ble Brønnøysundregistrene opprettet som en forvaltningsetat med ansvar for en rekke nasjonale kontroll og registreringsordninger for næringslivet. Historie Figur 3 Brønnøysunds Lokaler Selv om Brønnøysundregisteret er en ung institusjon har den likevel røtter som går tusen år tilbake. Dette kommer av at man allerede i vikingtiden hadde tradisjon for at viktige kunngjøringer ble foretatt hver gang alle var samlet til ting. Selv om det er store teknologiske og praktiske forskjeller fra den gang har hensikten med tinglysing alltid vært den samme, nemlig å gjøre det allment kjent at det var etablert et rettsforhold. I tillegg til denne tradisjonen har det også vært vanlig med godkjenning og kunngjøring av foretaksnavn og foretak i Norge. I 125 år har det eksistert en ordning som har endret seg lite frem til i dag. Serviceorgan Brønnøysundregisteret er svært bevisste over sin samfunnsmessige funksjon som nødvendig kontrollorgan og myndighetsutøver, og også som et nyttig serviceorgan for hele næringslivet. Deres Enhetsregister og Oppgaveregister er brukt som mønster for stadig flere land som ønsker å redusere byrden det er for næringslivet å rapportere overfor offentlige myndigheter. Når det kommer til registerdrift kommer Brønnøysundregisteret i verdenseliten, og de har som målsetting å beholde denne posisjonen. Samordning Næringslivets oppgaveplikter er omfattende, og av hensyn til spesielt små og mellomstore bedrifter gjør Brønnøysundregistrene et viktig arbeid for å samordne dette best mulig. Målet er å redusere overflødig innsamling og registrering av opplysninger, og derfor sammenlignes det fortløpende hva slags typer spørsmål etatene sender ut i sine skjemaer. Dersom de samme spørsmålene stilles flere ganger vil etatene samarbeide for å se på mulighetene for å 15

16 stille samme spørsmålet bare en gang. Dette samarbeidet mellom etatene er også lovpålagt av Oppgaveregisterloven. Sentral datakilde Mange bedrifter opplever mengden av registreringer og rapporteringer som en byrde, men det gir også positive effekter. På bakgrunn av alle registreringer og rapporteringer som utføres er Brønnøysundregistrene ett av Norges største lager av elektroniske data. Her kan mange forsyne seg av viktige data av ulike årsaker, og de aller fleste av oss har vært i kontakt med registrene i en eller annen sammenheng. Enten man er bedriftsleder, bruktbilkjøper, enkeltperson, journalist eller långiver, for å nevne noen, kan man få tilgang til mye av informasjonen som er lagret her. Mange registre De fleste av oss er uvitende om at Brønnøysundregisteret består av en stor mengde forskjellige statlige elektroniske registre. Løsøreregisteret, Foretaksregisteret, Regnskapsregisteret, Oppgaveregisteret, Enhetsregisteret, Konkursregisteret og Ektepaktsregisteret er noen av de viktigste. Gebyrsentralen som er ansvarlig for registrering av billag og fakturering i forbindelse med tvangsoppløsninger har også tilholdssted her. De administrerer også Jegerregisteret for Direktoratet for naturforvaltning, som er et register over jegere som har kvalifisert seg for å drive jakt i Norge. Henvendelser Den avanserte data- og informasjonsteknologien som er en integrert del av Brønnøysundregisteret gjør at de raskt registrerer og oppdaterer alle sine opplysninger, og som en følge av dette oppstår det tusenvis av henvendelser daglig både på telefon, datafon og via online tjenester. De mange opplysningene som finnes på ett sted gjør at man får raskt svar på sine spørsmål dersom man tar kontakt, noe som forsterker Brønnøysundregisterets samfunnsnyttige funksjoner. Alle de viktige funksjonene til de forskjellige registrene skal bidra til å skape et bedre og ryddigere forhold i næringslivet, og Brønnøysundregisteret lever etter regelen om at åpenhet og oversikt er med på å motvirke økonomisk kriminalitet. De hevder også at pålitelig og saklig informasjon gir økonomisk trygghet, og at god service er et nøkkelord i deres daglige virke. (Brønnøysundsregisteret, 2010) 16

17 2.8. Konkursovervåkning Næringslivet har vært spesielt hardt presset de siste årene, og mye av dette presset skyldes finanskrisen. I kjølvannet av krisen har det vokst fram tilbydere av ulike varslingssystemer som varsler om forskjellige typer endringer i bedrifters kundeportefølje. Tilbudet av leverandører har ikke eksplodert de siste årene, men det merkes at markedet for denne type tjenester har våknet. Figur 4 People_g201-Search_p9680.html Risikoanalyser En stadig større trend i bedriftsmarkedet er å ha større fokus på risikoanalyser av sine kundeporteføljer. Det er oftest de store selskapene som er vinnerne fordi de sitter med størst kapital og har råd til egne risikoteam som tar seg av regelmessige evalueringer av sine porteføljer. Mye av ekspertisen som finnes i markedet bygger ofte på å ha ansatt en riskmanager med bred erfaring og kunnskap i avanserte analyser av økonomi og bedrifter, i tillegg til omfattende kjennskap til bedriftens kundeportefølje. Bedrifter som ikke har råd til å ansette en riskmanager, eller sette sammen en riskgruppe er ofte små banker, netthandelsbedrifter, samt nystartede selskaper som ikke har etablert økonomi. Det er ofte denne type bedrifter som rammes hardest av negative endringer hos sine bedriftsforbindelser. På bakgrunn av dette ser det ut til å ha vokst fram et behov for rimelige varslingssystemer da dagens systemer er dyre og kompliserte. Spesielt vil dette være gunstig for det mindre til mellomstore bedriftsmarkedet som for en rimeligere sum kan varsles om viktige endringer i sin kundeportefølje Markedsundersøkelse Markedsundersøkelsen er et innledende arbeid i vårt hovedprosjekt hvor det skal komme frem hvilke tilbydere som finnes i markedet, og hva slags tjenester de tilbyr. Annen relevant informasjon som priser, funksjoner, praktiske løsninger og lignende skal inkluderes i denne undersøkelsen. Formålet med denne markedsundersøkelsen er å kunne isolere tilbyderne av slike tjenester ned til en kortfattet og oversiktlig rapport. Resultatene skal brukes til å utarbeide en kravspesifikasjon som skal gi vårt eget produkt en fordel i forhold til de andre tilbyderne på markedet. Vi ønsker å isolere konkursvarslingstjenester i denne markedsundersøkelsen og ser bort fra tilleggstjenester som finans- og regnskapsopplysninger. Informasjonen som innhentes i 17

18 undersøkelsen innhentes fra tilbydernes hjemmesider eller ved hjelp av direkte kontakt som f.eks e-post og telefon. Informasjonsinnhentingen ble påbegynt i uke og avsluttes i uke Det settes av ca 3 uker til markedsundersøkelsen, noe som anses som tilstrekkelig for den mengde informasjon som skal innhentes. Hver av tilbyderne som undersøkes blir presentert med firmanavn og URL til hjemmeside, samt utfyllende informasjon om deres tjenester. Forvalt.no Hjemmeside: Kontaktinfo: Olaf Helsets vei Oslo Kontortid: E-post: forvalt@proff.no Telefon: Tilbyr: Motta e-post dagen etter at en bedrift har gått konkurs. Forvalt.no tilbyr overvåking av alle konkurser i en spesiell bransje eller region, og dersom en bedrift eller organisasjon skulle gå konkurs vil du få melding via epost dagen etter. De benytter følgende registere for sine opplysninger: Brønnøysudregisteret, Inkassobyråene, Cyberwatcher, Statistisk sentralbyrå og Eniro. De har også tre forskjellige løsninger på overvåking: Mini, Basis og Plus, der overvåkingsmodulen er inkludert i basis og plus. Overvåkingsmodulen er inkludert i Basis og Plus, og prisen på den rimeligste overvåkningspakken starter på 6500,- eks.mva. Proff Forvalt leverer også skreddersydde løsninger tilpasset intranett / pool-løsninger. Forvalt Mini kr. 3900,- eks.mva Forvalt Basis kr. 6500,- eks.mva Forvalt Plus kr. 7900,- eks.mva Excel-export muligheter. 18

19 Dun & Bradstreet Hjemmeside: Kontaktinfo: Kundeservice Telefon: E-post: Tilbyr: «Alarm-overvåkingen er en nyhet som kan forebygge dramatiske tap!» D&B har øyeblikkelig alarmovervåkning som gir beskjed via e-post ved urovekkende endringer i et firma, de gir også mulighet for å ha flere porteføljer i samme overvåkningssystem. Dette betyr at forskjellige avdelinger i samme firma kan motta forskjellige varslinger basert på innholdet i de forskjellige porteføljene. Man legger selv til de organisasjonene/bedriftene man vil kjøre overvåkning på. D&B tilbyr også å utføre en behovsanalyse av deg slik at du kan få en løsning tilpasset dine behov. D&B tilbyr å legge utvalgte foretak til overvåkning, og motta e-postvarsling på ikke bare konkurser, men alle endringer i brønnøysund, som endring av daglig leder/styre/revisor, tvangsoppløsning, godkjent årsregnskap etc. Du kan selv administrere hvem som ligger til overvåkning, og i løpet av få sekunder har du lagt hele databasen til overvåkning. De utarbeider prisforslagene ved at de tar en gjennomgang av hvordan løsningen fungerer sammen med kunden, og tar da samtidig en behovsanalyse på potensielle kunder. Tilpasning av løsningen utføres, og en pris diskuteres. 19

20 Experian Hjemmeside: Kontaktinfo: Experian AS (Experian Credit Services) Postboks 5275 Majorstuen Sørkedalsveien 10 C 0303 Oslo Tlf.: Fax: E-post: kundesenter@no.experian.com Tilbyr: Experian tilbyr overvåkning ved at man legger inn sin kundeportefølje i deres database. Etter dette er gjort kan man logge seg inn på tjenesten og følge med på om det er oppstått endringer i kundeporteføljen. Hendelser som oppstår hos bedrifter vil være synlige i systemet straks Experian har lagt inn informasjonen. Experian anbefaler alarmovervåking, som gir beskjed fortløpende når det skjer alvorlige endringer som for eksempel konkurs, navneendring, betalingsanmerkninger og nedgang i ratingscore. Prisen på dette avhenger litt av hvor mange organisasjonsnumre som skal overvåkes. Normalt ligger dette på et sted mellom kr pr mnd, og man får da e-post varsel når det skjer endringer i kundeporteføljen. De har bindingstid på 1 år på dette abonnementet. Experian kan få tilsendt en fil med organisasjonsnumrene i Microsoft Excel, og kan lese denne filen inn i databasen sin. Slik kan de overføre alle sine foretak over til overvåkingsporteføljen. 20

21 Lindorff Hjemmeside: Kontaktinfo: Lindorff Decision Tlf: Fax: E-post: Tilbyr: Gjennom Lindorffs overvåkningsmodul varsles man fortløpende ved endringer i en kundeportefølje. Enten det gjelder nytt regnskap, betalingsanmerkninger eller endring i Decision Score gir Lindorff beskjed via e-post så snart endringen inntreffer. Lindorff hevder at man dermed unngår tap på krav, sparer tid og ressurser, og har til enhver tid full oversikt over faste kunder. Porteføljen administreres av kunden, og man kan fritt legge til/fjerne de kundene man ønsker å overvåke. Man får automatisk melding ved endring av følgende elementer i Lindorffs database: Decision-Score foretak, Fusjon/fisjon, Konkurs, Opphørsmelding, Slettemelding, Ikke levert regnskap, mottatt regnskap, Betalingsanmerkninger, Daglig leder, Styresammensetning, Selskapskapital/aksjekapital, Revisor, Foretaksnavn og Adresse. 21

22 Brønnøysundregisteret Hjemmeside: Kontaktinfo: Brønnøysundregistrene 8910 Brønnøysund Opplysningstelefonen: Administrasjonen: Telefaks: E-post Tilbyr: Tre ulike abonnementstyper: Spesifiserte organisasjonsnummer Spesifiserte fødselsnummer og/eller d-nummer Kunngjøringstype og/eller geografisk område Abonnement på spesifiserte organisasjonsnummer gir varsling når det blir foretatt kunngjøringer på spesifiserte organisasjonsnummer. Abonnement på spesifiserte fødselsnummer og/eller d-nummer (Altinn, 2010) gir varsling når det blir foretatt kunngjøringer på bestemte personnummer eller d-nummer. Disse to abonnementene lar deg maks overvåke 1000 numre per abonnement. Abonnement på spesifisert kunngjøringstype og/eller geografisk område gir varsler om alle kunngjøringer i for eksempel den kommunen du vil overvåke, eller kun varsling av bestemt kunngjøringstype. Brønnøysund leverer kun varsler pr. e-post. 22

23 2.10. Resultat fra markedsundersøkelse En vurdering av de nåværende tjenestene på markedet viser at alle overvåkingssystemene leverer varsler gjennom e-post. Alle tjenestene leverer varsler hver gang det skjer drastiske endringer i kundeporteføljen. De fleste systemene bruker Brønnøysundsregisteret som referanse til sine varsler og opplysninger, men ett av systemene bruker også flere andre registere som grunnlag for sine opplysninger. Alle systemene baserer seg på at man oppretter en portefølje med de organisasjonene man vil overvåke. Ingen av tjenestene tilbyr SMS varsling noe som gjør at for de som er på farten blir det vanskelig å holde seg oppdatert dersom det skulle oppstå endringer i porteføljen. I tillegg har de fleste tjenestene mengder av tilleggstjenester som ikke omhandler konkursvarsling, noe som betyr at man betaler for flere produkter enn hva man har behov for. Vårt system tilbyr varsling av alle kunngjøringstyper som omhandler konkurser, noe som betyr at brukerne vet hva de kan forvente av tjenesten. I tillegg er systemet planlagt utviklet med SMS styring av porteføljer. Dette betyr at brukere skal kunne legge til, og fjerne oppføringer i porteføljene ved hjelp av SMS Nøkkelbegreper I dette prosjektet blir det brukt en del begreper som ikke er kjent for de fleste. Her er en nærmere beskrivelse av disse. Næringsliv Dette er en betegnelse på den samlede økonomiske virksomheten i et land, eller innenfor et mindre område i et land. I dette prosjektet blir ordet næringsliv brukt som et begrep som omfatter alle små-, mellomstore- og større bedrifter som har en kundeportefølje de ønsker å overvåke. Klassifisering av næringslivet Det er normalt å klassifisere næringslivet i fire deler: Primærnæringer som fremstiller råvarer Sekundærnæringer som behandler råvarene Tertiærnæringer er næringer hvor produktet er en tjeneste. Typisk er disse tjenestene en formidling av produkter fra primær- og sekundærnæringer Kvartærnæringer er i økende grad tatt i bruk som en klassifisering av næringer som formidler kunnskap og informasjon. Dette er ofte næringer som omfatter ulike vekstområder innenfor IT, forskning og informasjonsinnhenting. 23

24 Premisser Næringslivet har forventninger og ønsker til konkursvarslingssystemer. Når vi i problemstillingen sier næringslivets egne premisser menes det de forutsetninger som bedriftene har vedrørende konkursvarsling. Dette innebærer at de stiller strenge krav til slike systemer, og dette kan omfatte integriteten på den leverte informasjonen, konfidensialiteten til kundeporteføljen, spesialtilpasning og pris av tjenesten, og supportmuligheter. Alle disse punktene, med flere, er ofte en forutsetning for flere bedrifter. Det er derfor viktig å utvikle et fleksibelt system som skal ta hensyn til kundenes behov og ønsker. Kundeporteføljer De fleste bedrifter i næringslivet holder oversikt over sine bedriftsforbindelser i en kundeportefølje. Dette er ofte parter som har en økonomisk forbindelse eller forpliktelse med bedriften, og av den grunn er samlet i en mappe eller database. Slike kundeporteføljer oppdateres regelmessig når ny informasjon dukker opp Gründerbedrifter på internett Konkursvarslingssystemet er en tjeneste som har mange fellestrekk med noen av de store populære tjenestene som Youtube, Facebook og ebay. Det kan derfor være nyttig å lese mer om hvordan disse startet, og hvordan de har utviklet seg til hva de er nå. I likhet med konkursvarslingssystemet startet de opp uten store investeringskostnader, med små lokaler og få ansatte. Selv med dette utgangspunktet endte de opp som noen av de viktigste merkenavnene på internett, og omsetter nå for milliarder av kroner i tillegg til å ha tusenvis av ansatte. Etter at internettet, the World Wide Web, som vi kjenner det i dag ble grunnlagt tidlig på 90 tallet dukket det sakte men sikkert opp en rekke tjenester som i løpet av kort tid ble verdt milliarder av dollar. Disse suksesshistoriene har mange fellestrekk med hverandre, og i dag er de fleste veletablerte merkenavn som har enorm omsetning og flere tusen ansatte. Det er viktig å lære av hvordan menneskene bak tjenestene kunne bli milliardærer nesten øyeblikkelig på noe så enkelt som å dele hjemmevideoer, holde kontakt med skolekamerater og å kunne selge sine eiendeler på nettet. De følgende sidene inneholder historien om hvordan Youtube, Facebook og ebay ble til. 24

25 Ebay Ebay er Amerikansk nettselskap som bestyrer ebay.com, en nettbasert auksjons- og shoppingnettside, hvor privatpersoner og bedrifter kan kjøpe og selge et bredt spekter av varer og tjenester fra hele verden. De fleste salg som utføres på tjenesten er i form av tidsstyrte auksjoner, men en stadig større del av salgene kategoriseres innenfor kjøp-nå kategorier. Figur 5 o.svg#filelinks Etter oppstarten i 1995 har de etablert seg med lokalkontorer i over tretti land, og de eier i tillegg betalingstjenesten PayPal som er en stor aktør i spesielt det amerikanske markedet for nettbaserte betalingstjenester. Historie 3. september 1995 ble en nettbasert auksjonstjeneste med navn AuctionWeb lansert av den franskfødte iranske dataprogrammereren Pierre Omidyar som en del av en større privat nettside han drev. I 1997 mottok han 5 million dollar oppstartskapital fra selskapet Benchmark Capital, og da var det hele i gang. Tidlig i 1996 ble Jeffrey Skoll ansatt som selskapets første president, og i november det samme året inngikk de en avtale om å selge flybilletter og andre reiseprodukter via nettstedet. Økningen i salgsvolum ble enorm, og i januar 1997 var auksjonstjenesten tilbyder av over auksjoner, sammenlignet med i hele Selskapet byttet offisielt navn til ebay i september I mars 1998 hadde selskapet 30 ansatte, en halv million brukere, og en omsetning på 4,7millioner dollar i USA alene. I september 1998 gikk selskapet offentlig, og både Omidyar og Skoll ble milliardærer over natta. I 2002 var selskapet blitt så stort at det begynte å kjøpe opp andre selskaper, deriblant PayPal, og en europeisk nettauksjonsside ved navn ibazar. Tidlig i 2008 hadde selskapet vokst seg ut over store deler av verden, hadde millioner av brukere, ansatte, og en omsetning på 7,7 milliarder dollar. De hadde også andeler i Skype, men solgte seg ned til 30% for en sum av 2,75 milliarder dollar. (Wikipedia, ebay, 2010) 25

26 Youtube Youtube er ett nettsted hvor brukere fritt kan dele filmsnutter og egenproduserte kortfilmer. Brukere som ikke er registrerte kan se på filmer mens de registrerte brukere kan laste opp ett ubegrenset antall videoer. Historie Figur 6 Nettstedet ble startet i februar 2005 av tre personer som tidligere var ansatt i PayPal. To av disse menneskene fikk ideen om å lage en enkel måte å dele video på etter at de hadde vansker med å dele videosnutter etter et middagsselskap. I 2006 ble Youtube kjøpt opp av Google, og drives nå som en tilleggstjeneste av selskapet. Youtube blir brukt mest av individuelle personer men større selskaper som CBS har også tatt i bruk teknologien, og er i dag ledende tilbyder av videodeling i USA. Det er beregnet at 20 timer med video blir lastet opp hvert minutt. (Wikipedia, YouTube, 2010) Facebook Facebook er et nettsamfunn som har blitt umåtelig populært de siste par årene. I begynnelsen av 2009 var det 1,5 millioner nordmenn på Facebook. Figur 7 Facebook er et sosialt nettverk der man oppretter en brukerprofil for å kommunisere med andre. Du trenger bare en gyldig e-post konto for å registrere deg. Du får tilgang til andre brukere ved å søke dem opp å sende dem en venneforespørsel. Hvis de godtar den så får du tilgang til profilen deres. På Facebook deles alt ifra status oppdateringer, videoer, bilder, interesser, personlig informasjon og andre applikasjoner som Facebook har utviklet i ettertid. Du har også muligheten til å se hvem som er online og snakke med dem. Facebook har nå blitt oversatt til en rekke språk etter ønske fra brukerne. Historie Nettstedet ble opprinnelig laget for at tidligere studenter kunne enklere holde kontakten. Det ble startet av Mark Zuckerberg med hjelp av noen med studenter i februar Facebook er reklamefinansiert og er gratis for brukeren. (VG, 2010) (Wikipedia, Facebook, 2010) 26

27 2.13. Markedet I markedsundersøkelsen som ble utført i forkant av prosjektet fant vi fram til 5 leverandører av konkursvarsling og bedriftsinformasjon. Det er ved en analyse av disse tjenestene at vi kan isolere de egenskapene som skal bli en del av kravspesifikasjonen for konkursvarslingssystemet vårt I dag Alle tjenestene tilbyr overvåkning av organisasjonsnumre i en portefølje, og leverer e- postvarsler dersom det inntreffer visse former for endringer. E-postvarslene inntreffer senest dagen etter at konkursen har blitt registrert hos Brønnøysund. Porteføljene kan opprettes enten ved at kundene legger inn kundene sine selv, eller at de sender inn en database av hele porteføljen slik at denne kan importeres direkte til overvåkningssystemet. Dette kan gjøres ved å legge inn alle kundene i et Excelark som oversendes til tjenesteleverandøren som så importerer denne. En av leverandørene tilbyr avdelingsbasert overvåkning, noe som innebærer at en kunde kan sende inn flere porteføljer for forkjellige avdelinger i bedriften. På denne måten får de forskjellige avdelingene varslinger som er relevante for deres behov. Oppdateringer om endring av daglig leder, styret, revisor, tvangsoppløsning, oppheving av tvangsoppløsning, tvangsavvikling, oppheving av tvangsoppløsning, avslutning av bobehandling, fortsettelse av bobehandling, konkursåpning og oppheving av konkurs med flere, er eksempler på tjenester som leveres i dag. Ett av systemene varsler også om endring av kredittrating, samt mer regnskapsrettet varsling. Dette er av typen ikke mottatt regnskap, mottatt regnskap, betalingsanmerkninger, selskapskapital/aksjekapital, revisorinformasjon, og endringer av foretaksnavn og adresser. Alle leverandørene tilbyr abonnementer på produktene sine, og da også med minimum bindingstid på 6 månder Fremtiden Basert på markedsundersøkelsen bør det ferdige systemet kunne tilby et minimum av tjenester som e-postvarsling av konkurser, tvangsoppløsninger, tvangsavviklinger, informasjon om bostyrer, administrering av portefølje via web, import av portefølje til database i Excelformat eller for eksempel kommaseparerte verdier, avdelingsbasert overvåkning (mulighet for flere porteføljer) og varsling til forskjellige e-postadresser. For å være konkurransedyktig er dette et minimum av tjenester som systemet bør kunne levere, og dette er også utgangspunktet for kravspesifikasjonen. 27

28 28

29 Kapittel 3 3. Systemutviklingsmetode Under arbeidet med å utvikle et produkt må vi hele tiden kunne skille klart mellom prosessene og selve produktet. Når produktet settes i drift avsluttes prosessen. Gjennom utviklingsprosessen fødes produktet. Ved hjelp av prosjektarbeidsformen styres prosjektutviklingsprosessen Agile Unified Process (AUP) Agile Unified Process(AUP) er en forenklet versjon av Rational Unified Process (RUP). Førstnevnte er en mer agil utviklingsmetode som lar utviklerne i større grad velge utviklingsverktøy enn hva som er tilfellet i sistnevnte. AUP beskriver en lettforståelig tilnærming til programvareutvikling til bedrifter ved hjelp av raske teknikker og konsepter selv om metoden fortsatt er nært beslektet RUP. Den anvender agile teknikker som inkluderer testbastert utvikling (TDD- test driven development), agilmodellering, fleksibel endringsbehandling og database design for å forbedre produktiviteten AUPs Disipliner AUP har syv disipliner. Den første disiplinen er modellen, hvor man må forstå forretningsområdet til næringslivet, problemområdet som prosjektet belyser, og identifiserer en mulig løsning for å løse dette problemet. Det neste er implementering, som innebærer å gjøre om modellene til kjørbar kode og utføre grunnleggende testing, og da spesielt enhetstesting. Testing hvor man utfører en objektiv evaluering for å forsikre kvalitet. Dette inkluderer å avdekke svakheter, validere at systemet virker som det tenkt, og verifisere at kravene er møtt. Neste steg er distribusjon hvor man planlegger systemleveransen og iverksetter planen for å gjøre det tilgjengelig for sluttbrukerne. Konfigurasjonsstyring er når man styrer tilgangen til prosjektartifaktene. Dette inkluderer ikke bare å holde oversikt over artifaktversjoner over tid, men også å kontrollere og behandle endringer i disse. Prosjektstyring innbærer å fordele aktivitetene i prosjektet. Dette inkluderer risikobehandling, tildeling av ansvar, og å koordinere med mennesker og systemer utenfor prosjektets omfang for å være sikker på at det blir levert innenfor tid og budsjett. Kårene for prosjektet skal støtte resten av arbeidet ved å sikre at riktige prosesser, veiledning(standarder og retningslinjer), verktøy(maskinvare, programvare, etc.) er tilgjengelig for teamet ved behov. 29

30 3.2. Valg av metode AUP ble valgt som systemutviklingsmetode av følgende årsaker. Prosjektmedlemmene har erfaringer fra tidligere prosjekter. Dette innebærer at medlemmene ikke kommer til å lese seg opp på detaljert prosessdokumentasjon, men de kunne ha behov for tilgang på detaljerte retningslinjer eller opplæring fra tid til annen. AUP har slik dokumentasjon tilgjengelig som man kan benytte seg av. Metoden er enkel, og alt er beskrevet presist på et fåtall sider og ikke tusenvis. AUP er smidig, og formes etter verdier og prinsipper til agil software utvikling, og Agile Alliance. Metoden har fokus på aktiviteter med høy verdi for prosjektet. Fokuset er på aktivitetene som faktisk teller, og ikke på hver eneste lille ting som kan inntreffe i løpet av prosjektet. Metoden er verktøyuavhengig, noe som gjør at du kan bruke de verktøyene som ønskes. Det anbefales at det blir brukt verktøy som passer best, noe som oftest er de enkle verktøyene. Noe av det viktigste er at AUP kan skreddersys for å passe våre behov. (Ambysoft, 2010) 30

31 Kapittel 4 4. Kravspesifikasjon For denne kravspesifikasjonen har vi brukt en mal som er hentet fra boka. (Bræk, 1983) Denne boken ga oss en god oversikt om hva som skulle være med og hvordan kravspesifikasjonen skulle skrives. Dette kapittelet beskriver nærgående alle deler av systemet slik det er tenkt når det er ferdig utviklet Oppbygging av kravspesifikasjonen Seksjon 4.2 i kravspesifikasjonen er en overordnet systembeskrivelse som beskriver forbedringer en kan oppnå ved å ta i bruk systemet. Her finner man informasjon om systemets egenskaper, kapasitet, begrensninger, produktivitet og operasjoner. Her finner man også en kort overordnet beskrivelse av det nye systemet som også viser en oppdeling av hvilke delsystemer og hvordan dataflyten er mellom dem og systemets omgivelser. Til slutt følger en beskrivelse av hvilke organisatoriske og personellmessige konsekvenser systemet medfører. Dette inneholder informasjon om hvilke endringer som vil skje med organisasjonen, personale, ansvarsforhold og fagkunnskaper konkursvarslingssystemet fører med seg. Seksjon 4.3 beskriver de forskjellige abonnementtypene som tilbys brukerne. Seksjon 4.4 i kravspesifikasjonen er rammekravene, og her spesifiseres de rammer som gjelder systemet som helhet. Beskrivelse av systemets tilgjengelighet beskrives her. Dette omfatter det som defineres som åpningstiden for systemet, maksimaltid for systemstans, og om det er behov for helgekjøring. Sikringstiltak mot tap eller ødeleggelse, tyveri eller misbruk av data, samt adgangskontroll og personvern er nærmere beskrevet i del tre. Videre er systemets kapasitet, sammen med informasjon om eventuell fremtidig utvidelse av systemet forklart her. Systemets responstid, oppdateringstider, nøyaktighet, brukervennlighet og arbeidslokaler samt miljø, sammen med en beskrivelse av hvordan verktøyet fungerer i et kontormiljø er nærmere forklart på slutten av dette kapittelet. Seksjon 4.5 omhandler systemets funksjonelle egenskaper, og hvert delsystem skal ha sitt eget underkapittel her. Her følger også en detaljert beskrivelse av on-line funksjoner, og alle satsvise funksjoner som inngår i hvert delsystem. I tillegg spesifiseres det nærmere hva funksjonen skal gjøre (behandlingsregler etc.), og det gis et eksempel på hva slags inndata som inngår. For hvert datafelt funksjonen inneholder beskrives det hvilket navn den har, om datafelter er valgfrie eller obligatoriske, symboltyper, antall tegn, og hva slags verdiområde 31

32 funksjonen har. Beskrivelse av inn- og utdata, og hvordan dette kan redigeres, og antatt bruksfrekvens disse har for brukerne vil komme fram i denne delen av kravspesifikasjonen. Seksjon 4.6 presenterer en logisk datamodell av hvordan den logiske sammenhengen mellom datasettene er. Her presenteres modellen(e) ved hjelp av datastrukturdiagrammer. Denne delen refererer til inndatabeskrivelsen fra kravspesifikasjonens del fire. Seksjon 4.7 forklarer hvilke krav det er til systemkonstruksjonen. Her angis det eventuelt eksisterende maskinutstyr som skal benyttes, og hvilke krav det stilles til eventuelt innkjøp av nytt maskinvareutstyr. Krav vedrørende service på utstyret, den geografiske plasseringen, antall enheter som må kjøpes inkludert eventuelt innkjøp av basisprogramvare som skal benyttes vil beskrives i denne delen. Her vil en spesifikk liste over hvilket databasesystem, operativsystem og lignende bli presentert. Seksjon 4.8 fastsetter kravene for dokumentasjonen til kravspesifikasjonen. Denne delen inneholder kravene til bruker-, operatør- og systemdokumentasjonen som skal utarbeides for systemet. Andre relevante dokumentasjonskrav finner man i denne delen av kravspesifikasjonen. Seksjon 4.9 i kravspesifikasjonen fastsetter kravene til systemets manuelle funksjoner, og gir en detaljert beskrivelse av hva som skal gjøres for hver av funksjonene. Det gis også en oversikt over ansvarlig og utførende personer for hver enkelt, samt en beskrivelse av inn- og utdata sammen med krav for frekvens- og behandlingstid. 32

33 4.2. Overordnet systembeskrivelse Brukeren kan logge seg inn på systemet med brukernavn og passord, hvis dette er glemt skal det være en mulighet for å få tilsendt et nytt på e-post. På første side vil det være en oversikt over hendelser som har skjedd den siste tiden, som for eksempel konkurser og tvangsoppløsninger i porteføljen. Brukerne vil også kunne administrere sin egen portefølje, her vil det være mulig å legge til nye oppføringer, fjerne oppføringer, endre oppføringer, endre brukerdata og søke i porteføljen. Systemet vil kunne varsle pr. e-post, sms og vise varsler på selve webområdet til brukeren. Administrasjonsmuligheter for systembrukere skal være tilgjengelig, hvor det vil være mulig å aktivere og deaktivere nye brukere, samt informasjonen tilknyttet disse. Utlogging av systemet skal være tilgjengelig på nettsiden. Ved å innføre vårt system vil bedriften kunne bruke mindre tid på å sjekke konkurser, fordi de vil slippe å sjekke organisasjonsnumrene manuelt. Hovedbeskrivelse Systemet skal tilby Innlogging og utlogging på systemet for brukere og administratorer Brukere kan administrere sin portefølje Brukere kan administrere sin egen brukerkonto. Detaljert beskrivelse Det skal opprettes brukernavn og passord for brukere av systemadmin Sende passord og brukernavn på e-post dersom det er glemt Legge til nye oppføringer Fjerne oppføringer Endre oppføringer Søke i portefølje Vise porteføljestatus Historikk av siste hendelser Endre fornavn og etternavnet til kontaktperson for bedriften Endre eller registrere telefonnummer Endre Faxnummer Endre mobiltelefon E-post/SMS/Webvarsling Konkursåpning Avslutning av bobehandling 33

34 Innstilling av bobehandling Fortsettelse av bobehandling Oppheving av konkurs Tvangsoppløsning Oppheving av tvangsoppløsning Tvangsavvikling Oppheving av tvangsavvikling Systemadministratormuligheter Deaktivere brukere Registrere nye brukere Opprette nytt (tilfeldig) passord til brukere Sende brukerinformasjon til nye brukere Backup av databaser Ta daglige backup av alle databaser, og lagre kopien i 30 dager. 34

35 4.3. Abonnementtyper Systemet skal loggføre de forskjellige abonnementene for brukerne, og utregne fakturaer basert på faktisk bruk. Dette gjøres ved å lagre den faktiske bruken for brukerne i en database. Denne informasjonen hentes ut en gang i måneden av systemadministrator, og lastes inn i et regnskapsprogram. Abonnement Beskrivelse Basis Web-administrasjon av portefølje Månedsavgift. Bindingstid Ingen SMS varsling. Ingen e-post varsling Fastpris pr. varsel Support Begrensning på 1 bruker Pluss Web-administrasjon av portefølje Månedsavgift Bindingstid E-post varsling Fastpris pr. varsel Support Begrensning på 1 bruker Proff Web-administrasjon av portefølje Månedsavgift Bindingstid E-post varsling SMS Varsling Fastpris for SMS pakke med fastsatt antall SMS. Pris Support 10 brukere 35

36 4.4. Rammekrav Tabellen nedenfor viser kravene for de funksjonene som systemet skal støtte. Samtidig vises prioritetsnivået til hver enkelt funksjon, hvor 1 er viktigst, og 3 er minst viktig. Krav Systemet skal tilby feilmelding dersom systemet eller nettsiden er nede Systemet skal tilby innlogging selv om tjenester er nede for vedlikehold. Prioritet Planlagte systemoppdateringer skal utføres i helgene Planlagte systemoppdateringer skal forhåndsvarsler på nettstedet Kritiske systemoppdateringer skal varsles en time før installering Det skal eksistere rutiner for håndtering av uforutsette feil Det skal eksistere rutiner for håndtering av uforutsett nedetid Overvåkning av systemet m/alarmfunksjon dersom det er nede grunnet uforutsette hendelser Adgangskontroll til systemet sikres ved brukernavn og passord Kryptering av passord i databasen slik at dette ikke ligger som vanlig tekst Passordbeskyttelse av sikkerhetskopierte databaser. 1 36

37 Fysisk sikring som oppbevaring i eget rom med lås Systemet varsler en gang pr. dag Systemet oppdateres daglig med nye kunngjøringer fra Brønnøysund Brukervennlig utforming av websiden m/funksjoner Systemet kjører i nettleser Hardware og annet støyende utstyr skal plasseres på ekstern lokasjon Systemet skal søke på organisasjonsnummer, med nøyaktig søketreff Systemets funksjonelle egenskaper Denne oversikten viser en mer detaljert oversikt over hva funksjonene i systemet skal gjøre, og hvilke data som funksjonen kan behandle. Funksjon Beskrivelse Databehandling Innlogging Brukeren må logge inn på tjenesten ved å skrive inn brukernavn og passord. Input skal valideres og kontrolleres for ugyldige tegn eller ondsinnet kode. Brukeren må eksistere i databasen, passord må være korrekt. Inndata: Brukernavn: string(30); Passord: char(8); Sende passord og brukernavn på e-post dersom det er glemt Tilby utlogging av systemet Dersom brukeren har glemt passord, skriver han inn kundenummer for å få passordet sendt til den registrerte mailen. Brukerens økt skal brytes ved at alle cookies/sessions avsluttes, slik at brukeren ikke lenger er innlogget. 37

38 Brukere kan administrere sin portefølje Brukeren kan administrere sin egen brukerkonto. Dersom man forsøker å gå tilbake må man logge inn på nytt Legge til nye oppføringer Brukeren skal kunne legge til nye oppføringer, altså registrere organisasjoner som skal overvåkes, dette gjøres ved å legge inn organisasjonsnummeret og firmanavn Fjerne oppføringer Brukeren skal kunne fjerne de enkelte organisasjonene de har under overvåking slik at de ikke lenger får informasjon om dette firmaet Endre oppføringer Brukeren skal kunne endre på for eksempel firmanavn eller organisasjonsnummere på de som allerede ligger registrert i deres portefølje Søke i portefølje Brukeren skal kunne søke etter sine allerede registrerte organisasjoner Status som viser nye hendelser i porteføljen når brukeren er innlogget skal det tydelig vises status over nye hendelser til de registrerte organisasjonene, dersom det forekommer en konkurs eller andre hendelser kommer det tydelig frem her. Dersom det ikke er noen nye hendelser skal dette også vises. Brukere skal kunne administrere sin egen brukerkonto Tilsendt nytt passord Brukerne skal kunne få Ny Oppføring: orgnr: int(9) Bedriftsnavn: varchar(50); Søkefelt: Varchar(60); Nytt passord: Varchar(8); Kontaktperson: Fornavn: String(30); 38

39 E- post/sms/webv arslig Systemadmini stratormulighete r tilsendt nytt passord ved å velge dette fra innloggingssiden. Brukerne må taste inn sitt brukernavn, og deretter sitt firmanummer. Systemet skal så sende ut det nye passordet til e-posten som er registrert på brukeren Endre kontaktperson for bedriften Brukerne skal kunne endre hvem som skal stå registrert som kontaktperson. Her skal de kunne skrive inn fornavn og etternavn på kontaktpersonen. Ingen e- postkvittering er nødvendig Endre telefonnummer Brukerne skal kunne legge til eller registrere et mobiltelefonnummer for SMS varsling. Det skal sendes ut en SMS bekreftelse til dette nummeret med en kode som må skrives inn på systemet for verifisering. Når nummeret er verifisert kan de motta SMS varsler. Brukerne skal kunne varsles av om det skjer noe i deres portfølje, dette er varslinger som blir vist på Websiden, eller sendt per E-post og SMS avhengig av hvilken type abonnoment kunden har. Dette vil opdateres ved en regelmessig scan av filer som kommer fra brønnøysundsregisteret. På denne siden skal systemets administrator styre systemet: Registrere nye brukere Etternavn String(30); e-post: varchar(50); Nytt postnr: Int(4); Ny adresse: Varchar(50); Nytt Tlf.Nr: Int(8); Deaktivere bruker: boolean Registrere bruker: Fornavn: String(30); Etternavn: 39

40 Backup av databaser Administratorbrukere skal kunne registrere en ny bruker Deaktivere brukere Administratorbrukerne skal kunne deaktivere brukere som ikke har betalt, eller har sagt opp sitt abonnoment. Dette vil skje ved at det blir vist en oversikt over alle brukerne som systemet har med en mulighet for å slette hver enkelt. På denne måten vil systemet slette alt som har med denne brukeren å gjøre Opprette nytt (tilfeldig) passord til brukerne Hvis en bruker har mistet sitt passord eller systemet av en annen grunn trenger å bytte passord på en bruker kan administratorer få en oversikt over alle brukerne og derifra endre passordet Sende brukerinformasjon til nye brukere Dette er en egenskap som sender ut brukernavn, passord, kundenummer og lignende informasjon til en ny bruker på mail. Samt informasjon om hvor det ligger brukerveiledning Behandle data fra web-registreringsskjema. Admin skal behandle ny data som kommer inn fra registrerinsskjemaet på nett for nye brukere. Systemet skal ta automatisk backup av databasene og sende disse til et eksternt system på en annen trygg lokasjon. String(30); Kundenr: Int(8); e-post: varchar(50); adresse: varchar(50); postnr: int(4); telefonnr: int(8) Bedriftsnavn: varchar(60); Orgnr: Int(9); abbtype: int(1); passord: varchar(8); 40

41 4.6. Logisk datamodell Systemet skal utvikles som et system for innsamling, behandling, lagring og distrubisjon av informasjon. Figuren under viser en use case oversikt som en modell over hva et informasjonssystem skal gjøre og for hvem. Modellen består av et antall brukstilfeller som kan være en isolert funksjon eller en prosess som tilfedstiller et krav hos brukeren/aktøren. Et use case skal fange opp systemets atferd uten å spesifisere hvordan denne atferden skal implementeres. Den blir brukt for å visualisere de essensielle atferdene. 41

42 Dette er klassediagrammet, som skal ligge til grunn for både datamodelleringen og implementeringen. Klassediagramet skal vise klassene, grensesnittene og samhandlingene som inngår i modellen og relasjonene mellom dem. 42

43 4.7. Krav til systemkonstruksjonen Selve systemkonstruksjonen må bestå av følgende hovedpunkter x Virtuell maskin med utviklingsmiljøet Linux Apache MySQL og PHP (Wikipedia, LAMP, 2010) x Stasjonær maskin med LAMP testmiljø Backupenhet(er) Gammu (mobiltelefonprogramvare for Linux) (Gammu, 2010) Mobiltelefon som støttes av Gammu Software for minnediagnose Software for harddiskdiagnoser Nettleser 4.8. Krav til dokumentasjon Det ferdigutviklede systemet bør leveres med dokumentasjon som forklarer brukerne hvordan systemet fungerer. Denne dokumentasjonen bør gjøres tilgjengelig for brukerne straks de er registrert som ny bruker. Punkt Underpunkt Brukerdokumentasjon: Logger på Logger ut Legger til oppføring i portefølje Fjerner oppføring i portefølje Endrer oppføring i portefølje Hvordan redigere egne brukerdata Forklaring av varslingsmåter Forklaring av varslingsområder som dekkes avsystemet Ofte stilte spørsmål (FAQ) Abonnementinformasjo Ordliste 43

44 Operatørdokumentasjon: Legge til systembrukere Fjerne systembrukere Endre systembrukerinformasjon og tilganger Teknisk spesifikasjon av systemet Programvare, Programmeringsspråk, Operativsystem, Nettleserkrav LAMP testmiljø XML spesifikasjoner Eksempler på oppbygging av de forskjellige filene Scripteksempel for XML parsing Ofte stilte spørsmål (FAQ) Ordliste Systemdokumentasjon skal inneholde informasjon om: Hardware Programvare Operativsystem Lokalisering av utstyr Systemrutiner 4.9. Krav til manuelle funksjoner Det er flere arbeidsoppgaver som må utføres manuelt av systemets administratorer. Dette er funksjoner som i fremtiden kan gjøres om til automatiske rutiner slik at systemet kan bli mer effektivt. Manuell funksjon: Beskrivelse: Legge inn bruker Når systemet får inn et nytt brukerskjema pr. Brevpost må en administrator legge dette inn i systemet og opprette brukeren Logg Systemet vil loggføre automatisk men administrator må manuelt sjekke disse Vedlikhold av systemet Se til at alt fungerer som det skal, og gjøre nødvendige oppdateringer Deaktivere brukere Hvis en kunde avslutter et abonnoment må administrator manuelt slette brukeren 44

45 Kapittel 5 5. Design Systemet skal varsle brukere av systemet om konkurser som kunngjøres fra Brønnøysundregisteret. Kunngjøringene overføres til konkursvarslingsystemet som skal sørge for å videreformidle denne informasjonen til sine brukere. Denne varslingen vil komme i form av SMS, e-post eller vises på brukernes hjemmeområder på nettsiden. I de påfølgende kapitlene følger en beskrivelse av systemets virkemåte og dets hovedkomponenter LAMP Utviklingsmiljø Ved utvikling av Konkursvarsling.no skal det benyttes et utviklingsmiljø som er basert på LAMP definisjonen. Dette betyr at systemet skal bestå av følgende komponenter: Linux Apache mysql PHP Linux Ryggraden i systemet er tenkt å være to Linuxmaskiner der den ene maskinen er et Debian Linux system uten grafisk brukergrensesnitt. Denne maskinen er tenkt å være en server som står med fast IP adresse på Høgskolen i Oslo, og den skal inneholde databasene til systemet. I tillegg skal den også fungere som webtjener for nettsiden. I tillegg til å være en webtjener må den konfigureres til å kunne koble seg til en SFTP konto hos Brønnøysundregisteret ved å åpne en kryptert datakanal SSH (Secure Shell) mellom de to maskinene. Den andre Linux maskinen skal kunne tilby et brukergrensesnitt, og kjøre Linux Operativsystem. Denne skal stå og lytte på tilkoblinger utenfra som kommer fra Debian maskinen. Denne maskinen skal ha som hovedoppgave å sende tekstmeldinger (SMS Short Messaging System) til brukernes mobiltelefoner ved eventuelle hendelser fra Brønnøysundregisteret. Prosjektgruppen ønsker å opprette en SFTP (Secure File Transfer Protocol) konto hos Brønnøysundregisteret for hovedprosjektets formål. Meningen med dette er at Debian maskinen og Brønnøysundregisteret skal kunne utveksle XML filer, og at maskinen da kan behandle alle de mottatte filene. 45

46 Apache Apache er en webtjener med åpen kildekode som er en av markedets mest populære. Tjeneren skal installeres på Debian maskinen, og skal konfigureres slik at Apache kan være webhotell for systemets nettside. (Apache, 2010) MySQL Hjertet i systemet vil bestå av to databaser som er skal plasseres på Debian maskinen. Den ene databasen vil inneholde all data som tilknyttes systemets brukere samt kunngjøringer fra Brønnøysundregisteret. Den andre databasen skal tilknyttes SMS varslingen, og det som er relatert til dette. I konkursdatabasen skal data registreres øyeblikkelig etter en konkurs, og deretter kontrolleres mot kundenes porteføljer. Forekommer det treff hvor kunngjøringer stemmer med forekomster i brukernes porteføljer, vil det sendes SMS, nett eller e- postvarslinger til de som er registrert til å motta dette. (mysql, 2010) PHP Hypertext Preprocessor PHP er et programmeringspråk som skal benyttes som et bindeledd mellom brukergrensesnittet og databaser. I prosjektet skal også dette språket benyttes til mye databasekommunikasjon. Mye av PHP er lånt fra C, Java og Perl, men samtidig har PHP flere egenskaper som er særegent for språket. PHP blir benyttet i dette prosjektet på bakgrunn av dets fleksible egenskaper, og at man kan benytte det til å lage dynamiske nettsider. (PHP, 2010) Gammu SMS system Utenfor LAMP definisjonen kommer programvaren Gammu som er et programvareprosjekt som sikter på å styre funksjoner på mobile enheter. Gammu støtter for tiden de fleste populære telefonmodeller, både via bluetooth og kabel. Programmet kjører på Maskin 2 og sørger for kommunikasjon mellom mobiltelefon, databaser og maskinvare. I praksis er alle aspekter med SMS bruk flyttet over fra telefonen til Maskin 1, som nå inneholder en komplett SMS database. Databasen er en erstatning for mobiltelefonens SMS system slik at alt foregår på datamaskinen og ikke på telefonen. Dette betyr at telefonens utboks, innboks, sendte elementer og lignende nå er flyttet fra telefonen, og befinner seg på Maskin 2. (Wiącek, 2010) 5.2. Detaljert systembeskrivelse Systemet skal varsle om kunngjøringer til brukerne, og dette skal gjøres ved hjelp av flere motorer som driver systemet. Disse motorene vil bestå av flere små programmer skrevet i Perl som blant annet skal ha ansvaret for filbehandling og systemkommunikasjon. 46

47 Symbolforklaring: Lagring Motor Database Maskin Tilkoblinger Konkursvarslingsystemet blir avhengig av å kunne koble seg til Brønnøysungregisteret for å laste ned kunngjøringsfilene. Dette skal løses ved at systemene oppretter kommunkasjonskanaler som krypterer data ved hjelp av SSH. SFTP fra en spesifisert og fast IP-adresse er den eneste tillatte formen for kommunikasjon til Brønnøysund. Det blir en automatisk kommunikasjon mellom systemene, noe som er avgjørende for rask varsling for brukerne. Det vil være et Perl script ved navn cronscript2.pl som oppretter tilkoblingen mellom systemene og åpner for en utveksling av krypterte nøkler som skal brukes for å godkjenne koblingene Filbehandling Systemet skal innhente alle filer fra SFTP kontoen, og skal lagre dem på Debian maskinen. Filene som skal hentes er i XML format og skal behandles av et Perlscript ved navn xmlscript.pl. 47

48 Databaser Etter filbehandlingen skal data overføres til databasene. Det skal behandles store mengder med data, og her skal systemets databaser ha ansvar for å opprettholde konfidensialitet, integritet, kvalitet og tilgjengelighet til de dataene som er behandlet. Databasene skal danne selve grunnmuren for hele systemet. Alt fra abonnement, brukere, porteføljer, rettigheter, SMS, logger og kunngjøringer lagres her Tilgangsrettigheter ACL Det skal bli satt opp en ACL (Access Control Lists) i databasestrukturen. ACL skal fungere som lister som styrer tilgangsrettigheter mellom brukere og abonnementer, og mellom brukere og porteføljer. Her er tanken at systemet skal kunne tildele rettigheter til brukerne. Det skal sørge for at det er god kontroll på hva brukerne har tilganger til, og det blir enkelt for systemadministratorer å deaktivere brukere som ikke skal ha tilgang til systemtjenester. Det samme skal gjelde for lokaladministratorer, i hovedsak eier av abonnementet, som skal kunne delegere rettigheter til brukerne sine Loggføring Hver spørresetning som utfører endringer i databasene skal loggføres. Dette gjelder blant annet for INSERT, UPDATE, og DELETE setninger. Loggføringsmuligheten er implementert fordi det er viktig for systemadministratoren å kunne spore endringer som er utført av brukerne. Loggføring vil også bli en slags sikkerhet for systemet, fordi det skal fungere som en dokumentasjon for at varslingene har blitt sendt til kundene. I tillegg skal det implementeres en siste hendelser liste på nettsiden. Den skal vise de 10 siste hendelser som har skjedd i kundens portefølje Sikkerhet Inputfelter skal sikres ved at innebygde PHP funksjoner renser inndata for ugyldige tegn. Dette skal blant annet forhindre SQL injeksjoner og andre potensielle angrep som benytter seg av inndata som angrepsform. Brukernes automatisk genererte passord skal krypteres slik at passordene ikke lagres i klartekst Tabellstruktur Systemets brukere skal lagres i en persontabell hvor navn, kontakt-, faktura-, e-post- og passordinformasjon blir satt inn. Denne tabellen skal kobles til abonnementstabellen som inneholder brukernes abonnementsnummer. Dette nummeret skal automatisk tildeles brukeren som eier abonnementet og nummeret skal benyttes videre på alle nye brukere som denne administratoren oppretter. Et abonnementsnummer skal være en identifikator for abonnementene fordi da skal man kunne knytte sammen flere brukere opp mot ett abonnement. Da blir det for eksempel enkelt å sperre alle tilhørende brukere dersom abonnementet ikke er betalt, og tilganger til systemet kan begrenses ved behov. 48

49 Porteføljene til brukerne skal alle lagres i en og samme tabell, men med et autoinkrementert nummer, abonnementsnummeret, og brukernavnet som identifikator. Dette gjør at en bruker kan opprette sin egen portefølje som tilknyttes brukernavnet, og i tillegg også til hovedabonnementets abonnementsnummer. Ved å benytte abonnementsnummeret skal man også kunne la brukere fra samme abonnement få muligheten til å se alle porteføljer innenfor det samme abonnementet. Dette vil da skape store muligheter for å skreddersy behovet til bedrifter som ønsker flere porteføljer, blant annet med tanke på avdelingsbasert overvåkning. Sistnevnte overvåkningsform tilsier at en lokal administrator må ha muligheten til å kunne legge til brukere med forskjellige porteføljer slik at ikke porteføljene blir store og uoversiktlige for brukerne. Tanken er at alle brukere skal få se en felles portefølje for hele bedriften, men at de kun skal få endre de porteføljene som de selv har tilgang til å endre. Slike rettigheter skal utdeles av den lokale administratoren. Varslingstabellen til databasen vil inneholde all behandlet data som skal hentes ut fra XML filene fra Brønnøysund. Etter kontakt med Brønnøysund er det gjort rede for at det finnes 9 forskjellige kunngjøringstyper som omhandler konkurser. Alle varslinger som publiseres i denne tabellen skal sjekkes mot alle organisasjonsnumrene som finnes i brukernes porteføljer, og systemet skal varsle brukerne via e-post, sms og på web dersom en hendelse oppstår i deres portefølje. Skjemaet nedenfor viser hvordan databasen er tenkt utvilket. Figur 8 Tenkt databasestruktur 49

50 5.3. Brukergrensesnitt Brukergrensesnittet på nettsiden er tenkt utformet i lyse farger og rene linjer som er tenkt å følge samme design som er observert på nettsider med tilsvarende tjenester og innenfor samme fagområde. Menyene er tenkt å kontrollere rettighetsnivået til brukere som er pålogget, og stenge eller åpne for de menyvalgene de har eller ikke har rettigheter til. Designet på siden er tenkt kontrollert av CSS fordi man dermed enkelt kan skreddersy designet ved behov. Det må også benyttes MySQL, PHP og XHTML/HTML programmering for å kunne skape en dynamisk brukeropplevelse. Det er tenkt implementert en hovedmeny som skal inneholde de mest brukte valgene på siden. I tillegg skal det utvikles en brukermeny som tilbyr brukerne valgene de trenger for å kontrollere sine porteføljer og sin egen brukerkonto. Nettsiden er tenkt oppdelt i en topp-, venstre-, bunn- og hoveddel (se bildet til høyre) for å kunne tilby brukerne en dynamisk opplevelse. Toppdelen skal inneholde logo, hovedmeny og inn- og utloggingsmuligheter. Venstredelen skal inneholde brukermenyen, og skal kunne endre seg ettersom hva slags rettigheter man er tildelt. Bunnen skal inneholde enkel kontaktinformasjon for rask tilgang dersom man har behov for dette. Venstre Figur 9 - Nettside struktur Topp Hoveddel Bunn Selve hoveddelen skal være dynamisk, og svarer på kommandoer som kommer fra de tre andre delene av siden. 50

51 Kapittel 6 6. Prototyping Utviklingen av en prototype tar utgangspunkt i et system som kjører Linux, Apache, mysql og PHP (LAMP) da dette tilbyr de funksjonene som systemet trenger for å kunne oppfylle kravspesifikasjonen som er nærmere beskrevet tidligere i rapporten Maskinvare Systemet kjører på to forskjellige datamaskiner som står på forskjellige lokasjoner, og som har forskjellige IP adresser. Den ene maskinen er webtjener og inneholder også alle databasene som systemet er avhengig av, mens den andre har ansvar for å sende ut SMSvarsler via en tilkoblet mobiltelefon. Maskin 1 Konkursvarsling.no/Databasesystem CPU: Intel(R) Xeon(TM) CPU 3.00GHz RAM: 512MB Hovedmaskinen til systemet er Maskin 1 som er et Debian Linux system uten grafisk brukergrensesnitt. Denne maskinen står med fast IP adresse på Høgskolen i Oslo, og den inneholder alle databasene til systemet. Maskin 2 - SMS CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz RAM: 2048MB Maskin 2 er satt opp med Ubuntu OS, og lytter på tilkoblingsanmodninger fra Maskin 1. Anmodningene kommer med regelmessige intervaller og inneholder organisasjonsnummer og firmanavn på bedriften det gjelder, i tillegg til telefonnummeret til den som skal varsles. Det sendes bare ut sms til de abonnementene som er aktivert for dette, og i tillegg bare til de brukerne som har registrert et mobiltelefonnummer. Kunngjøringer som allerede er varslet med SMS vil ikke bli varslet på nytt. 51

52 6.2. Programvare For at systemet skal kunne kjøre er følgende programvare nødt til å være installert på de to maskinene, nedenfor er en tabell som viser en oversikt over hvilke programmer som skal installeres på maskinene og hvilken versjon de installerte programmene er. Programvare Maskin# Versjon Apache 1 Apache/2.2.3 mysql Debian PHP 1 PHP/ Gammu 2 v Debian OS 1 Debian GNU/Linux - Linux xen-686 Ubuntu OS 2 Ubuntu Linux server Perl 1 v5.8.8 built for i486-linux-gnuthread-multi Perl 2 v built for i486-linux-gnuthread-multi OpenSSH 1 OpenSSH_4.3p2 Debian-9etch3, OpenSSL 1 OpenSSL 0.9.8c Systemfiler For at systemet skal fungere er det programmert en rekke småprogrammer i Perl, PHP og XHTML/HTMLl som har ansvaret for å få alle funksjonene til å virke som de skal. Nedenfor er en liste av filene og deres hovedoppgaver. Noen av programmene kjører regelmessig ved hjelp av funksjonen cron i Linux. Dette er en funskjon i Linux som lar deg bestemme når og hvor ofte script skal kjøres. Filnavn Beskrivelse # Linjer XML fra Brønnøysund Alle XML filer fra Brønnøysund. (.xml) WAAPscript.pl WATOscript.pl Behandler konkursåpninger, tvangsoppløsninger, tvangsavviklinger, WAAP 701 WATO 546 WATVscript.pl avslutning av bobehandling, innstilling av WATV 559 WAVSscript.pl bobehandling. WAVS 665 WINS 756 WINSscript.pl varsle.pl cronscript2.pl Denne filen kjører som cron og sjekker om det er brukere med SMSvarsling aktivt i abonnementet. Dersom abonnementet er aktivert for SMS tjenester vil scriptet oppdage alle hendelser som ikke tidligere er varslet via SMS. De som varsles vil ikke bli varslet for samme hendelse flere ganger. Fil som kobler seg til Brønnøysund og som styrer nedlasting av nye kunngjøringer. Den står også

53 WAAP.xml WAVS.xml WINS.xml WATO.xml WATV.xml WGTA-2.xsd AVSL-2.xsd FORT-1.xsd INNS-1.xsd KONK-3.xsd OPPH_KO-2.xsd OPPH_TO-2.xsd OPPH_TV-2.xsd TVANG-2.xsd TVOP-2.xsd WGFA-2.xsd for flytting og behandling av filene. Kunngjøringer hentet fra Brønnøysund i XML format. XML Schema filer som dokumenterer strukturen til XML filene. Filer tilhørende nettsiden index.php Indeksfilen til nettsiden, alle komponenter 659 inkluderes i denne. style.css Styrer utseendet til nettsiden. 266 calendar-win2k-cold-1 Styrer utseendet til kalenderknappen under nyregistrering av bruker. admin_index.php Fil som inneholder brukerskjema ved 400 nyregistrering. brukerdata.php Fil som tar imot data og behandler data ved 391 registrering. forstesiden.php Inneholder alt som skal stå på førstesiden. 16 hendelser.php Viser status for porteføljen og sorterer 105 oppføringene etter nyeste hendelse. add.php Fil som lar brukere legge til oppføringer i 258 porteføljene sine. Skiller mellom type brukere som admin og vanlig bruker. Viser forskjellig skjema etter rettighetsnivå. portefolje.php Fil som inkluderer porteføljen til pålogget 41 bruker dersom abonnementet er aktivt. Inkluderer filen p_print.inc.php p_print.inc.php Fil som skriver ut hele porteføljen til alle 159 brukere i ett abonnement i tabellform på skjerm. intern_sql.inc.php Fil med tilkoblingsinnstilling for mysql. Brukes 5 hver gang man bruker SQL på nettstedet. valgmuligheter.php Fil som inneholder menyen. 68 calendar.js calendar-setup.js Javascriptkalender GAMMU relaterte filer 53

54 argus.pl gammurc smsdrc Tolker innboks og sender svar. Konfigurasjonsfil for kommunikasjon mellom maskin og enhet. Leser konfigurasjonene fra gammurc Tilkoblinger Konkursvarslingsystemet ved Maskin 1, kobler seg til Brønnøysundregisteret for å laste ned kunngjøringsfiler. Dette skjer ved hjelp av cronscript2.pl. Denne kommunikasjonen bygger på flere moduler fra CPAN (the Comprehensive Perl Archive Network), som er en samling av over Perl moduler. Maskin 1 initialiserer her tilkoblingen mellom maskinene ved å sende en tilkoblingsanmodning ved hjelp av en Perl SFTP modul. Denne modulen heter Net::SFTP og krypterer koblingen ved hjelp av modulen Net::SSH. Dette scriptet konfigureres også med brukernavn, passord og adressen til SFTP serveren til Brønnøysund. Tilkoblingen mellom systemene åpner for utveksling av krypterte nøkler som brukes for å godkjenne koblingene. Når nøkkelutvekslingen er utført og tilkobling er opprettet, vil programmet liste alle filer som ligger på serveren og matche dem mot de som ligger på Maskin 1. SFTP tilkobling mot Brønnøysund fra Maskin 1s IP adresse er den eneste formen for tillatt kommunikasjon til Brønnøysund Filbehandling De filene som ligger på SFTP serveren, men ikke på Maskin 1, blir lastet ned og sortert i riktig mappestruktur ved hjelp av SFTP GET kommandoen. Det angis her plassering av serverens filmappe, og vår lokale nedlastingsmappe. Deretter er det en helautomatisk nedlastingsprosess som tar over og laster ned alle filene til den lokale mappen. Det gjøres en sammenligning av filer som allerede er lastet ned, og mot filer som ligger på Brønnøysundsregisterets SFTP-konto som ikke tidligere er lastet ned. De ny kunngjøringene som skiller seg ut blir dermed lastet ned. Deretter gir programmet beskjed til XML behandlingsprogrammene om å sette i gang behandlingen av de nedlastede filene. Hvert av programmene er konfigurert til å vite hvor filene er plassert på systemet, og vil foreta en helautomatisk behandlingsprosess. Det er et mangfold av variasjoner i disse filene, og behandlingsprogrammene må ta høyde for alt dette. I tillegg må programmene gjenkjenne innholdet i samtlige filer og kontrollere om innholdet er identisk med andre filer. I så fall vil filer bli oppfattet som duplikater, og flyttes til dedikerte mapper. Etter duplikatkontroll vil hvert script foreta innsetting av XML data i varslingsdatabasen, og for hver ferdigbehandlet fil vil scriptet flytte den respektive filen til korrekt mappe. Hver 54

55 varslingstype har sin egen mappestruktur slik at man vet hvilke filer som er ferdigbehandlet, ubehandlet og som er oppdaget som duplikat. Nedenfor vises kompleksiteten til XML strukturen ved at man kan se valgfrie og obligatoriske elementer som alle kan kombineres på forskjellige måter. Figur 10 - KONK-3.XSD Figur 10 viser XML schema dokumentet til filen som omhandler åpning av konkurser. De elementene som alltid forekommer vises uten minoccurs og maxoccurs beskrivelse. De mange variasjonene i XML strukturen oppstår når kombinasjoner av de valgfrie og obligatoriske elementene forekommer. Figur 11- WAAP.xml Figur 11 viser et utdrag av oppbyggingen av konkurskunngjøringer, og viser hva slags datatyper, navn og lengder som forekommer i denne filen Databaser 55

56 Overføring av data fra XML behandlingen skjer ved SQL spørringer til databasen. Databasen heter Konkursvarsling og består av følgende 10 tabeller: abonnement, acl_persabb, acl_perspor, logg, personer, portefolje, postboks, postfysisk, varsling, varslingstyper. Abonnement-tabellen inneholder all data om en brukers abonnement. I denne tabellen registreres abonnementbeskrivelse, pris, om det er aktivt, om det er betalt, og om det er aktivert for tilleggstjenester som for eksempel sms varsling. Til høyre ligger abonnement tabellen. Figur 12 Tabell: abonnement Tabellen personer inneholder alle data om en bruker. E-post adressen defineres som personens brukernavn, og skal ikke kunne endres i ettertid med begrunnelse av at logghistorikk må kunne spores. Alle personalia om vedkommende vil lagres her, og skal kunne endres av brukeren ved senere anledninger ved behov. I denne tabellen lagres også en brukers passord i kryptert format for sikkerhetsformål slik at brukernes valg av passord ikke kommer på avveie dersom databasen angripes. Foreløpig benytter systemet MD5 funksjonen til mysql for kryptering av passordene. Da dette er en enveiskryptering får brukerne tilsendt en en e-post med instruksjoner om hvordan de oppretter et nytt passord dersom de har glemt hva det opprinnelige passordet var. Figur 13 Tabell: personer 56

57 Porteføljene til alle brukerne ligger lagret i tabellen portefolje, og lagrer alle organisasjonsnumre og firmanavn som brukerne ønsker å overvåke. Alle oppføringene i porteføljene knyttes opp mot en brukers abonnementnummer og brukernavn slik at man vet hvilken bruker som skal få varslingene. Acl_persabb er tabellen som bestemmer hva slags rettigheter denne brukeren har tilknyttet abonnementet. Det deles her inn i rettighetsnivåer fra 0-5, hvor 5 er systemets superbrukere, og 0 er ingen rettigheter. Har brukeren rettighetsnivå 4 kan han legge til andre brukere, men han har ikke rettigheter til å legge til tilleggstjenester eller endre på abonnementet brukeren tilhører. Brukere med rettighetsnivå 4 kan bare legge til brukere med rettighetsnivå 3 eller lavere. Disse nye brukerne kan kun administrere porteføljer, og oppdatere brukerdata som omhandler deres egen bruker. Dette er data som f.eks telefonnummer og navn som er registrert i systemet. Figur 14 Tabell: portefolje Figur 15 Tabell: acl_persabb En aksesskontrolltabell som foreløpig ikke blir benyttet er tabellen som heter acl_perspor som ligger mellom tabellen personer og portefolje. Det er foreløpig ikke diskutert noe annet enn et mulig fremtidig behov for aksesskontroll mellom disse tabellene. Figur 16 Tabell: acl_perspor 57

58 Nært tilknyttet porteføljene er tabellen varsling. Dette er tabellen hvor all informasjon som kommer fra Brønnøysund blir lagret. Dette er den klart største tabellen, og på en vanlig dag har det vist seg at tabellen vokser med ca 70 nye rader. Varslingstypene ligger lagret i en egen tabell som heter varslingstyper. Her ligger informasjon om de forskjellige varslingstypene som kan forekomme. Varslingstabellen benytter seg av denne informasjonen ved å skrive inn de 4 bokstavene som kjennetegner en varslingsfil, og finner beskrivelsen av varslingstypen ved å spørre varslingstypetabellen. Figur 18 Tabell: varslingstyper Det er i tillegg to posttabeller i systemet som benyttes ved brukerregistreringer og adresseendringer. Systemet finner Figur 17 Tabell: varslings automatisk hvilket poststed som tilhører et postnummer som blir skrevet inn i skjemaer på nettsiden, og setter inn det riktige poststedet i tabellen. Figur 19 Tabell: postfysisk Figur 20 Tabell: postboks SMS Database En egen database ble utviklet for SMS systemet, og denne tar vare på alle sendte og mottatte varslinger som forekommer i systemet. Opprinnnelig lå denne databasen på en egen datamaskin, men databasen ble senere flyttet i sin helhet over på samme datamaskin som konkursvarslingssystemet. Dette gjorde systemoppbyggingen noe enklere, og eliminerte behovet for databasekommunikasjon på tvers av to forskjellige datamaskiner. SMS varslingen er satt til å kjøre mellom klokken 08:00 og 23:00, og styres av Gammu på Maskin 2. Denne datamaskinen er hele tiden tilkoblet en mobiltelefon og sjekker regelmessig om det er nye konkurser som hittil ikke er varslet med SMS. I tillegg kontrolleres 58

59 det at eieren av abonnementet har aktivert SMS varsling i abonnementet før det sendes ut varslinger. Figur 21 - SMS dabasestrukturen Figur 21 ovenfor viser hvordan en SMS database ser ut når den er overført fra mobiltelefon og over til Maskin Loggføring Hver spørresetning som utfører endringer i databasene loggføres. Dette gjelder blant annet INSERT, UPDATE, og DELETE setninger. Loggføringsmuligheten er implementert da det er viktig for systemadministratoren å kunne spore endringer som er utført av brukerne. Systemet logger alle endringer i tabellene, og lagrer dette i tabellen logg. Samtlige tabeller er beskrevet med tabellnavn, og ut fra dette betyr det at tabellen personer inneholder en Figur 22 Tabell: logg kolonne med teksten personer. Denne teksten lagres i loggtabellen sammen med tidsstempel for når endringen ble utført, og hvem som utførte endringen(e). 59

60 Slik ble den endelige databasestrukturen. Figur 23 - System database Figur 23 viser sammenhengen mellom alle tabellene, selve innholdet i tabellene er nevnt i kapittel 6.6 Databaser Sikkerhet Inputfelter sikres ved innebygde PHP funksjoner som renser inndata for ugyldige tegn. Dette er blant annet for å hindre SQL injeksjoner og andre potensielle angrep som benytter seg av inndata som angrepsform. 60

61 6.7. Prototypedesign Designet på siden er delt opp i topp-, venstre-, bunn- og hoveddel, og gir brukerne en enkel og god brukeropplevelse. Menyene er plassert for seg selv slik at man lett får øye på dem, og inn- og utloggingen er plassert godt synlig øverst på siden. Figur 24 - Design av nettside I prototypen er de elementene på hovedmenyen som brukerne må være innlogget for å kunne benytte seg av markert med hengelås. Etter at prototypen er godkjent for produksjon vil hengelåsene bli erstattet av knapper som peker til andre elementer som man ikke trenger å være pålogget for å kunne få tilgang til. Skjermbildet nedenfor viser hengelåsen slik den viser seg for brukerne i prototypen når de ikke er innlogget i systemet. Hengelåsen synes tydelig, og illustrerer med sin tilstedeværelse at brukeren ikke har tilgang. Figur 25 - Ikke innlogget Brukerne som logger inn vil bli møtt av en mer innholdsrik og funksjonell nettside som gir tilgang til flere funksjoner. 61

62 Søk i portefølje er en av funksjonene som brukerne får tilgang til. Her skriver de inn organisasjonsnummeret eller firmanavnet de ønsker å søke etter, og resultatet vil dukke opp på skjerm. Nedenfor er det søkt etter ordet hamm, noe som returnerer en porteføljeoppføring med navnet HAMMERGREN ERIK da søkeordet forekommer i oppføringen. Figur 26 - Søkefunksjon Endre/Slette/Legge til porteføljeoppføring er funksjonene brukerne får tilgang til dersom de har rettigheter til dette. Dersom brukerne har feillagret porteføljeelementer og ønsker å utføre en korrigering kan de endre navn og organisasjonsnummer til oppføringene sine ved å velge endring fra menyen til venstre. Figur 27 - Rediger Figur 28 - Endre oppføring Brukerne kan også slette oppføringen ved å velge fjern fra samme meny, og dermed trykke på valget for å slette elementet. Figur 29 - Slett 62

63 Funksjon for å legge til et porteføljeelement befinner seg også på menyen til venstre, og i brukergrensesnittet får brukerne opp følgende skjermbilde. Figur 30 - Legge til ny portefølje Etter at brukerne har registrert en oppføring i en portefølje og ønsker å registrere en ny oppføring vil de møtes av en noe annerledes utforming hvor de blir spurt om å lagre i samme portefølje, eller opprette en ny. Dersom det finnes mer enn en portefølje, vil brukeren bli presentert med en nedtrekksmeny som viser de tilgjengelige porteføljene, og lar brukeren velge hvilken portefølje han ønsker å lagre oppføringen i. Også her har brukeren muligheter til å opprette en ny portefølje. Figur 31 Legge til når portefølje eksisterer fra før Figur 32- Legge til når flere enn 2 porteføljer 63

64 Brukerne har også muligheter til å endre sin egen brukerkontoinformasjon ved å velge Brukerpanel knappen fra toppmenyen, og er meget nyttig i de tilfeller hvor man må oppdatere navn og mobiltelefon. Se figur 33. En annen nyttig funksjon på nettsiden er panelet nederst til venstre på menyen som viser de siste hendelser som har forekommet i porteføljen. Listen sorteres etter varslingsdato med den nyeste datoen øverst slik at brukeren får en oversikt over de mest aktuelle hendelsene straks etter innlogging. Figur 33 Endre brukerinfo Figur 34 Siste Hendelser Innloggede brukere med rettigheter til å legge til nye brukere i abonnementet kan trykke på admin knappen for å få opp et skjema som kan benyttes for å legge til nye brukere i systemet. De nye brukerne får ikke rettigheter til å kunne legge til nye brukere. Nedenfor er et skjermbilde av skjemaet som benyttes for å legge til nye brukere. Til venstre nedenfor vises skjemaet som en administratorbruker kan bruke for å legge til en ny bruker i abonnementet. Legg merke til at eier av abonnementet allerede er fylt inn fordi det her er snakk om å legge til en ny bruker i det samme abonnementet. Bildet til høyre viser et skjema for helt nye brukere. Her må all informasjon fylles ut som er nødvendig for å kunne registrere henvendelsen i databasen. Informasjon legges inn i databasen, og må gjennomgås av en systemadministrator før godkjennelse og aktivering av abonnementet. Figur 35 Nye brukere til eksisterende abonnement Figur 36 Registrere ny bruker I systemet fra nett. 64

65 En av de andre hovedfunksjonene er at man trykker på knappen Portefølje fra hovedmenyen, og da vil brukerne se porteføljen som er registrert. Dersom en hendelse har oppstått vil brukerne kunne trykke på en kobling som heter Alarm. De vil da få opp en forklaring av hva slags hendelse som har oppstått. Har ingen hendelse oppstått på et porteføljeelement vises teksten OK. Figur 37 Vise porteføljeoppføringer Via en kobling på menyen til venstre kan brukere også kontakte systemets utviklere ved hjelp av et kontaktskjema. Her fyller brukerne ut e-post og melding som de ønsker å sende inn. Alt sendes inn til en spesifisert e-post adresse, og vil leses av en systemadministrator. Figur 39 Kontaktskjema Figur 38 Kontakt oss vises på menyen Hoveddelen av nettsiden viser alt innholdet, og er den delen som oppfattes som mest dynamisk for brukerne. Det er i denne delen brukerne fyller ut, lagrer og endrer informasjon som er lagret i systemet. Når brukerne trykker på menyene vil innhold endres i sidens hoveddel. 65

66 6.7. Brukertesting Etter at prototypen var ferdig utviklet, ble det gjort klar for brukertesting. Formålet med testingen var å skaffe seg en oversikt over feil og mangler som ikke ble avdekket i det lokale testmiljøet. Det ble ikke utført testing av prototypen før alle moduler var ferdigutviklet av hensyn til at hver av systemmodulene måtte testes separat for å forsikre at de virket. Med en agil utviklingsmetode (AUP) var det nødvendig å utføre all testing etter at systemet var satt sammen for så senere kunne utvikle modulene og systemet videre. Det ble oppdaget en del kritiske og en del mindre feil i de interne testene av systemet, noe som gjorde at det under denne perioden ble brukt mye tid på feilretting og designendringer av prototypen. Etter hvert som feilene minket i antall og omfang ble det besluttet å begynne med planlegging av brukertestingen. Gjennom hele systemutviklingen er det blitt utført en del mindre tester for å se at systemet gjør de oppgavene som er satt i kravspesifikasjonen. Dette kalles white-box-testing (Wikipedia, White box testing, 2010), noe som innebærer at man har kjennskap til og innsikt i koden, og at man tester funksjonaliteten fortløpende. Ellers er det også utført black-boxtesting (Wikipedia, Black box testing, 2010) der man ikke trenger noen kjennskap til koden, men driver feiltesting ved at man mater systemet med testdata for å se hvilke tilbakemeldinger det gir og eventuelt luke ut feil eller rette opp problemer som oppstår Deltakere Til brukerstestingen ble det valgt ut forskjellige personer som både har erfaring med konkursbehandling, og privatpersoner med varierende datakunnskapsnivå. Årsaken til den store variasjonen i testpersoner ligger i at det var ønskelig å teste systemet på personer som ikke nødvendigvis har stor erfaring i å sette seg inn i nye datasystemer. Dette var for å kunne avdekke hvor brukervennlig grensesnittet til systemet oppleves for disse brukerne. En tredjedel av deltakerne jobber i Teller AS som er Norges ledende leverandør av internasjonale betalingsløsninger fra Visa, MasterCard og American Express som til daglig jobber med å avdekke konkurser i sin portefølje. Testskjemaet medfølger til rapporten som vedlegg F Resultat Testingen var nyttig for å kunne konkludere om systemet er enkelt og effektivt. Ut fra resultatene fra brukertestningen ble det foreslått flere endringer. De to testelementene som er blitt mest kommentert er blant annet at velkomst e-posten bør utformes annerledes slik at den får et mer informativt og luftigere preg. I tillegg bør skriften på nettsiden gjøres større slik at brukergrensesnittet blir mer brukervennlig. De gode tilbakemeldingene fra brukertestingen konkluderer med at prototypen er velfungerende, stabil og lett å forstå for brukerne. Resultatene fra brukertestingen ligger som vedlegg A i rapporten. 66

67 Kapittel 7 7. Diskusjon Det begynte med en idè om å utvikle et konkursvarslingssystem som kunne varsle i sanntid ved hjelp av E-post og SMS. Kundene skulle også ha et brukergrensesnitt på internett hvor de kunne administrere sine egne porteføljer. Dette ble et godt utgangspunkt med stort faglig omfang, og det var innlysende allerede fra starten av at arbeidsmengden kom til å bli stor. Planleggingen av hele systemet krevde mye tid og medførte en del diskusjon i gruppen. Det viste seg tidlig at det var viktig å være nøyaktig i planleggingen helt fra begynnelsen for å få et best mulig utgangspunkt da mange detaljer måtte på plass. Et whiteboard ble blant annet kjøpt inn og benyttet for å tegne opp alle elementer som måtte på plass i systemet. Etter en del diskusjon om de forskjellige løsningene, ble det til en felles oppfatning av hvordan hele systemet skulle utvikles. Et av de store målene var å lage et system som skal være så brukervennlig som mulig. Det bør med andre ord ikke være nødvendig å ha store datakunnskaper for å benytte seg av tjenesten. Dette gjør at systemet vil kunne nå ut til en større brukergruppe, og at alt fra håndverkere til journalister kan bruke tjenesten. Det at tjenesten når deg på telefon er også en av de store fordelene med nettopp vår tjeneste. Dersom du er journalist og alltid er på farten vil du få SMS om eventuelle konkurser eller andre hendelser registrert i Brønnøysundregisteret. Hvem er systemet beregnet for? Tjenesten som nå er laget er et tilbud til alle organisasjoner, bedrifter så vel som privatpersoner som ønsker en tjeneste som holder øye med Brønnøysundsregisterets kunngjøringer som for eksempel konkurser og tvangsoppløsninger. Systemet er laget med tanke på at du skal kunne få varsel selv når du kun har mobiltelefonen tilgjengelig. Administrasjon av selve abonnementet må man gjøre via internett, hvor systemet kjører som en webbasert tjeneste. Noe som betyr at det ikke er nødvendig med noen installasjon eller faste programmer på maskinen utenom en nettleser. Alt man er avhengig av er en internettforbindelse, og en enhet med nettleser om kan koble seg til nettsiden. Systemet bør også ha muligheten til å kunne tilby brukerne muligheten til å registrere overvåkningsobjekter i flere forskjellige porteføljer slik at det kan være mulig å skille på forskjellige kategori- eller prioritetsnavn. Dette vil være nyttig om brukerne ønsker avdelingsbasert overvåkning hvor for eksempel regnskapsavdelingen og logistikkavdelingen ønsker å overvåke forskjellige objekter. En slik mulighet vil kunne styrke systemet ved at man også i fremtidige versjoner kan tilby forskjellige varslingstyper og tilleggsprodukter for hver enkelt portefølje. 67

68 En planlagt utvidelse av systemet vil la brukerne kunne administrere porteføljene ved hjelp av SMS, noe som vil bety at de kan legge til og fjerne overvåkningsobjekter tilknyttet sitt eget abonnement uansett hvor de måtte befinne seg i verden. Dette vil være med på å styrke systemet som et mobilt arbeidsverktøy og kunne være en ytterligere fordel i forhold til de andre tilsvarende tjenestene som finnes i markedet. De nødvendige komponentene er allerede på plass, slik som det SMS tekniske og det databasemessige, og dermed burde ikke dette være en omfattende oppgave sett i forhold til andre utfordringer som har oppstått i løpet av prosjektet. Eksisterer det tilsvarende tjenester? Til å begynne med ble det foretatt markedsundersøkelser for å se hva som eksisterer av lignende tjenester. Det ble funnet fem tilbydere av lignende tjenester, men resultatet fra undersøkelsen viste at disse tjenestene ofte tilbyr tilleggstjenester man ikke har behov for om man bare er ute etter konkursvarsling. Brønnøysundregisteret tilbyr også overvåkning, men de setter et tak på hvor mange objekter man kan overvåke på en portefølje. Dette kan virke begrensende på kunder som ønsker en slik tjeneste, og er dermed noe vi har valgt ikke å gjøre. Det var heller ingen av tjenestene som tilbød SMS varsling, noe som låser brukerne til en enhet med internett tilkobling. Det lave antall tilbydere med de mange og unødvendige tilleggstjenestene med fraværet av SMS muligheter gjorde at konkursvarslingssystemet ble satt i produksjon Systemutviklingen I prosessen med systemutviklingen falt valget på Agile Unified Process(AUP) som verktøy. Denne måten å arbeide på passet best, fordi utviklingen av systemet var avhengig av en del prøving og feiling. Dette ga prosjektet litt mer frie tøyler til å bruke de programmene man har best erfaring med. Fossefallsmetoden ble også vurdert, men den hadde for faste rammer, og dessuten manglet den muligheten til å gå frem og tilbake mellom fasene i prosjektet. Gruppen hadde også tidligere erfaring med AUP metoden, noe som viste seg å være nyttig. Man visste allerede om grunnelementene til denne metoden, og trengte ikke å lese seg opp på detaljert prosessdokumentasjon, men hadde dette tilgjengelig ved behov. Med AUP var det lett å få fokus på de oppgavene som var av høy verdi for prosjektet, og ved å benytte denne metoden kunne prosjektet ha fremgang selv med små tekniske utfordringer. Mottoet vårt ble etterhvert å få ting til å fungere sammen, for deretter utvikle det videre til å bli mer effektivt og robust. Med AUP som utviklingsmetode ble det åpnet for at det kunne jobbes iterativt med systemutviklingen, i motsetning til fossefallsmetoden. Dette åpnet for raske sykluser med prøv-og-feil metoden underveis, noe som var meget nyttig for kvaliteten på systemet da feil raskt ble luket bort. 68

69 Flere ting måtte være på plass før selve systemet kunne utvikles. Blant annet var det mye kontakt med Brønnøysund for å få på plass muligheten til å abonnere på kunngjøringsfiler i XML format. Normalt er dette en tjeneste som man må betale for, men konkursvarslingsprosjektet ble kategorisert som forskning, og abonnementet ble dermed kostnadsfritt. Umiddelbart etter at abonnementet hos Brønnøysund var blitt aktivert, var det en stor jobb å tolke oppbyggingen av de enkelte filtypene som ble lastet ned. Denne jobben tok lenger tid enn antatt da det skulle vise seg å være langt flere variasjoner scriptene våre måtte utvikles for å kunne ta høye for. Eksempler på to kunngjøringsfiler ligger vedlagt som vedlegg B og C. Utviklingen av XML tolkingsscriptene tok to uker lenger tid enn planlagt grunnet en mye større kompleksistet i oppbyggingen enn først antatt. Hva er systemets avhengigheter, og hvordan fungerer de? Systemet består av en del moduler som finnes i Perls modulsamling CPAN, og undersøkelser viste at det er egne moduler for MySQL, SFTP, SSH, PHP, kryptering og arraybehandling som måtte installeres for å få den ønskede funksjonaliteten tilført systemet. Modulen Net::SSH viste seg nødvendig for å få systemet til å koble seg til SFTP kontoen til Brønnøysund, og Net::SFTP var avgjørende for å kunne benytte seg av SFTP kommandoene. Tilleggspakker for RSA kryptering måtte også installeres i CPAN for å få til nøkkelutveksklingen mellom Maskin 1 og Brønnøysund SFTP serveren. Etter at SFTP kommandoene er utført tar XML behandlingen over, og denne er igjen avhengig av modulen XML::Simple som har ansvaret for tolking av XML filene som er lastet ned. Samtidig med XML behandlingen måtte moduler for MySQL lastes inn for å kunne sette inn data i databasene, og dette gjøres ved hjelp av Perl modulen DBI som inneholder alle kommandoer som Perl behøver for å kunne tolke SQL kommandoer. Programmet som skal sjekke for konkurser kjører som et PHP script inne i et Perl program, og for å få til dette måtte det i tillegg også installeres en CPAN modul som heter PHP::Include som tillater tolking av PHP kildekode. Implementeringen av alle modulene utgjorde systemets grunnmur, og var en omfattende prosess fordi dette var moduler gruppen ikke hadde kjennskap til tidligere. Uten modulene ville det ikke være mulig å få systemet til å utføre de oppgavene det skulle gjøre i følge kravspesifikasjonen, noe som gjorde at å lese seg opp i bruken av modulene av helt nødvendig. Flere av modulene var avhengig av flere undermoduler, og kompileringsfeil grunnet avhengighetsproblemer var ikke ukjent i denne delen av systemutviklingen. Parallellt med tolkingen av XML filene begynte også planleggingen av database og nettsidestruktur. En av de store utfordringene vedrørende databasestrukturen var å danne seg et bilde av hvordan systemet skulle se ut når det var ferdig utviklet. Etter hvert som nettsiden ble utviklet, og XML kompleksiteten vokste, ble også databasen utviklet videre. 69

70 Det skulle foretas tre større endringer av databasen før strukturen skulle vise seg å være solid nok for impelementering i forhold til kravspesifikasjonen. Systemet skal hente ned kunngjøringsfiler i XML format fra Brønnøysundregisteret, og disse hadde en mer kompleks oppbygging enn først antatt. Det viste seg at det var ni forskjellige typer kunngjøringer som til sammen kunne ha flere hundre variasjoner. Samtidig med denne oppdagelsen var det vanskelig å få tak i god dokumentasjon fra Brønnøysund, og kontaktpersonen som ble tildelt fra Brønnysund skiftet samtidig stilling internt, og det gikk fem uker før en erstatter var på plass. Etter oppdagelsen av den komplekse oppbyggingen av filene ble det enighet om å fordele to nye uker på milepælsplanen til å gjennomgå XML strukturen. Med ni forskjellige kunngjøringstyper, måtte det av praktiske årsaker utvikles tilsvarende mengde forskjellige script som skulle ta høyde for alle variasjonene. Det ble en tidkrevende prosess å lage scriptene som skulle behandle alle kunngjøringsfilene fra Brønnøysund. Etter at kunngjøringsfilene er hentet ned fra Brønnøysundregisteret blir de avlest, ikke modifisert, noe som tilsier at påliteligheten til dataene som presenteres er stor. Det ble i tillegg utført manuell kontroll av behandlede kunngjøringsfiler i ettertid for å kontrollere at dataene var korrekt representert i databasene. Denne manuelle kontrollen avdekket i enkelte tilfeller mangler på dataene, noe som ble sporet tilbake til Perl programmene som hadde ansvar for XML behandlingen. Resultatene av dette ble brukt som grunnlag for videreutvikling og feilretting av Perl programmene, og førte til at dataene ble mer pålitelig etter hvert som feil ble fjernet. All kunngjøringsinformasjon samles i systemets databaser, og dette kan blant annet brukes til å lage statistikker og se trender eller for eksempel hvilke deler av landet som har flest konkurser. I denne fasen av prosjektet var det mye programmering, og det ble brukt mye tid på å få alle delene av systemet til å snakke sammen. Programmeringen ble både mer omfattende og utfordrende enn tidligere prosjekter, og med dette fulgte en del programmeringsfeil som stadig måtte rettes opp, noe som var tidkrevende. Det ble utført fortløpende feilretting og omfattende systemtesting for å avdekke systemfeil. Påliteligheten til dataene har blitt bedre etter hvert som feilrettingen ble utført. For å fange opp alle feil i filbehandlingen har all output blitt overført til loggfiler som fanger opp alle feilmeldinger. Denne metoden av feilretting var meget nyttig da alle feil lett kunne spores opp, og retting påbegynnes umiddelbart etter at utdata var skrevet til loggfilen. Det ble deretter utviklet en kompleks database som i begynnelsen var konstruert på en måte som ville fungert dårlig med de kravene som ble stilt til systemet. Det skulle vise seg at det var vanskelig å ta høyde for alt som måtte være med i databasen, men på den tredje og siste versjonen ble databasen godkjent for implementering i systemet. 70

71 Behandlingen av filene førte til en overveldende mengde data i forhold til hva som var forventet. Oppfyller brukergrensesnittet kravspesifikasjonen? Brukergrensesnittet som er utviklet er en nettside i lyse farger og enkle linjer for å gjøre det så brukervennlig som mulig. Tilbakemeldinger fra brukerne som testet prototypen viste at det ikke oppstod noen problemer tilknyttet navigeringen på siden. Innholdet er logisk plassert, og knappene har navn som er forklarende for handlingen som skal utføres. Kommentarer på brukergrensesnittet som gikk i negativ retning angikk skriftstørrelsen, og mer utfyllende forklaringer og beskrivelser på flere av nettsidens funksjoner. Personene som deltok i testingen av prototypen mottok i samtlige tilfeller varslinger på både e-post, SMS og på nettsiden. Dette viser at brukergrensesnittet er velutformet, og at det også fungerer teknisk. Dette oppfyller dermed kravene som ble satt i kravspesifikasjonen til at systemet skulle være effektivt og enkelt. Rimelighetskravet følger naturlig som et resultat av at systemet er billig i drift. Er datagrunnlaget nøyaktig, og til å stole på? Filene som mottas fra Brønnøsyundregisteret er i XML format og følger samme generelle struktur, men de har gjerne stor variasjon i oppbyggingen. Dette har åpnet for muligheten til å utvikle programmer i Perl som kan gjenkjenne oppbyggingen av de forskjellige filene. Hver av varslingstypene som systemet er laget for å gjenkjenne har sitt eget program som er spesiallaget for akkurat denne typen. Det er avdekket et mangfold av variasjoner, og programmene som er utviklet for å behandle XML filene må ta høyde for alle disse. Datagrunnlaget er svært pålitelig, i og med at det kommer fra Norges største offentlige digitale arkiv. Hvordan kan dette systemet bidra til å forebygge følgene av konkurser? Kunngjøringer hentes automatisk ned fra Brønnøysundregisteret i XML format, og etter mottak behandles filene. Programmene som er utviklet for systemet vil raskt og effektivt hente ut all data fra filene og legge det inn i databasene. Brukerne av systemet vil på sin side bli varslet straks en av deres porteføljeoppføringer har et treff i konkursdatabasen. Varslene kan sendes både på e-post, SMS og kan vises visuelt på nettsiden. Denne raske og fleksible varslingen bidrar til å forebygge de negative følgene av konkurser ved at brukeren raskt kan iverksette mottiltak som kan begrense eventuelle tap. Testing av systemet viser at tekstmeldinger, e-poster og visuelle varsler på nettsiden gjør brukeren raskt oppmerksom på konkursen. Varslingssystemet kjører i tillegg regelmessige oppdateringer i løpet av dagen slik at nye oppføringer i porteføljene sjekkes opp mot konkurslistene. Denne regelmessige oppdateringen er en viktig egenskap til systemet, og gir en trygghetsfølelse for brukerne. 71

72 Hvor pålitelig er systemet, og kan andre utvikle tilsvarende system? Dataene som ligger i databasen representerer hva som er hentet ut av kunngjøringsfilene, og denne jobben utføres av flere script som har ansvaret for dette. Hjertet av systemet er perlscriptet cronscript2.pl som regelmessig kobler seg til Brønnøysundregisteret og laster ned kunngjøringsfiler som ikke er hentet ned fra før. Systemet er helt avhengig av denne prosessen, og vil svikte i sine daglige oppdateringer dersom den feiler. Påliteligheten og troverdigheten til systemet vil bli lidende dersom kunngjøringer ikke blir oppdatert regelmessig. I slike tilfeller der hvor systemet ikke får behandlet noen kunngjøringsfiler vil disse bli liggende igjen i egne mapper som er merket med kunngjøringskoden og navnet ubehandlet. Behandlingsprogrammene for alle kunngjøringstypene vil ved fullført filbehandling flytte den behandlede kunngjøringsfilen til en mappe for behandlede filer. Der hvor filbehandlingen av en eller annen grunn feiler vil ikke filen bli flyttet til behandlet, men den vil fortsatt ligge igjen som ubehandlet, og slik kan man se hvilke filer som har uforutsette variasjoner i oppbygging og struktur. I verste fall vil en behandlingsfeil føre til at filen blir liggende igjen som ubehandlet slik at systemet ikke vil lide noe nedetid som en følge av behandlingsfeil. Hvordan virker SMS systemet, og hva ligger bak? For å sende ut SMS varsler er det benyttet et program som er nevnt tidligere under navnet Gammu. Alt ansvar for SMS kommunikasjon hviler på at dette programmet kommuniserer med de egenutviklede Perl programmene som er laget for å snakke med mobiltelefonen som skal sende ut varslinger. Det var vanskelig å finne en mobiltelefon med de egenskaper som systemet hadde behov for. Telefonen måtte kunne kommunisere med Gammu ved hjelp av bluetooth, og det var vanskelig å finne en telefon som hadde denne muligheten. Valget falt på en Sony Ericsson k810i. Varslinger i systemet som sendes ut på SMS vil lagres i en tabell som heter outbox, og som er lagringssted for alle meldinger som sendes ut til brukerne. En utfordring her bestod i at all tekst som settes inn i outbox tabellen måtte lagres i HEX format, og straks meldingen var sendt måtte det samme innholdet gjøres om til vanlig tekst og lagres i tabellen for sendte elementer. Dette ble løst ved å opprette en Perlfunksjon som konverterte tekst til HEX slik at Gammu kunne tolke meldingene. SMS databasen og konkursvarslingsdatabasen måtte i begynnelsen kommunisere sammen på tvers av to systemer, og for å forenkle denne kommunikasjonen ble det derfor bestemt å flytte SMS databasen over fra Maskin 2 til Maskin 1 slik at begge databasene lå på Maskin 1. Databasene ble flyttet, men mobiltelefonen og SMS programmet som hele tiden ser etter nye konkurser i brukernes porteføljer ligger fortsatt på Maskin 2. 72

73 En utfording som oppstod etter flyttingen av databasene var at kommunikasjonen mellom Maskin 1 og Maskin 2 ble hindret av en brannmur på Maskin 1 som ikke tillot MySQL tilkoblinger på standardport Dette var en brannmurregel som var satt av Høgskolen i Oslo, og kunne ikke endres. Maskin 2 ble derfor konfigurert til å koble seg til Maskin 1 på port 33006, som er en annen port enn standardporten for MySQL. Brannmuren ble samtidig konfigurert til å videresendetilkoblinger fra til standardport 3306 slik at kommunikasjon ble tillatt. Dersom telefonen som sender ut meldingene skulle svikte, vil ikke dette påvirke varslingene som allerede ligger lagret i databasen klar for utsending. Alle meldingene som er lagret i databasen vil sendes straks telefonen er påslått, og en gang i minuttet gjennom hele døgnet vil et eget program kontrollere denne tabellen for nye meldinger som ligger klare for sending. Hva om databasene skulle svikte? Finnes det rutiner for sikkerhetskopiering? Dersom databasene skulle svikte vil dette være mulig å kunne gjenopprette ved importere backupfilene som blir opprettet regelmessig av kommandoen mysqldump --opt -u <brukernavn> -p --password=<passord> -B <databasenavn> gzip > databasebackup<dato>.dump.gz. Denne kjører som bakgrunnsjobb en gang i timen og tar backup av den valgte databasen med alt innhold og kan brukes til gjenoppretting ved behov. Backup lagres over 30 dager, og slettes fortløpende etter dette. Dersom de ferdigbehandlede filene i konkursvarslingssystemet av en eller annen årsak skulle bli slettet fra disk, vil programmet cronscript2.pl som kjører en gang i timen koble seg til Brønnøysund og kjøre en sammenligning over hvilke filer som allerede er lastet ned, og hvilke som ikke er det. Slik vil systemet alltid kunne opprettholde en korrekt filliste over de nyeste kunngjøringene selv om systemet har opplevd å miste alle kunngjøringsfilene. Skulle mappestrukturen forsvinne er det tenkt å benytte seg av Perls funksjon for å sjekke om mappen finnes. Skulle ikke mappen eksistere vil scriptet opprette denne slik at man unngår systemsvikt ved nedlasting av filer til ikke-eksisterende mappenavn. Kan det lages tilsvarende systemer? Muligheten for at andre kan lage et lignende system er til stede, men det er vanskelig da man må ha tilgang på XML filene og dokumentasjonen fra Brønnøysund. XML dokumentasjon er ikke fritt tilgjengelig for alle, og man er avhengig av å kontakte Brønnøysundregisteret for å få tilsendt denne. Et XML abonnement er i tillegg nødvendig for å få tilsendt rammeverket for XML filene som er definert i XSD (XML Schema) format. XSD filer er å betrakte som det samme som DTD (Document Type Definition) som begge har som formål å validere XML dokumenter med hensyn til struktur og innhold. Det er derfor er en omfattende jobb å utvikle programmer som kan ta høyde for de mange variasjonene som kan forekomme i filene. Dette gjør det svært vanskelig, men ikke umulig, å 73

74 gjenskape systemet. Datagrunnlaget for andre systemer vil alltid være det samme som vårt system benytter fordi filene vil være uforandret etter publisering hos Brønnøysund. Dette tilsier også at det alltid er mulig å kunne reprodusere de samme resultatene for andre utviklere dersom de ønsker dette. Det finnes ingen dokumentasjon på tidligere systemer eller hva slags verktøy som kan benyttes under utviklingsfasen. Dette gjør utviklingen av et slikt system tidkrevende da alt må utvikles fra grunn av. Det økonomiske perspektivet er også viktig. Det koster kr for å abonnere på XML filene som omhandler konkurser fra Brønnøysundregisteret. Prisen kombinert med at det kommer ut ca kunngjøringsfiler pr. dag gjør at systemet hele tiden behandler nye filer med potensielt flere variasjoner. Systemet er dermed sårbart for å støte på nye XML variasjoner, og vil kunne oppleve behandlingsfeil underveis. Risikoen for at filer ikke behandles er dermed alltid til stede, noe som gjør at man konstant må være klar for å kunne oppdatere systemet med ny kode. Regelmessig oppfølging bør utføres for å kunne forsikre seg om at ingen filer ligger ubehandlet etter nedlasting fra Brønnøysund, slik at man vet at brukerne alltid mottar den seneste tilgjengelige informasjon som er mulig å innhente Prosess Ved prosjektets oppstart samlet gruppen seg og lagde en milepælsplan for prosjektet. Denne skulle være grunnlaget for de store målene gjennom prosjektet, og sette tidsfrister for når de forskjellige tingene skulle være ferdig. Milepælsplanen skulle sørge for at vi holdt et stramt tidsskjema, og samtidig kunne levere en god prototype. Det har vært utført et par revisjoner av planen grunnet utfordringer underveis i systemutviklingen, men bortsett fra dette har tidskjema holdt som planlagt. For å kvalitetssikre prosessen etter at milepælsplanen ble revidert foretok gruppen en midtveis evaluering for å få kartlagt hva som hittil var gjort og hva som måtte gjøres for å sørge for at prosjektet skulle holde tidsskjemaet. Gruppen følte at evalueringen var viktig for å kunne holde fokus rettet fremover, og for å avdekke potensielle svakheter som måtte arbeides med. Midtveisevalueringen ligger som vedlegg E til rapporten. Arbeidsoppgavene ble fordelt slik at alle gruppemedlemmene hadde tilsvarende stor arbeidsmengde. Dersom utfordringene til tider ble for store ble arbeidsfordelingen endret slik at flere jobbet sammen for å løse problemet i felleskap. Alle i gruppen har forskjellige personlige egenskaper og erfaringer, og arbeidsoppgaver ble fordelt slik at vedkommende med størst kompetanse innenfor enkelte fagområder ble tildelt ansvaret for denne. Det er samtidig forsøkt å være så inkluderende som mulig i de fleste oppgavene, og på denne måten har alle gruppemedlemmene kjennskap til hver utviklingsmodul av systemet. Gruppen har holdt sammen gjennom hele studiet, noe som gjør at gruppemedlemmene kjenner hverandre godt og vet hvem som er i best stand til å utføre de oppgavene som må 74

75 utføres. Gruppetilliten er solid, og terskelen for å spørre om hjelp er lav de gangene man står fast med et problem som må løses Prototypen Den ferdige prototypen kunne ha støttet import av porteføljer i forskjellige filformater. Det kan nevnes populære formater som Excel og CSV format som brukerne skulle ha kunnet laste opp på nettsiden. Generering av kunngjøringsvarsler i PDF format for nedlasting på nettsiden er også en funksjon som hadde vært ønskelig å implementere i en fremtidig versjon av systemet. Opplastingen av filene er tenkt slik at brukerne trykker på en knapp for opplasting, og deretter følger en dialog som ber brukerne å velge fil som skal lastes opp. Etter opplasting til systemet skal filen behandles og nye elementer skal automatisk legge inn i brukerens portefølje. PDF rapporten er tenkt løst ved at brukeren trykker seg inn på det varslede elementet, og får opp en ny side med informasjon. Der er det tenkt en knapp som lar brukeren velge å laste ned rapporten i utskriftsvennlig PDF format, noe som ville vært en nyttig funksjon for utskrift og arkivering av alle varsler. I de tilfeller hvor man sier opp abonnementet vil man da sitte igjen med en PDF fil eller utskrift som viser varselet til oppføringen. SMS administrasjon av kundeporteføljene anses også som et viktig tilskudd til en fremtidig versjon av systemet. Muligheten til å kunne legge til, og fjerne elementer i porteføljene vil være en viktig bidragsyter til å gi systemet en fordel ovenfor de andre tjenestene som finnes. En ny funksjon der brukerne legger til et nytt porteføljeelement er tenkt implementert. Her er det tenkt at brukerne skriver inn organisasjonsnummeret til bedriften de ønsker å legge til, og systemet finner automatisk firmanavnet hos Brønnøysund, og lagrer deretter elementet etter at brukeren har bekreftet at organisasjonsnummer og firmanavn stemmer overens Samfunnsnytte Konkursvarsling er blitt et viktig hjelpemiddel for næringslivet da konkurser inntreffer oftere enn før, og de rammer næringslivet i stadig større omfang og kraft. Nå som man er inne i det største toppåret for konkurser siden børskrakket i 1929 trenger man tjenester som kan varsle om konkurser så snart de oppstår, og det blir stadig viktigere å bli mer portabel enn før. Derfor førte behovet for et enkelt og rask varslingssystem til ideen om å utvikle et konkursvarslingssystem med SMS varsling som skal kunne bidra til å begrense de negative følgene av konkurser uansett hvor man måtte befinne seg i verden. 75

76 76

77 Kapittel 8 8. Konklusjon Målet for dette hovedprosjektet har vært å utvikle et varslingssystem som kan varsle næringslivet før store summer går tapt som en følge av ringvirkningene etter en konkurs. Innledningsvis ble det foretatt en markedsundersøkelse som fastslo at behovet for en mer mobil varslingstype var til stede. De eksisterende løsningene viste seg å tilby langt mer enn bare konkursvarsling, og de oppfattes som uoversiktlige og lite fleksible grunnet det store utvalget av ekstratjenester. Det ble tidlig klart at å tilby varsling via SMS ville kunne gi systemet noe ekstra som de andre systemene ikke har, nemlig portabilitet. Spesielt vil systemet få et fortrinn ovefor de som er mobile i arbeidslivet, for eksempel journalister, forretningsfolk og selgere som er avhengig av å få oppdateringer om sine partnere straks det inntreffer endringer. Fordelene ved å tilby varslinger ved hjelp av SMS er at man ikke er avhengig av en PC med internett, og ikke minst at man vil få varsel uansett hvor man befinner seg i verden. Tjenesten er et tilbud til alle organisasjoner, bedrifter og privatpersoner som ønsker en tjeneste som varsler om konkurskunngjøringer. For å administrere brukerkontoen sin må brukerne av tjenesten besøke nettsiden, hvor man så kan vedlikeholde sine porteføljer og brukerkontoinformasjon. Brukerne kan også registrere seg med forskjellige abonnementer som tilbyr en økende grad av mulighet til å skreddersy tjenesten alt etter hvilket behov man har. Det er i tillegg lagt opp til at brukerne kan lagre overvåkningsobjektene i flere forskjellige porteføljer slik at muligheten for å skille på egne eksempelvis kategorier eller prioritet er mulig. Flere brukere kan også administrere flere porteføljer dersom disse er kategorisert som offentlige og tilhører samme abonnement. Slik kan systemet tillate avdelingsbasert overvåkning, og fleksibiliteten mener vi gjør at systemet passer godt for mange forskjellige kunde- og brukertyper. En av systemets styrker ligger i at det ikke er nødvendig med noen installasjon eller faste programmer på maskinen utenom en nettleser. Alt man er avhengig av er en internettforbindelse, og en mobil enhet med nettleser om kan koble seg til tjeneste. Datagrunnlaget for systemet er XML filene som hentes ned fra Brønnøysund. Alle kunngjøringstypene må behandles forskjellig, og egne programmer i Perl ble utviklet for å hente ut data fra disse, og legge det inn i databasene. Kompleksisteten til kunngjøringsfilene gjenspeilet seg også i databasene, og gjorde at systemet ble langt større i omfang enn først forventet. Resultatene fra bruker- og systemtester viser at brukervennligheten, og SMS varsling gir systemet fordeler i forhold til de andre tjenestene som eksisterer. Systemet vil samtidig være rimeligere enn de andre tjenestene på markedet fordi det ikke 77

78 tilbyr en mengde ekstratjenester, men det fokuserer på de kunngjøringstypene som omhandler konkurser. Fokuset på spesialiserte varslingsområder vil holde prisene på systemet på et lavere nivå enn konkurrentene, og vil være en markedsfordel. Ser man tilbake på problemstillingen Hvordan varsle næringslivet på deres egne premisser om konkurser i deres portefølje på en enkel, rimelig og effektiv måte? viser funnene i rapporten at dette kan oppnås. Systemet utfører de oppgavene det er satt til å gjøre på en hensiktsmessig og praktisk måte ved at det enkle brukergrensesnittet kombinert med raskt varsel gir inntrykk av et system som er til å stole på. Dersom noen hendelser inntreffer i porteføljene til brukerne vil et varsel om dette straks sendes brukerne på web, e-post og ved hjelp av SMS slik at det er mulig å ta sine forhåndsregler. Utviklingen av et system som kan varsle næringslivet på deres egne premisser om konkurser i deres kundeportefølje på enkel, rimelig og effektiv føler vi dermed er oppnådd. Fremtidig Arbeid Systemet er en fungerende prototyp som fortsatt er under utvikling, og det er flere funksjoner som er tenkt implementert i ettertid. Utvikling av en modul som lar brukerne laste opp sine porteføljer i populære filformater, der systemet importerer alle elementer ved en helautomatisk prosess, vil gjøre systemet mer brukervennlig for de som har mange kunder de ønsker å overvåke. For å gjøre systemet mer mobilt er det tenkt å implementere funksjoner som lar brukerne legge til, og samtidig fjerne porteføljeelementer via SMS. Brukerne kan dermed benytte tjenesten helt uten å være tilknyttet internett, noe som gir systemet stor fleksibilitet. Brukervennligheten på selve nettsiden er tenkt forenklet ved å utvikle en funksjon tilhørende prosessen der brukerne legger til et nytt porteføljeelement. Her er det tenkt at brukerne skriver inn organisasjonsnummeret til bedriften de ønsker å legge til, hvoretter systemet kontrollerer organisasjonsnummeret mot Brønnøysundregisteret før lagring i porteføljen. Mange bedrifter arkiverer ofte hendelser i permer, og derfor ser man også behovet for at systemet kan tilby en nedlastbar varslingsrapport for hver hendelse som er utformet i utskriftsvennlig PDF format. Dette er også nyttig som dokumentasjonsformål dersom brukerne viser seg å skulle si opp abonnementet, og ikke lenger har tilgang til systemet. 78

79 Kilder Altinn. (2010). altinn.no. Hentet fra Ambysoft. (2010). ambysoft.com. Hentet 2 24, 2010 fra Apache. (2010, 2 12). apache.org. Hentet fra Bræk, R. (1983). Håndbok i systemarbeid. Tapir forlag. Brønnøysundsregisteret. (2010, 2 14). brreg.no. Hentet fra Dun & Bradstreet. (2009, 12 7). db24.no. Hentet 2010 fra er+hver+uke.b7c_wbbu1i.ips Gammu. (2010, 3 20). gammu.org. Hentet fra mysql. (2010, 2 20). mysql.com. Hentet fra PHP. (2010, 3 21). php.net. Hentet fra Rønningen, R. (1995, 7 20). oslo.net. Hentet fra VG. (2010, 1 22). vg.no. Hentet fra Wiącek, M. (2010, 3 10). mwiacek.com. Hentet fra Wikipedia, Black box testing. (2010, 2 14). wikipedia.org. Hentet fra Wikipedia, ebay. (2010, 1 22). wikipedia.org. Hentet fra Wikipedia, Facebook. (2010, 1 22). wikipedia.org. Hentet fra Wikipedia, Finanskrisen. (2010, 5 21). wikipedia.org. Hentet 2010 fra Wikipedia, Insolvens. (2010, 5 10). wikipedia.org. Hentet 2010 fra 79

80 Wikipedia, LAMP. (2010, 5 14). wikipedia.org. Hentet fra Wikipedia, White box testing. (2010, 2 14). wikipedia.org. Hentet fra Wikipedia, YouTube. (2010, 1 21). wikipedia.org. Hentet fra 80

81 Litteraturliste Andersen, E. S., & Schwencke, E. (2007). Prosjektarbeid. Bekkestua: NKI Forlaget. Castro, E. (2007). HTML, XHTML & CSS Sixth Edition. Berkeley CA: Peachpit Press as a division of Pearson Education Inc. Hasle, T. E. (2008). Systemutvikling. Oslo: Cappelen Damm AS. Horgen, S. A. (2007). Webprogrammering i PHP 2. utg. Oslo: Gyldendal Norsk Forlag. Nemeth, E., Snyder, G., & Hein, T. E. (2008). LINUX Administration Handbook. Stoughton MA: Pearson Education Inc. Pfleeger, C. P., Pfleeger, S. L., & Ware, W. H. (2008). Security in Computing Fourth Edition. Westford: Pearson Education. Inc. Stone, D., Jarrett, C., Woodroffe, M., & Minocha, S. (2005). User Interface Design and Evaluation. San Francisco CA: Elsevier, Inc. 81

82 Vedlegg A Brukertesting Denne testrapporten beskriver testene som er utført på prototypen, og resultatene fra testene skal brukes til videreutvikling av systemet. Systemet vi har laget har forskjellige rettighetsnivåer, og testen er derfor hovedsakelig konsentrert rundt en ekstern administrator som har tilgang til alle systemfunksjoner. Det er ikke være nødvendig å teste brukere med lavere funksjonalitet da det ikke finnes andre funksjoner ut over det administratoren kan utføre. Etter at systemutviklingen var utført og avsluttet, testet vi systemet gjennom at brukere utførte forhåndsbestemte handlinger. Alle testene foregikk på stasjonære datamaskiner hvor testpersonen satt alene og utførte testene mens en obervatør fra prosjektgruppen overvar det hele uten å gripe inn. Det var ønskelig å teste brukervennligheten og funksjonaliteten til brukergrensesnittet for å se om testpersonene fant de rette funksjonene på de forventede plassene. I utgangspunktet var fokus rettet mot først og fremst fagkyndige personer, men også noen testbrukere fra allmennheten som kanskje ikke har like god kjennskap til faguttrykk på området ble valgt testet. Dette for å se om brukergrensesnittet var logisk oppbygget for både uerfarne og erfarne brukere. Oversiktstabellen nedenfor viser testscenarioene som ble presentert for brukerne. Rettighetsnivå Funksjon Hva er testet Alle registrerte brukere Logge inn Logge inn med korrekt brukernavn/passord. Alle registrerte brukere Legge til org.nr. i ditt portefølje At det er mulig å legge til nye org.nr. i portefølje for overvåking. Alle registrerte brukere Fjerne ett org.nr. fra portefølje At det er mulig å fjerne en allerede overvåket bedrift. Alle registrerte brukere Endre info på ett overvåket org.nr. At det er mulig å endre på en oppføring i porteføljet. Alle registrerte brukere Oppdatere brukerkontoinformasjon At det er mulig å oppdatere brukerinformasjonen sin. Må være nivå 4 Legge til en bruker som skal få tilgang i ditt portefølje Er det forståelg fremgangsmåte og fungerer det som det skal? Alle registrerte brukere Søke etter ett org.nr. i ditt At man får søkeresultat portefølje Alle registrerte brukere Søke etter ett feil org.nr. Får man opp at du ikke overvåker dette nummeret? Alle registrerte brukere Logge ut Se at man logger ut fra kontoen, og at det foretas en 82

83 sjekk, så dersom man trykker tilbake kommer man ikke inn uten innlogging. Alle besøkende og brukere Linker At alle linker fungerer Nivå 4 bruker Registrere bruker At brukerregistrering fungerer uten komplikasjoner Det ble valgt å teste ut de funksjoner som systemet tilbyr, blant annet å legge til nye organisasjonsnumre, opprette/endre/slette oppføringer i portefølje og endre på kontoinformasjon som telefonnumre, adresser, kontaktperson. Før brukertestene startet var det nødvendig med evaluering av skjemaene for å se om de var riktig utformet, og om det var noe som var manglet. Det måtte også forsikres om at det ikke kunne oppstå noen misforståelser underveis i testingen. Resultat Ut i fra resultatene av brukertestingen har vi fått en del informasjon som hjelper oss til å forbedre vårt system. Vi har testet registreringsskjemaet og ut i fra resultatene ser det ut til at de fleste forstår utfyllingsfeltene, det er en del kommentarer på skriftstørrelsen på feltene. Det ser også ut til at de fleste forsto innholdet i e-posten som blir sendt ut ved registrering, det er 2 kommentarer på at e-posten kunne vært tydeligere. Alle greide å logge inn uten problemer. Legge til i portefølje ble fullført av 9 av 10 testpersoner, men det det var en som ikke forsto hva portefølje var, og skjønte dermed ikke oppgaven. Det er samtidig flere kommentarer på at portefølje er utydelig og at vi kanskje burde beskrive hva som skal stå i dette feltet. De som utførte oppgaven fikk lagt til oppføring i portefølje og siden disse oppføringene allerede er slått konkurs mottok de sms og e-post fra systemet. Det er altså ingen tekniske problemer ved varslingene. Når det kommer til punktet hvor testpersonene skal endre eller slette oppføringer i portefølje er det ingen som opplevde problemer med dette. Dette gjelder også for endring av brukerinformasjon. Søkefunksjonen fungerte også i 100% av tilfellene og ingen hadde noen problemer med dette. 83

84 Kommentarer fra brukerne Kommentarer Antall Liten font 4 Ikke forstå portefølje 5 Utydelig mail 2 Vanskelig å velge rettighet 1 Suksessrate Oppgave Utført Mulige Kommentar Fullført registrering Logge inn Legge til i portefølje 9 10 Mottatt SMS varsel 9 9 *som følge av forrige feil Mottatt e-post varsel 9 9 *som følge av forrige feil Fjerne organisasjon Endre organisasjon Endre brukerinformasjon Søke med firmanavn i portefølje Søke med org.nr i portefølje Alt ble vist i porteføljet Registrere ny bruker på samme abonnement 8 10 *på grunn av dobbel registrering av samme e-post 84

85 Vedlegg B Xml kunngjøring fra Brønnøysundregisteret eksempel 1 85

86 86

87 Vedlegg C Xml kunngjøring fra Brønnøysundregisteret eksempel 2 87

88 88

89 Vedlegg D Milepælsplan 89

90 90