Altinn II. Overordnet spesifikasjon

Transkript

1 Altinn II Overordnet spesifikasjon

2 Innhold 1 Innledning Mål for løsningen Målbilde for Altinn II versjon Bruk av løsningen Brukerprosesser Etablere og vedlikeholde tjenester i Altinn Benytte Altinn Etablere og vedlikeholde tjenester i Altinn Brukergrupper - tjenesteutvikling Utvalgte bruksscenarioer - tjenesteutvikling Benytte Altinn Brukergrupper - sluttbrukerløsning Utvalgte bruksscenarioer - sluttbrukerløsning Overordnede krav, føringer og løsningsprinsipper Teknisk løsning/arkitektur Prinsipp Prinsipp Prinsipp Prinsipp Prinsipp Prinsipp Prinsipp Prinsipp Prinsipp Prinsipp Funksjonelt/Brukskvalitet Suksesskriterier Ønskede systemegenskaper Løsningsprinsipper tjenesteutvikling Løsningsprinsipper sluttbrukerløsning Overordnet beskrivelse av tjenesteutviklingsløsningen Prosess for tjenesteutvikling Prosess for arbeidsflyt Forhold til sluttbrukerløsningen Funksjonelle områder Tjenesteversjoner Dokumenter og samhandling Publisering/Infoportal Migrering og testing Tjenestemetadata Tjenesteinnhold Språk Verktøykasse Altinn II Side 2 / 54

3 6.4.9 Tjenestekategorivedlikehold Brukerstøtte Tilgangsadministrasjon Navigasjon og sideinndeling Overordnet beskrivelse av sluttbrukerløsningen Forhold til eksisterende løsning Funksjonelle områder Tjeneste-/listehåndtering Innsendingstjenester Meldingstjenester Innsynstjenester Lenketjenester Varsel Preutfylling Arkiv Grunndatavedlikehold Infoportal Abonnement Sluttbrukeroppfølging Autentisering og autorisering Brukerstøtte Brukerinnstillinger Tilgangsadministrasjon sluttbruker Tilgangsadministrasjon klient Tilgangsadministrasjon sluttbrukersystem Formidlingstjenester Navigasjon og sideinndeling Sluttbrukersystemutviklere Overordnet beskrivelse av teknisk løsning Arkitekturmodell Løsningsarkitektur Informasjonsarkitektur Integrasjonsarkitektur Sikkerhetsarkitektur Prosesseringsarkitektur og teknisk infrastruktur Applikasjonsarkitektur Utviklings- og testarkitektur Driftsarkitektur Struktur og sammenheng i detaljspesifikasjon Overordnet spesifikasjon Teknisk spesifikasjon Funksjonell spesifikasjon Avviksdokument Spesifikasjon av struktur og innhold i dokumentasjon Systemdokumentasjon for funksjonalitet som videreføres på eksisterende plattform54 Altinn II Side 3 / 54

4 1 Innledning Overordnet spesifikasjon er toppdokumentet for den detaljerte spesifikasjonen for Altinn. Dokumentet dekker de overordnede beskrivelsene av løsningen, og fungerer som en leseveiledning for dokumentene som inneholder de detaljerte beskrivelsene. Både teknisk og funksjonell side er dekket. Dette dokumentet er beregnet for de som ønsker en overordnet innføring i løsningen uten å gå i detaljer. Det er også egnet for de som kjenner detaljer om enkeltdeler av løsningen, men ønsker å se dette i en større kontekst. Denne detaljspesifikasjonen skal dekke versjon 1 av Altinn II. Dette dokumentet behandler derfor i hovedsak løsningen per versjon 1 av Altinn II. Behandling som omhandler løsningen som helhet per målbilde er betegnet Altinn uten løsningsbetegnelse (I/II) og der hvor det skilles mellom versjon 1 og versjon 2 av Altinn II er dette angitt. Dokumentet er strukturert i følgende kapitler: 1. Innledning Innledning til dette dokumentet 2. Mål for løsningen Hva skal Altinn være, og hvilke utfordringer skal løsningen besvare. 3. Målbilde for Altinn II versjon 1 Hvilken del av målene for løsningen er det tiltenkt at Altinn II versjon 1 skal dekke. 4. Bruk av løsningen Oversikt over de identifiserte brukergruppene i Altinn og de arbeidsprosessene de utfører. 5. Overordnede krav, føringer og prinsipper Beskrivelse av de overordnede krav, føringer og prinsipper som gjelder for løsningen. 6. Overordnet beskrivelse av tjenesteutviklingsløsningen En høynivå introduksjon til den delen av løsningen hvor tjenesteeiere utvikler sine tjenester. 7. Overordnet beskrivelse av sluttbrukerløsningen En høynivå introduksjon til den delen av løsningen som er tilgjengelig for sluttbrukere. Det er her tjenestene utviklet av tjenesteeiere benyttes. 8. Overordnet beskrivelse av teknisk løsning En høynivå introduksjon til den tekniske arkitekturen i løsningen. 9. Struktur og sammenheng i detaljspesifikasjon Kapitelet er en leseveiledning til detaljspesifikasjonen, og angir hvilke dokumenter detaljspesifikasjonen består av og hva disse inneholder. Altinn II Side 4 / 54

5 Tjenestenav Integrasjon Tjenestekatalog Informasjonssikkerhet Transaksjonsnav Overordnet spesifikasjon.doc 2 Mål for løsningen Altinn skal være en fremtidsrettet plattform for elektronisk kommunikasjon og samhandling. Målet skal oppnås ved at Altinn blir et samhandlingsnav for offentlig norsk e-forvaltning. Som transaksjonsnav skal Altinn sørge for håndtering av sluttbrukertjenester som innsendings-, meldings- og innsynstjenester. Som tjenestenav skal Altinn være tilbyder av offentlige fellestjenester som kan gjenbrukes på tvers av offentlige enheter. Tjenestene som tilbys gjennom Altinn kan produseres lokalt i Altinn eller hos tredjeparter. Altinn vil operere som et samlende punkt for disse tjenestene, for å tilfredsstille en enhetlig infrastruktur for offentlige IT-tjenester. Samhandlingstjenester Innsending Melding Innsyn Formidling Autentisering Signering Fullmakter Varsling Katalog (Register) Arkiv Preutfylling / validering Skjemamotor Figur 1 Felles offentlig infrastruktur med Altinn som samhandlingsnav Altinn skal være basert på en tjenesteorientert arkitektur. Løsningen skal være modulær, for å støtte krav til utvidelser og gjenbruk på tvers av tjenester, eksterne aktører og aksessmåter (portal, sluttbrukersystemer, etc.). Innføring av nye tjenester skal kunne gjøres uten at det påvirker sentrale systemkomponenter og eksisterende tjenester realisert i løsningen. Regjeringens IKT-politikk og fornyingsstrategi setter et høyt ambisjonsnivå for elektronisk samhandling i og med offentlig sektor. Stortingsmelding nr. 17 ( ) viser hvordan Altinn passer inn i et felles offentlig IKT-landskap. Altinn II Side 5 / 54

6 Figur 2 Felles arkitektur for IKT i offentlig sektor 1 Altinn skal ha komponenter både i tjenestelag og presentasjonslag, og forholder seg til lagdelingen. Tjenester som produseres eller tilbys i Altinn skal ikke være knyttet mot presentasjon, slik at de kan gjenbrukes utenfor Altinn-løsningen. Presentasjonslaget i Altinn kan benytte disse tjenestene for presentasjon i løsningen. For å nå målbildet om frikobling fra presentasjonslaget, vil Altinn II inneha et rammeverk 2 for å kunne tilby sluttbrukertjenester og andre portalsider til eksterne portaler. Portaluavhengighet vil ikke være en del av første versjon av løsningen, men vil kunne utvides med dette fra versjon 2. I første versjon vil man lage en løsning som vil kunne utvides med portaluavhengighetsrammeverket. 1 Kilde: Tilbudsinnbydelsesdokument_vedlegg_2_Målbilde_v2.0.doc 2 Rammeverk for portaluavhengighet er ikke priset inn i fastpris og må eksplisitt bestilles. Altinn II Side 6 / 54

7 Utviklingsarkitektur Driftsarkitektur Overordnet spesifikasjon.doc 3 Målbilde for Altinn II versjon 1 Leveranseløpet for ny Altinn-løsning (prosjektbetegnelsen Altinn II benyttes for å skille mellom ny (Altinn II) og eksisterende (Altinn I)) er delt inn i to; versjon 1 og versjon 2. Versjon 1 vil ha støtte for de mest sentrale eksisterende tjenestene, innsending og melding, og vil danne grunnlaget for de nye tjenestetypene som kommer i versjon 2. For å understøtte dette, vil versjon 1 i hovedsak være en utvikling av ny plattform med tilsvarende funksjonalitet som eksisterende løsning. Løsningen vil tilby tjenesteutviklere å migrere sine eksisterende tjenester til ny plattform slik at man får en glidende overgang fra gammel til ny løsning. Dette gjør at både tjenesteeiere og eksterne aktører, spesielt sluttbrukersystemleverandører, får et langt tidsvindu for å tilpasse seg den nye løsningen. Versjon 1 skal i størst mulig grad skjerme tjenesteeiere og eksterne aktører for endringer, bl.a. ved å beholde eksisterende grensesnitt på en slik måte at det ikke fremtvinger endringer i eksterne systemer. Referansemodellen under viser en overordnet funksjonell og teknisk nedbrytning av Altinn II versjon 1. Altinn II Funksjonelle og tekniske områder Funksjonell nedbrytning Funksjonsområder tjenesteutvikling Funksjonsområder sluttbrukerløsning Kjerneprosesser Tjeneste-spesifikasjon Kjerneprosesser Tjenesteversjoner Dokumenter og samhandling Tjenestemetadata Tjeneste-/ listehåndtering Innsendingstjenester Meldingstjenester Versjon 2: Innsynstjenester Lenketjenester Versjon 2: Samhandlingstjenester Versjon 2: Transaksjonstjenester Publisering/ Infoportal Migrering og testing Språk Arkiv Varsel Abonnement Preutfylling Grunndatavedlikehold Infoportal Formidlingstjenester Tjenesteinnhold Støtteprosesser Støtteprosesser Sluttbrukeroppfølging Autentisering og autorisering Brukerstøtte Versjon 2: Betaling Tjenestekategorivedlikehold Verktøykasse Tilgangsadmin Brukerstøtte Brukerinnstillinger Tilgangsadm. sluttbruker Tilgangsadm. klient Tilgangsadm. sluttbrukersystem Versjon 2: Bruksstatistikk Teknisk nedbrytning Applikasjonsarkitektur Sikkerhetsarkitektur Integrasjonsarkitektur Informasjonsarkitektur Konfidensialitet & Integritet Logging, Sporing Logghåndtering I&AM Tjenesteoversikt Komponentintegrasjon Sluttbrukersystem - integrasjon Sikkerhetsintegrasjon Ekstern portalintegrasjon Konseptuell datamodell Tilgjengelighet Sikkerhetinfrastruktur Offentlige registerintegrasjon Etatintegrasjon Statistikkintegrasjon Konvertering Teknisk Infrastruktur Maskinvare / OS Nettverk Lagring Databasetjenester Web- og applikasjonsservere SOA infrastruktur Skjemamotor Arbeidsflyt Figur 3 Referansemodell Altinn II Side 7 / 54

8 Funksjonell nedbrytning De funksjonelle områdene for sluttbrukerløsningen (forkortes SBL ) og tjenesteutviklingsløsningen (forkortes TUL ) er delt inn i kjerneprosesser og støtteprosesser. Kjerneprosesser omfatter den funksjonalitet som tjenesteeiere, virksomheter og privatpersoner trenger for å utføre elektroniske tjenester mellom det offentlige og næringsliv/ privatpersoner Støtteprosesser omfatter den funksjonalitet som trengs for å sette opp, administrere og følge opp bruk av Altinn for tjenesteeiere, virksomheter og privatpersoner. Herunder ligger også oppgaver knyttet til effektiv tjenesteyting for profesjonelle sluttbrukere som regnskapsførere og revisorer m.fl. Senere kapitler i dette dokumentet beskriver de funksjonelle områdene i mer detalj. De funksjonelle områdene er igjen delt inn i Use Case (brukstilfeller) som er detaljert beskrevet i vedleggene til detaljert funksjonell spesifikasjon. Teknisk nedbrytning Den tekniske nedbrytningen er delt inn i følgende områder: Applikasjonsarkitektur Driftsarkitektur Informasjonsarkitektur Infrastruktur Infrastrukturtjenester Integrasjonsarkitektur Løsningsarkitektur (overordnet) Utviklings- og testarkitektur Sikkerhetsarkitektur Senere kapitler i dette dokumentet beskriver de forskjellige delene i mer detalj. Overordnet beskrivelse av forholdet til Altinn I Versjon 1 av Altinn II vil forholde seg til eksisterende løsning (Altinn I), da denne vil fortsette å eksistere. Følgende føringer og tiltak er gitt for at de to løsningene skal kunne sameksistere: Skal være en løsning sett utenfra (Altinn). Tjenesteeiere og brukere av løsningen skal ikke måtte forholde seg til to løsninger. Dette håndteres ved at eksterne tjenester rutes på innsiden, og ved at portalen tilbyr felles innlogging og brukergrensesnitt Altinn I skal ikke forholde seg til Altinn II. For fellestjenester, skal disse ligge i Altinn I så fremt det lar seg gjøre. Eksempelvis vil registerdatabasen (personer, organisasjoner, roller, rettigheter, brukerprofiler, etc.) beholdes i Altinn I, og Altinn II benytte tjenester fra Altinn I for autentisering og autorisering. Det innføres et eget sameksistenslag mellom Altinn I og Altinn II, slik at tjenester i Altinn II ikke forholder seg til Altinn I direkte. Dermed vil det, når Altinn I skrus av, ikke være behov for å endre på eksisterende tjenester i Altinn II Altinn II Side 8 / 54

9 Se også kapittelet Integrasjon mot dagens Altinn-løsning i TA230 Detaljert teknisk spesifikasjon Løsning. Overordnet beskrivelse av forholdet til Altinn II versjon 2 Altinn er en løsning som skal leve lenge. Det er derfor nødvendig å ta høyde for senere versjoner av løsningen, og ikke innføre elementer i løsningen som begrenser muligheten for senere oppgraderinger. Versjon 1 vil legge grunnlag og føringer for senere versjoner av løsningen, men skal ikke innføre begrensninger ut over dette. Løsningen støtter seg tungt på bruk av standardprodukter. En sentral føring er at det ved bruk av standard programvare så langt det lar seg gjøre benyttes integrasjonsmåter som er dokumentert av leverandør av programvaren, sånn at dette ikke begrenser muligheten for å oppgradere til nye versjoner av standardproduktene. I analyse og design legges det vekt på at valg som gjøres ikke begrenser mulighetene i ny løsning. Eksempelvis gjelder dette informasjonsmodell som må ta høyde for nye tjenestetyper og applikasjonsarkitektur som må detaljere tjenester på korrekt detaljnivå. Altinn II Side 9 / 54

10 4 Bruk av løsningen I dette kapitlet gis en oversikt over de prosesser som støttes av Altinn per versjon 1 av Altinn II, ulike brukergrupper og deres hovedoppgaver. Videre beskrives utvalgte scenarioer som utnytter kjernefunksjonaliteten i Altinn. 4.1 Brukerprosesser Figuren nedenfor gir en oversikt over brukerprosessene som er identifisert for Altinn. Brukerprosesser i Altinn Etablere og vedlikeholde tjenester i Altinn Benytte Altinn Kjerneprosesser Kjerneprosesser Definere, utvikle og vedlikeholde tjenester - Designe - Definere - Utvikle - Enhetsteste - Migrere Systemteste - Akseptanseteste - Produksjonsette Publisere informasjon Finne og velge tjeneste - Finne info om offentlige tjenester - Sende varsel til brukere - Bli formidlet til tjeneste - Autentisere og autorisere bruker Benytte tjeneste i Altinn - Innsendingstjeneste - Innsynstjeneste - Meldingstjeneste - Lenketjeneste (flere i versjon 2) Utveksle data med tjenesteeier - Sende data - Motta data Finne tilbake til mottatt og innsendt informasjon Støtteprosesser Støtteprosesser Administrere brukere og rettigheter Opprette og vedlikeholde tjenestekategorier Administrere profil, brukere og rettigheter Administrere sluttbrukersystemers integrasjon mot Altinn Følge opp sluttbrukerprosesser Registrere abonnements-informasjon Figur 4 - Brukerprosesser i Altinn Etablere og vedlikeholde tjenester i Altinn Definere, utvikle og vedlikeholde tjenester er en prosess som dekker utvikling og vedlikehold av alle tjenestetyper i tjenesteutviklingsløsningen. Prosessen består av stegene: opprette overordnet design for en tjeneste detaljering av design definisjon av tjenesten utvikling av tjenesten test (enhet, system, akseptanse) migrering Stegene er ikke bundet til hverandre i en fast prosess, som åpner for at tjenesteutviklere kan utføre stegene i den rekkefølgen som passer hver utvikler best. Noen steg vil naturlig følge etter 3 Figuren er basert på Figur 1, brukerprosesser i Altinn fra Tilbudsinnbydelsesdokument_vedlegg_1_Brukerprosesser_v2 0 Altinn II Side 10 / 54

11 andre steg i prosessen, eksempelvis vil man ikke kunne migrere en tjeneste før denne er utviklet. For detaljert beskrivelse av stegene i prosessen, se relaterte use case for tjenesteutviklingsløsningen. Publisere informasjon dekker prosesser knyttet til publisering i Informasjonsportalen. Administrere brukere og rettigheter omfatter etablering og vedlikehold av felles brukergruppe-, rolle- og rettighetsstrukturer så vel som rettighetsadministrasjon for den enkelte bruker av løsningen. Opprette og vedlikeholde tjenestekategorier omfatter etablering og vedlikehold av kategorier så vel som knytning av tjeneste mot kategorier. Hensikten er å tilby en struktur som gjør det enklere for sluttbruker å finne fram til ønsket tjeneste Benytte Altinn Finne og velge tjeneste dekker prosessene som lar sluttbruker finne fram til offentlige tjenester og velge å benytte tjenester i Altinn. Inngangen kan være via ulike portaler eller varsel på SMS eller e-post. Prosessene dekker løpet fram til at bruker er autentisert og autorisert, og står klar til å benytte valgt tjeneste. Benytte tjeneste i Altinn omfatter sluttbrukers bruk av de ulike tjenestetypene som er tilgjengelig gjennom Altinn. Dette omfatter bruk gjennom Altinn-portal så vel som sluttbrukersystem og lenketjenester som presenteres i andre portaler/nettsteder. Utveksle data med tjenesteeier dekker prosessene for utveksling av data mellom sluttbruker og den enkelte tjenesteeier. Finne tilbake til mottatt og innsendt informasjon dekker både sluttbrukers og tjenesteeiers behov for å finne informasjon om tidligere utførte tjenester. Administrere profil, brukere og rettigheter omfatter et sett med prosesser for å administrere profilvalg for den enkelte bruker, og for å administrere brukere og rettigheter innen virksomhetene. Administrere sluttbrukersystemers integrasjon mot Altinn lar bruker sette opp forbindelse mellom Altinn og sitt sluttbrukersystem ved å registrere informasjon i begge systemer. Følge opp sluttbrukerprosesser omfatter prosessene der ulike profesjonelle brukergrupper følger opp at kunder- og klientgrupper får utført tjenester i Altinn på korrekt måte og til rett tid. Registrere abonnementsinformasjon lar tjenesteeiere distribuere abonnementsinformasjon til Altinn for presentasjon for bruker, og etter hvert tilsvarende for sluttbrukere som ønsker påminnelser om rettigheter og plikter i Altinn. Altinn II Side 11 / 54

12 4.2 Etablere og vedlikeholde tjenester i Altinn Brukergrupper - tjenesteutvikling Det er ønskelig at tjenesteeiere skal kunne utføre betydelige deler av arbeidet knyttet til å etablere og vedlikeholde tjenester i Altinn. Samtidig er enkelte oppgaver kompliserte og krever til dels dyp teknisk kompetanse. De involverte brukerne kan derfor grupperes basert på kompetanse og arbeidsfordeling i tjenesteutviklingen. Nedenfor oppsummeres egenskaper og eksempler på arbeidsoppgaver for fem identifiserte brukergrupper knyttet til tjenesteutvikling. Hensikten er at alle som involveres i utforming av systemløsning og rutiner, skal ha et bevisst forhold til brukernes egenskaper og forutsetninger. (Inndelingen i brukergrupper representerer ikke en definisjon av roller og rettigheter i ferdig løsning.) Bruker og egenskaper Fagperson som forstår kommunikasjonsbehov knyttet til aktuelle offentlig tjenester basert på faglig kompetanse. Er opptatt av at tjenester skal være effektive og feilfrie; er nøyaktig og ønsker å levere god kvalitet. Har et fagområde utenom IKT; bruker IKTverktøy, men er ingen systemutvikler. Har fått grunnopplæring i TUL og evt. Infopath. Arbeider med tjenestedefinisjon og vedlikehold generelt, eller er spesialisert inn mot bestemte oppgaver. Enkelte har fått tilleggsopplæring i Sharepoint vinklet mot brukeradministrasjon og/eller tilpasning av samhandlingsområder i Sharepoint. Oversetter som har kompetanse på de aktuelle språkene. Typiske oppgaver - Opprette tjeneste/tjenesteutgave - Utarbeide design - Definere tjeneste inkludert evt. arbeidsflyt og skjemasett - Utvikle tjenesteinnhold inkludert layout, tekster, kalkyler og regler - Enhetsteste tjeneste - Starte migrering til portalmiljø - Systemteste/akseptanseteste tjeneste - Publisere informasjon om tjeneste - Vedlikeholde og migrere kodeliste - Administrere roller og rettigheter - Oversette tjeneste Er grundig og ønsker å bidra til enkel og forståelig kommunikasjon. Har fått grunnopplæring i TUL vinklet mot språkmodulen. Altinn II Side 12 / 54

13 Løsningsadmin IKT-person som har erfaring med systemutvikling. Behersker Visual Studio og Workflow Foundation. Har fått grunnopplæring i TUL. Teknisk utvikler med god forståelse av Altinn-løsningen. Har spesialisert kompetanse knyttet til verktøyene i Altinn. Enkelte har tilgang til å iverksette endringer i produksjonsmiljøet. For øvrig som IKT. Løsningsadministrator med god forståelse av Altinn-løsningen, spesielt TUL. Gir støtte til tjenesteeiere i tjenesteutviklingsarbeidet. Bruker IKT-verktøy, men er ingen systemutvikler. Har fått opplæring i Active Directory og i Sharepoint, vinklet mot brukeradministrasjon og/eller tilpasning av samhandlingsområder i Sharepoint. - Utarbeide arbeidsflytmal - Utarbeide komplekse regler/kontroller - Utvikle ny kjøretidskomponent, for eksempel arbeidsflytkomponent - Produksjonssette mal - Produksjonssette tjeneste - Opprette arbeidsområde og database for etat/ny tjenesteeier - Opprette nytt integrasjonspunkt mot etat - Administrere roller og rettigheter - Laste opp informasjon, for eksempel dokumentmaler, dokumenter og kunngjøringer Utvalgte bruksscenarioer - tjenesteutvikling Nedenfor beskrives utvalgte bruksscenarioer innenfor tjenesteutvikling. Bruksscenarioer bidrar til å bygge forståelse av brukerne, deres oppgaver og arbeidsomgivelser, noe som er viktig for å kunne utforme en løsning med høy brukskvalitet. Disse scenarioene er valgt ut fordi de representerer kjerneprosesser og/eller annen mye brukt funksjonalitet som er vesentlig for brukeropplevelsen i hovedsak ligger innenfor løsningsområder der brukergrensesnittet utvikles som del av Altinn-løsningen; det vil si at fagperson og oversetter er de sentrale brukerne Innledende designprosess En etat vurderer å tilby en ny tjeneste gjennom Altinn. To medarbeidere får i oppgave å utarbeide en kost-/nytteanalyse og konkretisere et forslag til utforming av tjenesten. Altinn II Side 13 / 54

14 En fagperson starter arbeidet ved å opprette tjenesten i tjenesteutviklingsløsningen og samler deretter relevant bakgrunnsinformasjon i arbeidsområdet. Den andre starter på et nytt dokument som skisserer et mulig informasjonsinnhold, og ber kollegaen om å ferdigstille dette Ny innsendingstjeneste (fra designdokument) En etat har startet arbeidet med en ny innsendingstjeneste. Utførlig designdokumentasjonen er utarbeidet. En medarbeider får i oppgave å definere og utvikle tjenesten, slik at den blir klar for enhetstest. En fagperson setter seg inn i eksisterende designdokumentasjon og oppretter den første utgaven av tjenesten. Fagpersonen gjennomfører deretter alle oppgaver knyttet til tjenestedefinisjon og - utvikling. Et Infopath-dokument fra design benyttes for utvikling av informasjonshåndtering Ny utgave av innsendingstjeneste (i produksjon) Etter at innsendingstjenesten er satt i produksjon skal det lages en ny utgave av tjenesten med noen endringer av utgavedefinisjonen fra en gitt dato. En medarbeider får i oppgave å endre utgavedefinisjonen fra den angitte datoen. En fagperson henter fram tjenesten, legger inn det mottatte notatet på arbeidsområdet, oppretter en ny utgave av tjenesten basert på den som allerede er i produksjon og justerer tjenestedefinisjonen. Deretter migreres utgaven til systemtest. I tillegg henter fagpersonen fram produksjonsversjonen av tjenesten og justerer sluttdato tilsvarende. Endringen migreres til produksjon Ny meldingstjeneste (fra mal) En etat har startet arbeidet med en ny meldingstjeneste. Det foreligger notater som beskriver ønsket tjenesteinnhold. En medarbeider får i oppgave å definere og utvikle tjenesten, slik at den blir klar for enhetstest. En fagperson setter seg inn i eksisterende bakgrunnsdokumentasjon og oppretter den første utgaven av tjenesten. Fagpersonen gjennomfører deretter alle oppgaver knyttet til tjenestedefinisjon og -utvikling. Det finnes en mal som gir et godt startpunkt for utvikling av tjenesteinnhold Ny meldingstjeneste (nytt forsøk) En etat utvikler en ny meldingstjeneste. Det foreligger ingen design. Etter en gjennomgang av foreliggende forslag, besluttes det at tjenesten skal vinkles helt annerledes. Nye føringer for innhold og funksjonalitet dokumenteres. En medarbeider får i oppgave å definere og utvikle tjenesten på nytt. En fagperson legger inn dokumentet med føringene på arbeidsområdet og oppretter en helt ny utgave av tjenesten. Fagpersonen gjennomfører deretter alle oppgaver knyttet til tjenestedefinisjon og -utvikling. Altinn II Side 14 / 54

15 Oversettelse En etat har en innsendingstjeneste på bokmål som er klar for systemtest, med unntak av at den skal oversettes til nynorsk og engelsk. En medarbeider får denne oppgaven. En oversetter benytter oversettingsverktøyet til å oversette tjenesten til nynorsk og engelsk. Deretter verifiseres at informasjonsinnholdet fungerer i alle språkversjonene Opphør av tjeneste En etat tilbyr en tjeneste i Altinn som skal erstattes av en ny og bedre tjeneste. Begge tjenester har vært tilgjengelig i produksjon en periode, men nå skal den eldste tjenesten opphøre. En medarbeider får i oppgave å slette den gamle tjenesten for godt. En fagperson henter fram tjenesten og deaktiverer den. Dette medfører stenging i produksjon. 4.3 Benytte Altinn Brukergrupper - sluttbrukerløsning Altinn er i prinsippet tilgjengelig for alle borgere, og de kan velge å benytte ulike deler av Altinn på ulike måter. Brukerne kan grupperes langs flere dimensjoner, som demografi, PC/internetterfaring, bruksfrekvens eller fagområde. Her har vi valgt ut et håndterbart antall sluttbrukergrupper med utgangspunkt i hvem de representerer ved bruk av Altinn: Seg selv eller sin egen virksomhet - to grupper basert på erfaringsnivå Virksomheten de er involvert i - tre grupper basert på ansvarsområde Andre sluttbrukere Etat/enhet i Altinn-samarbeidet. Nedenfor oppsummeres egenskaper og eksempler på arbeidsoppgaver for disse sju representative sluttbrukergruppene. Hensikten er at alle som involveres i utforming av systemløsning og rutiner, skal ha et bevisst forhold til brukernes egenskaper og forutsetninger. Altinn II Side 15 / 54

16 Sporadisk bruker E-borger Virksomhets-leder Bruker og egenskaper Person som representerer seg selv som privatperson, eller sin egen virksomhet (for eksempel et enkeltpersonforetak). Bruker PC jevnlig til for eksempel nettbank og informasjonssøk. Har begrenset erfaring med Altinn. Bruker løsningen sporadisk og husker ikke nødvendigvis menyvalg, funksjonalitet og informasjonsinnhold fra gang til gang. Er usikker og opptatt av å ha kontroll og forstå hva som skjer; har det ikke spesielt travelt ved bruk av Altinn. Foretrekker å ha papirkopier av viktige dokumenter og kvitteringer. Person som representerer seg selv som privatperson, eller sin egen virksomhet. Bruker PC jevnlig til det meste, inklusive offentlige og private tjenester på nett. Er erfaren Altinn-bruker og nysgjerrig på å ta i bruk ny funksjonalitet. Er opptatt av effektivitet, oversikt og få tastetrykk. Arkiverer alt elektronisk og er fornøyd med å slippe papirer og brev. Leder som representerer en virksomhet (næringsliv, kommune, organisasjon, ). Bruker PC og Internett jevnlig, men bruker Altinn kun sporadisk. Føler ansvar for at virksomheten skal overholde regler og innrapportere effektivt, men involverer seg ikke i konkrete detaljer. Har generelt liten tid og interesse for å lære IKT- Overordnet spesifikasjon.doc Typiske oppgaver - Finne fram til tilgjengelige tjenester og informasjon om disse - Finne fram til mottatte meldinger og tjenester/skjemaer under arbeid - Benytte tjeneste o i Altinn-portalen, evt. via lenke fra annen portal - Finne fram til tilgjengelige tjenester og informasjon om disse - Finne fram til mottatte meldinger og tjenester/skjemaer under arbeid - Benytte tjeneste o i Altinn-portalen, evt. via lenke fra annen portal o via sluttbrukersystem - Finne fram til arkivert informasjon - Tilpasse brukerprofil - Delegere rettigheter i Altinn - Finne fram til arkivert informasjon Altinn II Side 16 / 54

17 Medarbeider Avdelingsleder Sluttbrukerrepresentant løsninger. Avdelingsleder/områdeansvarlig i en virksomhet. Kan være identisk med virksomhetslederen. Er vant med PC og Altinn som arbeidsverktøy i jobbsammenheng, men regnes ikke som noen ekspert. Ha ansvar for rapportering innen sitt område. Kan overlate mye til sine medarbeidere, eller selv utføre oppgaver for eksempel knyttet til skjemautfylling. Er opptatt av å ha oversikt og kontroll over kommunikasjon med det offentlige. Bruker ikke tid på å lære seg IKT-løsninger som Altinn utover det som trengs for å løse nødvendige oppgaver. Medarbeider i en virksomhet. Er vant med PC og Altinn som arbeidsverktøy i jobbsammenheng, men regnes ikke som noen ekspert. Får tildelt spesifikke oppgaver innen et område som for eksempel regnskap eller personal, men har ikke rett til å rapportere på vegne av virksomheten. Aksepterer behov for nøyaktig og detaljert informasjon, men vil unngå tungvinte løsninger og opplevd dobbeltarbeid. Lærer seg det som er nødvendig for å løse konkrete oppgaver, men er ikke interessert i Altinn generelt. Ansvarlig for eller ansatt i en virksomhet som representerer andre sluttbrukere mht. innrapportering til det offentlige for eksempel regnskapsfører eller revisor. Bruker PC og Altinn aktivt som arbeidsverktøy og er fortrolig med funksjonaliteten. Overordnet spesifikasjon.doc - Delegere rettigheter i Altinn - Benytte tjeneste (inkl. signering og innsending) o i Altinn-portalen o via sluttbrukersystem - Finne fram til mottatte meldinger og tjenester/skjemaer under arbeid; sitt eget og andres arbeid - Finne fram til arkivert informasjon - Benytte tjeneste (utfylling) o i Altinn-portalen o via sluttbrukersystem o fra annet nettsted (v2) - Finne fram til virksomhetens tjenester/skjemaer som han arbeider med - Finne fram til arkivert informasjon - Følge opp sluttbrukerprosesser, dvs. tjenester som benyttes av andre virksomheter - Finne fram til mottatte meldinger og tjenester/skjemaer under arbeid; sitt eget og andres Altinn II Side 17 / 54

18 Etatsbruker Veileder også andre sluttbrukere i å håndtere informasjon i Altinn. Er opptatt av oversikt, kontroll og en effektiv arbeidssituasjon. Medarbeider i etat/enhet som deltar i Altinnsamarbeidet. Har oppgaver knyttet til drift eller oppfølging av tjenester som tilbys gjennom Altinn. Er opptatt av at tjenester skal være effektive og feilfrie; er nøyaktig og ønsker å levere god kvalitet. Har fått opplæring i Altinn og evt. andre løsninger som benyttes i arbeidet. Overordnet spesifikasjon.doc arbeid - Starte og benytte tjeneste (inkl. signering og innsending) o i Altinn-portalen o via sluttbrukersystem - Finne fram til arkivert informasjon - Delegere rettighet til å representere andre sluttbrukere - Finne mottatt og sendt informasjon i servicearkiv eller i tredjepartsarkiv I tillegg vil følgende grupper forholde seg til sluttbrukerløsningen: Brukerstøtte vil veilede sluttbrukere gjennom portalsidene og dessuten kunne gjøre oppslag i service- eller tredjepartsarkiv. IKT- og fagpersoner personer hos etat vil registrere meldinger, abonnement og preutfyllingsdata via sine etatssystemer. Utviklere av sluttbrukersystemer vil benytte tjenester fra Altinn i utvikling av sluttbrukersystemer Utvalgte bruksscenarioer - sluttbrukerløsning Nedenfor beskrives utvalgte bruksscenarioer innenfor sluttbrukerløsningen. Bruksscenarioer bidrar til å bygge forståelse av brukerne, deres oppgaver og arbeidsomgivelser, noe som er viktig for å kunne utforme en løsning med høy brukskvalitet. Disse scenarioene er valgt ut fordi de representerer kjerneprosesser og/eller annen mye brukt funksjonalitet som er vesentlig for brukeropplevelsen Enkel innsending En illustratør bruker Altinn bare for innsending av MVA-oppgave, og nå nærmer fristen seg igjen. Altinn II Side 18 / 54

19 Den sporadiske brukeren logger inn i Altinn og finner fram til MVA-oppgaven som er lagt ut for virksomheten gjennom abonnement. Han fyller ut og sender inn og passer på å ta vare på kvittering og papirkopi Sammensatt bruk En IT-konsulent mottar varsel om at melding er mottatt i Altinn. Meldingen medfører at han må benytte en innsendingstjeneste. Samtidig tester han ut funksjonalitet han finner på veien. E-borgeren går inn i Altinn, kvitterer ut meldingen og forstår at han trenger å benytte innsendingstjenesten. Han leter fram aktuelle tjenester og legger merke til en lenketjeneste som ser spennende ut, og prøver denne. Etterpå finner han innsendingstjenesten, fyller ut og sender inn. Til slutt sjekker han hva som ligger elektronisk arkivert Altinn via annen portal IT-konsulenten skal flytte og går inn på postens nettsider for å ordne det som skal til. På postens sider finner e-borgeren lenke til flyttemelding. Han fyller ut og sender inn meldingen. Så finner han en ny innsynstjeneste som viser registrerte persondata, men ser at endringen ikke er registrert. Han leter fram informasjon om flyttemeldingen for å finne ut hvor lang tid det vil ta Ny virksomhet i Altinn En ny, større virksomhet skal ta i bruk Altinn for offentlig rapportering. Virksomhetslederen logger inn i Altinn for første gang og setter opp passord og andre innstillinger. Deretter delegeres rettigheter til avdelingsledere og medarbeidere Med sluttbrukersystem En medarbeider har ferdigstilt utfylling av selvangivelsen i sluttbrukersystemet og vil gjøre alt klart slik at lederen kan signere og sende inn i Altinn. Medarbeideren overfører selvangivelsen til Altinn og åpner den for å sjekke om alt er blitt riktig. Han retter en utfyllingsfeil i sluttbrukersystemet og overfører på nytt. Til slutt rydder han opp slik at bare siste versjon ligger tilgjengelig i Altinn Kontroll og innsending En avdelingsleder får beskjed om at selvangivelsen for næringsdrivende er ferdig utfylt, og vil kontrollere og sende inn denne. Avdelingslederen finner og åpner selvangivelsen. Han sjekker noen beløp i fjorårets selvangivelse og konkluderer med at utfyllingen er rett. Deretter signerer han og sender inn selvangivelsen Hos revisoren Det nærmer seg frist for innlevering av selvangivelse, og en revisor vil finne ut hvordan han ligger an. Altinn II Side 19 / 54

20 Revisoren sjekker hvilke av hans klienter som har selvangivelsen klar til signering nå, og hvilke som fortsatt mangler. Deretter søker han fram en oversikt over alle selvangivelsene han har sendt inn i år Hos regnskapsføreren En medarbeider har akkurat blitt langtidssykemeldt da en av klientene henvender seg med et spørsmål om MVA-oppgaven som skulle vært levert. Lederen gir en ny medarbeider ansvar for å følge opp klienten umiddelbart. Lederen tildeler klienten til sin nye medarbeider. Medarbeideren henter fram oversikt over innsendte MVA-oppgaver, men finner ingen innslag for denne klienten. Medarbeideren går videre inn på klienten for å oppdatere seg på status før klienten kontaktes Forespørsel etat En virksomhet har fått brev fra statens innkrevingssentral om forsinkelsesgebyr pga manglende innlevering av årsregnskap. Økonomisjefen kontakter Brønnøysundregistrene og forklarer at regnskapet skal ha blitt sendt inn i Altinn og skulle vært registrert. Etatsbruker går inn i servicearkivet og søker frem alle årsregnskap som virksomheten har levert. Altinn II Side 20 / 54

21 5 Overordnede krav, føringer og løsningsprinsipper 5.1 Teknisk løsning/arkitektur Design av arkitektur i Altinn styres av 10 overordnete arkitekturprinsipper, som kan tolkes som suksesskriterier for løsningen. Nedenfor gjengis prinsippene og hvordan de er tenkt ivaretatt i løsningen Prinsipp 1 Altinn skal etableres ved gjenbruk av eksisterende komponenter i kombinasjon med nye komponenter. Der det finnes komponenter i offentlig sektor som tilfredsstiller behov i Altinn, skal disse tas i bruk. Hele løsningsforslaget er basert på SOA-prinsipper og dermed løs kopling mellom de ulike komponentene som utgjør løsningen. Løsningen vil gjenbruke så mye som relevant/mulig fra nåværende Altinn, men uten å bryte prinsippet om tjenesteorientering og løs kobling. Innføring av en tjenestebuss som benytter åpne standarder, har også vært et viktig prinsipp for løsningen. Gjennom bruk av denne typen teknologi vil det være svært enkelt å utvide Altinn til å omfatte komponenter som utvikles hos ulike tjenesteeiere. Altinn vil gjenbruke standard offentlige sikkerhetsløsninger som MinID. Altinn vil selv kunne inngå i andre offentlige løsninger og fylle rollen som et offentlig samhandlingsnav Prinsipp 2 Der det er hensiktsmessig skal det benyttes standardløsninger fremfor egenutvikling. Løsningen for Altinn vil i stor grad benytte standardløsninger. Altinn vil være bygd på Sharepoint som samhandlingsplattform, Infopath for skjemautvikling, og Workflow Foundation for arbeidsflyt. Kjernen i sikkerhetsløsningen vil benytte Sun Federated Access Manager Prinsipp 3 Altinn skal være lagdelt og bygges av tjenesteorienterte komponenter med definerte grensesnitt. Løsningen vil være lagdelt og tjenesteorientert. De ulike lagene i systemet (presentasjons-, forretnings- og datalag) er implementert med løs kobling og med veldefinerte grensesnitt koblet til tjenestebussen. Løsningsarkitekturen vil bestå av fysiske, selvstendige komponenter. En komponent har sin egen datamodell og snakker med andre komponenter gjennom veldefinerte tjenestegrensesnitt på tjenestebussen Prinsipp 4 I Altinn skal grensesnitt mellom komponenter baseres på åpne standarder. Komponenter i Altinn skal baseres på åpne standarder der slike finnes. Komponentene snakker med andre komponenter og systemer gjennom grensesnitt basert på åpne standarder. Tjenestebussen eksponerer tjenester som web-services, men kan også tilby tjenester via en binærprotokoll hvis ytelseshensyn krever det. Autentisering er skilt ut i en egen Altinn II Side 21 / 54

22 komponent som kommuniserer med resten av løsningen ved hjelp av SAML-protokollen, som også benyttes av MinSide/MinID Prinsipp 5 Altinn sitt brukergrensesnitt skal være Web-basert og støtte alle typer brukere uten ekstrainnsats fra brukeren. Sluttbrukerløsningen er fullstendig web-basert. Det kreves ingen ekstra installasjon hos brukeren for å benytte Altinn. Løsningen følger Elmer-retningslinjene for innsendingstjenester. Tjenesteutviklingsløsningen er i hovedsak web-basert gjennom Sharepoint. Infopath er en rik klient som installeres i utviklingsmiljøet til en tjenesteutvikler og tilbys gjennom en Citrixløsning slik at det ikke er behov for installasjon lokalt på en tjenesteutviklers arbeidsstasjon Prinsipp 6 Altinn skal tilrettelegge for samordning og gjenbruk av offentlige grunndata der lover og regler muliggjør det. Løsningen gjenbruker offentlige grunndata (metadata, enhetsregisteret, med mer) Prinsipp 7 Altinn skal bygges på en slik måte at det er mulig å oppnå 24/7-tilgjengelighet. Det er ingen komponenter i løsningen som har behov for fast nedetid/vedlikehold offline. Både software- og hardwaremessig har det vært sterkt fokus på implementering av redundans i alle ledd og høy grad av oppetid, på samme måte som det ble ivaretatt i eksisterende Altinn. I tillegg er det mulighet for både vertikal og horisontal skalering av de ulike komponentene i løsningen Prinsipp 8 Altinn skal bygges på en slik måte at behovet for effektivt vedlikehold av tjenestene ivaretas. Tjenesteutviklingsløsningen som består av høyereordens design- og utviklingsverktøy som Sharepoint, Infopath og Workflow Designer gjør at design og utvikling utføres i samme verktøy uavhengig om man definerer metadata, tegner arbeidsflyt eller utvikler nye skjema. Dette gjør det mulig for brukere i store og små etater å utvikle tjenester i tjenesteutviklingsløsningen uten at de trenger å ha dyp IKT-kompetanse. Tjenester kan utvikles av mange brukere i parallell, uavhengig av hverandre, men med konfigurasjonskontroll. Migrering av tjenester til test og produksjon gjøres fra tjenesteutviklingsløsningen Prinsipp 9 Brukeres tilgang til Altinn skal baseres på tjenestelige behov. Tilgangskontrollen i Altinn vil være rollebasert. Roller tildeles bruker etter tjenestelige behov. Løsningen vil i større grad enn tidligere benytte standardverktøy for tilgangskontroll. Det gjelder både tjenesteutviklingsløsningen og sluttbrukerløsningen. Tilgangsrettigheter kan endres dynamisk av tjenesteeier. Altinn II Side 22 / 54

23 Prinsipp 10 Altinn skal bygges for å kunne håndtere sensitive opplysninger. Sikkerhet og spesielt muligheten til å ta imot, behandle og videreformidle sensitive opplysninger er i sterkt fokus i løsningen. Sikkerhetsarkitekturen tilfredsstiller grunnleggende krav til informasjonssikkerhet som går på autentisitet, konfidensialitet, integritet og tilgjengelighet for tjenester og data, ansvarlighet for brukerne og tillit til at disse kravene møtes på et tilfredsstillende måte. Dette støtter opp under sikkerhet på systemnivå i form av at man får en sikker plattform, sikker drift og vedlikehold, og sikker hendelseshåndtering og gjenoppretting. 5.2 Funksjonelt/Brukskvalitet God brukskvalitet bidrar til å oppnå visjonen om Altinn som nøkkelen til eforvaltning i verdensklasse. I tillegg til funksjonelle krav stilles derfor mange generelle og spesifikke krav om at løsningen skal oppleves som brukervennlig når man utvikler og benytter tjenester i Altinn. Brukskvaliteten bestemmes av i hvilken grad de enkelte brukergruppene opplever Altinn som et effektivt og tilfredsstillende verktøy i forhold til sine oppgaver og mål. Brukerens opplevelse påvirkes av hvilken funksjonalitet som tilbys, så vel som av hvordan brukergrensesnittet er utformet. I dette kapitlet konkretiseres suksesskriterier og løsningsprinsipper innenfor brukskvalitet. Hensikten er først og fremst å sette fokus på avgjørende brukerbehov i løsningsutformingen, men også å konkretisere hvilke egenskaper som vil bli verifisert senere i utviklingsløpet Suksesskriterier Med utgangspunkt i krav og føringer innen brukskvalitet kan vi identifisere et sett med suksesskriterier for Altinnløsningen. Disse listes nedenfor Nyttig rett funksjonalitet og innhold Fagpersoner hos tjenesteeiere kan utvikle og vedlikeholde tjenester uten særlig involvering av IKT- og teknisk personell uten merarbeid om tjenesten skal tilbys i sluttbrukersystem eller portal eller begge deler. Tjenesteutviklingsløsningen synliggjør tjenestedefinisjon og tjenesteinnhold, slik at feil og mangler kan oppdages og rettes tidlig. Altinn gir god oversikt over tilgjengelige tjenester - i produksjon for sluttbrukere, i produksjon og under utvikling for system- og tjenesteeiere. Altinn tilrettelegger for utvikling og utfylling av skjemaer som bygger på ELMERretningslinjene. Med dette opplever sluttbruker støtte i utfyllingsprosessen og gjenkjennelse fra andre skjema og løsninger. Altinn tilrettelegger for at sluttbrukersystemer kan tilby sine brukere å benytte Altinntjenester gjennom sitt brukergrensesnitt. Gode feilmeldinger gir grunnlag for en meningsfull brukerdialog. Altinn gir avhengig av tjenesteomfang - sluttbruker mulighet for å utføre og samle sin kommunikasjon med det offentlige på ett sted, inkludert historikk. Altinn II Side 23 / 54

24 Effektiv tilpasset bruker og oppgave Overordnet spesifikasjon.doc Fagpersoner kan komme i gang med tjenesteutvikling etter grunnopplæring i løsningen, uten tekniske forkunnskaper. Brukergrensesnittet oppfattes som enkelt og intuitivt for begynnere, samtidig som løsningen er effektiv for erfarne tjenesteutviklere. Tjenesteutviklingsløsningen gir fortløpende støtte til utviklingsprosessen avhengig av tjenestetype og hvor i prosessen brukeren befinner seg. Sluttbrukersystemutvikler har tilgang på informasjon og tjenester som understøtter integrasjon av Altinn-tjenester i andre systemer. Sluttbruker logger inn, finner fram til og benytter tjenester uten opplæring, og bruker tilgjengelig støtteinformasjon som hjelp til å komme videre ved behov. Altinn tilrettelegger for samhandling innen utvikling og bruk av tjenester. Altinn gir tilgang til funksjonalitet og innhold avhengig av brukerens rolle/rettigheter. Brukeren kjenner igjen begreper og konsepter fra hverdagen slik at Altinn oppleves forståelig og logisk oppbygd. Brukeren har oversikt og kontroll og forstår hvor er jeg, hva kan jeg gjøre, og hvor kan jeg gå videre/tilbake? Tilfredsstillende behagelig i bruk, for alle Sluttbruker opplever at Altinn representerer tjenesteeierne og kommuniserer profesjonelt, forståelig og effektivt. De får derved tillit til løsningen og bruker den igjen. Tjenesteeiere oppfatter at Altinn representerer dem og formidler deres tjenester på en tilfredsstillende måte. Altinn dekker krav til universell utforming og kan brukes av alle, også synshemmede Ønskede systemegenskaper I de følgende avsnittene defineres løsningsprinsipper for henholdsvis tjenesteutviklingsløsningen og sluttbrukerløsningen. Vi tar utgangspunkt i ønskede egenskaper som kjennetegner ethvert brukervennlig produkt: Intuitiv lett å ta i bruk Strukturert lar brukeren ta kontroll Støttende hjelper brukeren på rett vei Enkel fremhever hovedveiene Effektiv minimaliserer arbeidsmengden Tilgjengelig favner hele brukergruppen Tiltrekkende oppnår brukerens tillit og engasjement Nedenfor beskrives mekanismer og virkemidler som understøtter disse egenskapene, gitt suksesskriterier, brukergrupper og oppgaver i Altinn. Storyboards og skisser i detaljert funksjonell spesifikasjon er utarbeidet basert på bl.a. disse prinsippene. Begrepene som er brukt her samsvarer med de som ble definert i avtalens Bilag 5 Testing og godkjenning. Altinn II Side 24 / 54

25 5.2.3 Løsningsprinsipper tjenesteutvikling Intuitiv, strukturert og støttende Fokus: Senke opplæringsterskelen og sikre forståelighet av løsningen. Løsningen skal inneholde et hjelpepanel som gir en kort oversikt over tjenesteutviklingsprosessen og relevante maler. Løsningen skal bygges opp slik at bruker kjenner igjen oppgaver og begreper fra tjenesteutviklingsprosessen: Design, konfigurering av metadata, utvikling av innhold osv. Menyvalg og annen navigasjon skal være tydelig og konsistent. Verktøy/hovedvalg som brukeren ikke har rettighet til, skal skjules, med mindre visning av disse og feilmelding ved forsøk på aktivering er hensiktsmessig for å forstå løsning eller prosess. Det skal være en arbeidsflate pr. utgave av tjeneste der det er synlig hva som er fylt ut, hva som mangler og hvor langt man er kommet i utviklingsprosessen. Arbeidsflaten skal være tilpasset den aktuelle tjenestetypen, slik at brukerens valg begrenses til de som er relevante. Innenfor tjenestekonfigurering skal informasjon samles i logiske grupper som brukeren kan kjenne igjen på tvers av tjenestetyper. Brukeren skal i størst mulig grad velge mellom alternativer og/eller fra lister, slik at det ikke blir nødvendig å huske/skrive inn kommandoer, navn på maler osv Enkel og effektiv Fokus: Sikre effektivitet i bruk og tilfredsstillende feiltoleranse. Det skal være en arbeidsflate pr. etat/tjenesteeier der det er mulig å liste og åpne dennes tjenester, eller opprette nye tjenester. Det skal være enkelt å liste henholdsvis tjenester i produksjon og tjenester under utvikling. I arbeidsflaten skal tjenesteeieren kunne laste opp dokumenter for informasjon og gjenbruk mellom tjenester; dette dekkes av Sharepoint standardfunksjonalitet. Flere skal kunne samarbeide om en tjeneste ved at dokumentasjon utarbeides i kontorstøtteverktøy som har mulighet for kommentarer og sporing av endringer, og ved at Sharepoint har standardfunksjonalitet for å legge inn for eksempel diskusjoner og kunngjøringer i arbeidsflaten. Dessuten brukes Sharepoints standardfunksjonalitet for å abonnere på varsel om endringer, og for versjonshåndtering der endringer kan lagres som separate versjoner med beskrivelse av hva som er endret. Kjernefunksjonalitet skal fremheves og prioriteres på bekostning av mindre brukt funksjonalitet, slik at brukeren i vanlige utviklingsløp forholder seg til tydelige valg og får færrest mulig navigeringssteg. Ved utvikling av en tjenesteutgave skal brukeren så langt det er praktisk kunne velge rekkefølge på konfigurering og innholdsutvikling, og på oppgaver innenfor hver av disse. Alle verktøy som trengs for å konfigurere og utvikle en tjeneste, skal være tilgjengelig fra tjeneste- eller utgavearbeidsflaten. Ulike brukere kan jobbe på separate deler av tjenesten samtidig. For eksempel kan man arbeide med skjemasett, arbeidsflyt og oversettelse i parallell. Altinn II Side 25 / 54

26 Så langt som praktisk mulig skal det lages konfigurerbare maler for ulike tjenesteegenskaper. Det skal lages brukergrensesnitt for utfylling av parametere, slik at konfigureringen ikke krever IKT-bakgrunn. Spesielt skal det tilrettelegges for konfigurering av hvordan et skjema skal fylles ut i henhold til ELMER-retningslinjene, med sporvalg etc., slik at dette blir den naturlige fremgangsmåten for utvikling av innhold i innsendingstjenester. Det skal være mulig å kopiere Infopath-dokumenter fra design over til utvikling av tjenesteinnhold slik at informasjon om layout og innhold kan gjenbrukes. Det skal være tydelig for brukeren om det gjøres endringer på en tjeneste som allerede er migrert til portalmiljø. Spesielt skal det ikke være mulig å slette en tjenesteutgave samtidig som den blir værende i produksjon. Der det kan være vanskelig å forstå hvorfor en funksjon ikke er tilgjengelig, skal valget være aktivt og brukeren få en forklarende melding hvis valget benyttes. Generelt skal feilmeldinger forklare hva som skal til for å komme videre Tilgjengelig og tiltrekkende Fokus: Sikre universell utforming og brukerens tillit. Løsningen bygges opp av standardverktøy som følger retningslinjene for universell utforming og kan brukes av alle, samt egenutviklede deler som følger tilsvarende retningslinjer. Det legges vekt på å bygge inn prinsipper som alle brukergrupper har fordel av, spesielt en klar og konsistent struktur, enkelt språk, logisk gruppering av innhold med tydelige overskrifter og gode kontraster. Løsningen skal oppleves som responderende, det vil si at brukere skal ikke måtte vente lenge på at nettleservinduet oppdateres når en operasjon utføres. Det legges opp til å benytte asynkrone måter å oppdatere deler av en side der det kan gi en bedre brukeropplevelse Løsningsprinsipper sluttbrukerløsning Intuitiv, strukturert og støttende Fokus: Senke terskelen for å komme i gang og sikre forståelighet av løsningen. Menyvalg og annen navigasjon skal være tydelig og konsistent. Verktøy/hovedvalg som brukeren ikke har rettighet til, skal skjules. Hovedmenyen skal være tilgjengelig og oppleves uendret når brukeren henter fram informasjon om en tjeneste, og når brukeren henter fram tjenester. Brukeren skal i størst mulig grad velge mellom alternativer og/eller fra lister, slik at det ikke blir nødvendig å huske/skrive inn kommandoer, navn på tjenester osv. Løsningen skal gi tilgang til støtteinformasjon/hjelp avhengig av den kontekst brukeren er i. Der det er hensiktsmessig skal støtteinformasjon vises i eget nettleservindu. Der en antar at flertallet av brukere vil trenge støtte, skal korte instruksjoner skrives direkte i skjermbildet. Altinn II Side 26 / 54

27 For prosesser som går over flere steg, skal brukeren ledes gjennom disse ved veiviserliknende sider der unødvendige valg ikke er tilgjengelig. Hver side skal tydelig formidle hva bruker holder på med, for eksempel hvem brukeren rapporterer for og hvilken tjeneste som benyttes. Standardinnstillinger og parametere skal settes ut i fra behovet for nye og sporadiske brukere. Mer erfarne brukere forutsettes å utnytte muligheter for å tilpasse sideinnhold ved behov. Innsendingstjenester skal i all hovedsak presenteres ved format og funksjonalitet som følger ELMER 2-retningslinjene. Designvalg i løsningen for øvrig skal følge prinsippene fra ELMER 2-retningslinjene der dette er relevant og hensiktsmessig for å gi en konsistent brukeropplevelse Enkel og effektiv Fokus: Sikre effektivitet i bruk og tilfredsstillende feiltoleranse. Kjernefunksjonalitet skal fremheves og prioriteres på bekostning av mindre brukt funksjonalitet, slik at brukeren i vanlige bruksløp forholder seg til tydelige valg og får færrest mulig navigeringssteg. Der det kan være vanskelig å forstå hvorfor en funksjon ikke er tilgjengelig, skal valget være aktivt og brukeren få en forklarende melding hvis valget benyttes. Generelt skal feilmeldinger forklare hva som skal til for å komme videre. Det gis mulighet for å tilpasse sin egen arbeidsflate gjennom å definere brukerprofil. Enkelte brukervalg vil løsningen huske fra sesjon til sesjon. Løsningen skal vise tilstrekkelig informasjon om listeelementer til at brukeren kan avgjøre hvilket element som skal åpnes. Listeinnholdet skal begrenses når siden åpnes. Brukere som trenger større informasjonsmengder skal gis mulighet for å hente fram dette i etterkant. Når brukeren er i en prosessflyt som for eksempel skjemautfylling og trenger tilleggsinformasjon, skal separate nettleservinduer åpnes for dette. Skjermbredden skal i utgangspunktet være dynamisk (men må vurderes i forhold til Informasjonsportal og Altinn 1), og det skal normalt ikke forekomme horisontal scrolling. Vertikal scrolling er akseptabelt. Løsningen skal gi eksisterende brukere gjenkjennelse i forhold til eksisterende versjon, samtidig som man tilrettelegger for innføring av Meldingsboks i neste versjon Tilgjengelig og tiltrekkende Fokus: Sikre universell utforming og brukerens tillit. Løsningen utvikles i henhold til retningslinjene for universell utforming. Det legges vekt på å bygge inn prinsipper som alle brukergrupper har fordel av, spesielt en klar og konsistent struktur, enkelt språk, logisk gruppering av innhold med tydelige overskrifter og gode kontraster. Løsningen skal oppleves som responderende, det vil si at brukere skal ikke måtte vente lenge på at nettleservinduet oppdateres når en operasjon utføres. Det legges opp til å Altinn II Side 27 / 54

28 benytte asynkrone måter å oppdatere deler av en side der det kan gi en bedre brukeropplevelse. Løsningen skal henvende seg til brukeren på et forståelig språk og tydelig signalisere hvem som er avsender og mottaker av informasjon. Altinn II Side 28 / 54

29 6 Overordnet beskrivelse av tjenesteutviklingsløsningen Tjenesteutviklingsløsningen er en samling av verktøy som tilgjengeliggjøres for tjenesteutviklere på en felles arbeidsflate. Alle verktøy som en tjenesteutvikler behøver for å utvikle tjenester for Altinn finnes her. Detaljspesifikasjonen for tjenesteutviklingsløsningen består av forskjellige funksjonelle områder som igjen er brutt ned i Use Case. De forskjellige funksjonelle områdene listes under med en kort beskrivelse av hvert område samt en liste over de Use Case som dekker funksjonaliteten. De forskjellige Use Case er beskrevet i Detaljert funksjonell spesifikasjon. Navigasjon og sideinndeling er beskrevet i Site Map og Storyboards. Eksempler på disse er gjengitt i dette kapittelet, mens den fullstendige spesifikasjonen av Navigasjon og sideflyt ligger i Detaljert funksjonell spesifikasjon. 6.1 Prosess for tjenesteutvikling Prosessmodellen for Tjenesteutviklingsløsningen bygger på tjenesteutviklingsprosessen gitt i kravspesifikasjonen, gjengitt under i Figur 5. 1 a. Opprette overordnet design for tjeneste 2. Definere tjeneste 1 b. Opprette detaljert design for tjeneste 3. Utvikle tjeneste 4. Enhetsteste tjeneste 5. Migrere tjeneste til portalmiljø Figur 5 Prosess for tjenesteutvikling 6. Systemteste tjeneste 7. Akseptanseteste tjeneste 8. Produksjonsette tjeneste Prosessmodellen for Tjenesteutviklingsløsningen vises i Figur 6 under, og inneholder følgende steg: Design tjeneste: Kan gjøres i Tjenesteutviklingsløsningen, men også i egne dokument i forkant av opprettelse av tjeneste Opprett tjeneste: Opprettelse av tjeneste. Man får da tilgang til arbeidsflaten, dokumentbibliotek, tjenestedefinering og tjenesteutvikling (skjemautvikling) Definer tjeneste: Konfigurering av tjeneste, ved parametersetting Utvikle tjeneste: Utvikling av skjema, samt o Utvikle språkutgave (endre layout etc) o Oversett tjeneste o Utvikle og migrer kodeliste o Utvikle og migrer arbeidsflytmal- og komponenter Enhetstest tjeneste: Enhetstesting av skjema og kodegjennomgang. Utføres i forkant av Systemtest, men kan også utføres iterativt i utviklingsprosessen Altinn II Side 29 / 54

30 Systemtest tjeneste: Test av tjeneste i Sluttbrukerløsningen og Sluttbrukersystemer Akseptansetest tjeneste: Test av tjeneste i Sluttbrukerløsningen og Sluttbrukersystemer Produksjonssett tjeneste: Migrering til sluttbrukerløsningen Publisering av tjeneste: Publisering på InfoPortalen Figur 6 illustrerer hvordan prosesstegene normalt plasseres ut i tid ved utvikling av en tjeneste. Prosessene vises som piler bortover den horisontale tidslinjen. Tidslinjen gjengir i hvilket tidsrom prosess-stegene normalt uføres. Vertikalt vises rekkefølgen på prosess-stegene. Samlet viser dette da at for eksempel Definer tjeneste og Utvikle tjeneste kan gå i parallell, men at det prosessmessig er normalt å starte med å definere tjenesten i forkant av utvikling. De vertikale pilene viser overgangen fra et prosess-steg til et annet. Markering med A og M viser om overgangen er automatisk (støttet av Tjenesteutviklingsløsningen) eller om det er manuelle steg som må gjøres. Altinn II Side 30 / 54

31 Design tjeneste (Valgfritt verktøy/infopath) A Opprett tjeneste (SharePoint) A A Definer tjeneste (metadata, arbeidsflytkonfigurering, skjemasettkonfigurering (SharePoint) A M1 Utvikle og migrer arbeidsflytmal og komponenter (Visual Studio/WWF/SharePoint) Utvikle tjeneste (InfoPath/Visual Studio) A PROSESS A M2 Utvikle og migrer kodeliste (SharePoint) A A O Utvikle språkutgave (InfoPath) Oversett tjeneste (SharePoint/InfoPath) A Enhetstest tjeneste (InfoPath) A Publisering av tjeneste (EpiServer) Systemtest/Akseptansetest tjeneste (Sluttbrukerløsningen) M3 Produksjonssett tjeneste (SharePoint) M4 A: Automatisk grensesnitt fra et prosess-steg til et annet M1: Manuell bestilling av ny arbeidsflytmal- og komponenter. Arbeidsflytmalen og -komponentene utvikles, testes, kvalitetssikres (manuelt) og migreres til Sluttbrukerløsningen (manuelt). Arbeidsflytmalen tilgjengeliggjøres (manuell prosess) for bruk i utvikling av tjeneste. M2: Manuell bestilling av ny kodeliste. Kodelisten utvikles, testes og migreres (automatisk) til Sluttbrukerløsningen. Kodelisten er da klar til å brukes under utvikling av tjeneste M3: Ved migrering til produksjon er det et manuelt steg ved faktisk migrering til produksjon. Pakking og teknisk test av tjenesten er automatisk M4: Etter produksjonssetting må dyplenke til tjenesten legges inn i InfoPortalen O: Oversette tjeneste og Utvikle språkutgave kan gjøres i parallell, men da for forskjellige språk TID Figur 6 Sekvens for tjenesteutvikling, parallellitet og samspill mellom prosess-steg De forskjellige prosessene kan i stor grad utføres i parallell gjennom utviklingsperioden, begrenset av de forskjellige verktøyenes støtte for parallellitet. For eksempel kan definering og utvikling av tjeneste gå i parallell siden det arbeides på forskjellige elementer og dokumenttyper. Parallell oppdatering på ett og samme element støttes ikke, siden ett dokument ikke kan editeres av mer enn en bruker samtidig. Eksempler på elementer er InfoPath-dokument og spesifisering av arbeidsflyt i SharePoint. Altinn II Side 31 / 54

32 Utvikling av språkutgaver og oversettelse av tjeneste er prosesser som normalt gjøres ved slutten av utviklingsperioden, når tjenesten er komplett i forhold til tekst som skal oversettes. Oversetting kan også gjøres på et senere tidspunkt, da må testing, migrering og publisering av tjenesten gjøres på nytt for den nye språkutgaven i stedet for som del av prosessen for tjenesten som helhet. Under definering og utvikling av tjenesten kan tjenesteutvikler komme til å trenge nye elementer som skal brukes av tjenesten. Dette gjelder for eksempel kodelister og arbeidsflytmaler. Dette er komponenter som må bestilles manuelt og tilgjengeliggjøres for tjenesteutvikler slik at de kan brukes i videre definering og utvikling av tjenesten. Prosessfiguren illustrerer også hvilke verktøy som er de viktigste verktøyene som brukes av hver prosess. De enkelte Use Casene vil beskrive mer i detalj hvilke verktøy som brukes ved utvikling av de forskjellige komponentene, grad av gjenbruk og hvordan parallellitet støttes innad i de forskjellige prosess-stegene. Hovedunntaket fra prosessen, er formidlingstjenester. Her utføres samtlige operasjoner for utvikling, migrering og test i standardverktøyet BizTalk. Dette er nærmere beskrevet i relevante UC. 6.2 Prosess for arbeidsflyt Arbeidsflyt er en vesentlig del av utvikling og bruk av innsendingstjenester. Arbeidsflyten styrer gangen i skjemainnsendingen, og består av forskjellige steg; blant annet innsending, signering og kvittering. Som Figur 6 beskriver, defineres og konfigureres arbeidsflyten under tjenesteutviklingsprosessen. Dersom det trenges ekstra arbeidsflytdefinisjoner, lages disse på bestilling og tilgjengeliggjøres i tjenesteutviklingsløsningen som maler. Figur 7 under beskriver mer detaljert prosessen rundt utvikling og bruk av arbeidsflyt. De forskjellige use casene hvor delprosesssene er beskrevet i er markert med grå firkant. Arbeidsflytmaler og kontroller må utvikles, installeres i sluttbrukerløsningen og tilgjengeliggjøres i tjenestetutviklingsløsningen før de kan taes i bruk ved utvikling av tjeneste. De vanligste arbeidsflytmalene, spesifiserte arbeidsflytmalene og kontrollene er allerede tilgjengelige, og normalt er det prosessen Spesifiser (parametriser) arbeidsflyt som er startpunktet ved tjenesteutvikling. Altinn II Side 32 / 54

33 Use case: TUL - Bygg verktøykasse Utarbeid avansert logikk (kontroll)* (Visual Studio) Installer avansert logikk i SBL (Publiseringsrutiner) Tilgjengeliggjør avansert logikk i TUL (Publiseringsrutiner) Use case: TUL - Utarbeid arbeidsflytmal og komponenter Utarbeid arbeidsflytkomponent (steg) (Visual Studio) Utarbeid arbeidsflytmal (Visual Studio/Visual Designer) PROSESS Use case: TUL - Bygg verktøykasse Installer arbeidsflytmal i SBL (Publiseringsrutiner) Tilgjengeliggjør arbeidsflytmal i TUL (Publiseringsrutiner) Lag og publiser spesifisert arbeidsflytmal i TUL** (Publiseringsrutiner) Use case: TUL - Spesifiser arbeidsflyt Spesifiser (parametriser) arbeidsflyt (TUL) Use case: TUL - Migrer og produksjonssett tjeneste Migrer tjenesteutgave til SBL (TUL, publiseringsrutiner) Use case: SBL Benytt innsendingstjeneste Bruk innsendingstjeneste (SBL) TID * Tidligere kalt hooks. Kontrollen må ikke være tilgjengeliggjort før arbeidsflytmalen er lages. Men kontrollen må være tilgjengeliggjort før den kan velges i en arbeidsflytspesifisering (UC Spesifiser arbeidsflyt) ** Bare nødvendig dersom spesifisert arbeidsflytmal behøves. Lages per tjenesteeier og er i praksis en arbeidsflytmal med defaultverdier. Figur 7 Sekvens for arbeidsflyt Altinn II Side 33 / 54

34 6.3 Forhold til sluttbrukerløsningen Alle tjenester som kan kjøres i sluttbrukerløsningen, kan utvikles i tjenesteutviklingsløsningen. Tjenesteutviklings- og sluttbrukerløsningen er knyttet sammen gjennom et migreringsgrensesnitt, som enkelt lar tjenesteutviklere migrere utviklingsutgaver eller produksjonsklare tjenester fra tjenesteutviklingsløsningen til et sett av test- og produksjonsmiljøer. Tjenesteutviklere vil sitte med en produksjonslik testutgave av produksjonsmiljøet for sluttbrukerløsningen, hvor de kan teste alle aspekter av tjenestene som utvikles, inklusive bruk fra portal og sluttbrukersystemer. Figur 8 Sammenheng mellom tjenesteutviklingsløsningen og sluttbrukerløsningen Altinn II Side 34 / 54