Vedlegg 8: Løsningsbeskrivelse

Transkript

1 Vedlegg 8: Løsningsbeskrivelse Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 1.1 Generelle krav Løsningen skal bestå av et rammeverk som ivaretar design og navigasjon mellom de forskjellige modulene i løsningen slik at løsningen fremstår som enhetlig og sammenhengende.rammeverket skal omfatte følgende innholdskategorier:! Nettstedets logo, navn, etc., som skal vises på alle sider! Språkvalg! Faner e.l. som hjelper brukeren å navigere mellom datakatalogen, blogg, andre dokumenter og ressurser! Innlogging for brukere Løsningen skal kunne fremstå på flere språk, med mulighet for å gjøre innhold tilgjengelig på flere språk. Ja. Se også løsningsskisse. ez Publish har en språkhåndteringen som er meget godt ivaretatt ved at det opereres med oversettinger av innholdsobjekter. Det er enkelt å se hvilke språk et innhold er oversatt til, og systemet gir meget god støtte ved oversettelser til nytt språk. Ved en oversettelse tar man utgangspunkt i en allerede eksisterende språkversjonene og viser teksten som skal oversettes i samme mal. Noe som gjør oversettelsesarbeidet enkelt og oversiktelig for webredaktørene. Hvilken språkversjon som vises på det enkelte nettsted avgjøres av nettstedets språkvalg. Man kan velge å vise et default språk (f.eks engelsk) på de sidene/elementene som

2 1.1.3 Løsningen skal ha minst ett unikt navn, det vil si et navn som ikke er direkte knyttet til løsningen eller leverandøren av løsningen. For eksempel data.norge.no Løsningen skal aktivt hjelpe brukeren til å følge referansekatalogens krav til ITstandarder der det er relevant. ( Et konkret eksempel på dette er at løsningen skal sørge for at dokumenter blir publisert i rett format Løsningen skal utformes i tråd med statens IKTarkitekturprinsipper: tekturprinsipper Løsningen skal tilfredsstille kravene i W3C WAI WCAG 2.0 AA (alle kriterier merket A og AA i standarden - erview.php). Ved leveranse skal dette dokumenteres. ikke har alt innhold ferdig oversatt. ez Publish legger ingen føringer i valg av navn på løsningen. Både ez og Tarantell imøtekommer disse kravene. Detter er arkitekturprinsipper som vi følger i alle våre prosjekter, uavhengig av om det er knyttet til offentlig eller privat sektor. Tarantells sterke brukeropplevelsesfokus tilsier at vi alltid tilstreber å senke terskelen for å gi brukerne en positiv og vellykket interaksjon og opplevelse. I dette ligger også å lage løsninger som er tilgjengelige for så mange av målgruppen som mulig, uansett hva deres forutsetninger måtte være. Dette betyr at vi kjenner og bruker W3C Accessibility Guidelines 2.0 (de delene som er relevante for nettsideutvikling), samt kvalitetskriteriene for offentlige nettsteder på norge.no. Vi utvikler i utgangspunktet koden med separasjon av struktur og innhold, plattformuavhengighet og W3Cstandard kompatibilitet. Videre tilstreber vi "graceful degradation" og unngår å legge opp til grep som gir dårlig usability - som f.eks. cascading javascriptmenyer Løsningen skal benytte RDF/Linked Open Data- Dette dekkes som standard.

3 attributter til å annotere innhold på nettstedet Datakatalog-delen av løsningen bør bygge på Comprehensive Knowledge Archive Network (CKAN) eller bedre. Beskriv hvordan dere ønsker å bruke CKAN. Dersom løsningen ikke bygger på CKAN, begrunn hvorfor og hva dere vil bruke istedet. 1.2 Administrasjon av nettstedet Løsningen skal kunne håndtere et større antall brukere med ulike roller og rettigheter. Det skal registreres kontaktinformasjon relatert til hver bruker. Løsningen vil inkluderer og samhandle med CKAN. CKAN har et programmeringsgrensesnitt basert på RESTful services for aksessering av data. En teknologi og arkitektur som støttes meget godt av ez Publish. Basert på REST vil samhandlingen mellom systemene enkelt implementeres. Sikkerhet, ansvarsforhold og eierskap til data vil bli ivaretatt fullt ut. Vi kan gjenbruke og utnytte CKAN funksjonalitet i de tilfeller det er hensiktsmessig. ez Publish har et enkelt og effektivt grensesnitt for administrasjon for oppsett av rettigheter og tilgangskontroll for grupper eller enkeltpersoner. Det ingen begrensing i antall brukere som kan administreres av ez Publish. Roller og rettigheter defineres av administrator og gir full frihet i definisjon av tilgangsnivåer til funksjonalitet og innhold. Kontaktinformasjon kan registreres som en del av brukerprofilene til brukeren Innholdet på nettstedet skal kunne administreres gjennom et webbasert grensesnitt kryptert med SSL. ez Publish har gode innebygde sikkerhetsmekanismer som tilfredsstiller de strengeste sikkerhetskrav. Som eksempel kan vi nevne at US Department of Defense har testet og akseptert ez Publish som plattform for sine egen nettsider.

4 Sikkerhetsmekanismer innebygd i ez Publish: Audit Trail Captcha Anti- Spam Content Approval Database Backup/Restore Pluggable Authentication Verification Error Reporting LDAP Authentication Login History NTLM Authentication Password Encryption Scheduled Backups Session Management SMB Authentication SSL Support Versioning Løsningen må legge til rette for en enkel autentisering av brukere. Det må være mulig å verifisere enkelte brukere som representanter for departement, etater og kommuner Det skal være støtte for å tildele rettigheter til brukere på en enkel måte. ez Publish har innebygd funksjon for brukerautentisering. Brukerne tildeles roller, rettigheter og organisatorisk tilhørighet i administrasjonsgrensesnittet til ez Publish. Gjøres via ez Publish sitt administrasjonsgrensesnitt. Alt administrasjon fra ett og samme grensesnitt Alt innhold skal eies av én eller flere brukere i systemet. Alt innhold blir lagret med informasjon om hvem som her opprettet og eierskap til innholdet. Det finnes mulighet for arbeidsflyt som kan definere ulike rettighetsnivåer på innholdsobjektene. Mange selskaper ønsker god kontroll å på hva som faktisk legges ut på nettsidene og det kan styres via en

5 1.2.6 Administrator skal kunne administrere alt innhold Løsningen skal kunne håndtere flere versjoner av metadata, der hver av versjonene korresponderer med ulike versjoner av datasettet metadataene beskriver. Det skal komme klart frem hvilke versjoner av det beskrevne datasettet som er tilgjengelige til enhver tid, og hvilke versjoner som er historiske Løsningen skal ha en rutine for håndtering av metadata for relaterte datasett. Det skal være mulig å se metadata for relaterte datasett i sammenheng Løsningen skal ha en rutine for utfasing av beskrivelser av spesifikke datasett Løsningen skal kunne håndtere import av metadata fra andre kilder. Slik import skal kunne automatiseres. godkjenningsfunksjon. En regels som styrer hvem som har ansvar for godkjenning før publisering. Hvis innholdselementer skal deles mellom flere brukere, blir dette styrt ut i fra rettighetene til den enkelte bruker. Standard oppsett av ez Publish tillater Administrator å administrere alt innhold og alle funksjoner i løsningen. Defineres ut fra roller og rettigheter. Alle innholdsobjekter, også metadata, har versjonskontroll. Når ny versjon av datasettet opprettes vil forrige versjon bli lagret og arkivert. ez Publish lagrer all historie og kan også vise forskjellen mellom to versjoner av datasettet. Alle innholdsobjekter kan relateres til andre objekter. Dette gjelder også innholdsobjektet Datasett. Når innholdsobjektet opprettes kan redaktør registrere relasjonene til andre datasett. Et datasett produseres og publiseres på samme måte som annet innhold. Hvis en utfasning av datasettet er bestemt kan man registrere en avpublisering i forkant av hendelsen. Datasettet vil da forsvinne fra alle lister på den data og det klokkeslett som er registrert. ez Publish har egen modul for import og eksport til/fra eksterne kilder. Settes opp som automatiserte jobber for å hente/sende på gitte tidspunkt (tidsbasert) eller å hente/sende ved forhåndsdefinerte hendeler(hendelsesbasert ). Forutsetningen er at det eksterne systemet kan motta og sende informasjon

6 Datakatalogen skal inneholde metadata som kreves for å kunne gjøre en tjeneste tilgjengelig, eksempelvis informasjon, relevante adresser, formater, dokumenter, standarder, lisenser og kontaktinformasjon for feilmeldinger meldt på nettstedet. Beskriv hvordan disse metadatadefinisjonene kan vedlikeholdes Alle innholdselement skal ha en unik permanent URI. URI-en må være lesbar ( human readable ), være hierarkisk oppbygget, og være utformet slik at man skal kunne tolke hva den representerer. Beskriv hvordan disse URI-ene kan vedlikeholdes Det skal være mulig å navigere i metadataene på flere måter, f.eks. etter eier, forvaltningsnivå, eiers geografiske plassering, på et strukturert og lesbart format, f.eks. XML. Informasjon om metadata vil bli importert fra eksterne kilder og er avhengig av kildens datakvalitet. Metadata vil presenteres i egen mal, der hvert enkelt felt er separert og presentert på en lesbar måte for redaktør. Hvis informasjonen fra eksterne kilde skal vedlikeholdes må man ha klare regler for ny versjoner av metadata som påvirker eksisterende. Det beste er å beholde informasjon fra eksterne kilde uendret, men heller bygge på med nye felter som kan endres av redaktør. ez Publish leverer alle URI som beskrevet i kravet. ez Publish vedlikeholder alle URI internt i rammeverket. Alle innholdsobjekter tildeles et internt referansenummer. Alle relasjoner mellom informasjonsobjekter benytter dette nummeret for å linke relatert innhold. Hvis et informasjonsobjekt flyttes i strukturen vil ikke det få konsekvenser for relasjonene til andre informasjonsobjekter. Alle relasjoner beholdes pga. at referansenummeret fortsatt er gyldig og kjenner den nye plasseringen til objektet. Dette gjelder også eksterne systemer som har en relasjon til informasjonsobjekter i ez Publish. Ingen brutte linker selv om objektet flyttes internt i strukturen. ez Publish legger ingen føringer i forhold til hvordan metadata kan navigeres.

7 type data og lisenstype Det skal være mulig å gi tilbakemelding på alle datasett som er beskrevet i datakatalogen. Beskriv hvordan dette løses og administreres Det skal være mulig å følge en RSS/Atom-feed med nyheter om hvert datasett som er beskrevet i datakatalogen. Disse nyhetene skal kunne lages direkte på nettstedet. Løsningen skal også kunne videreformidle nyheter fra dataeier. Søkelogikk og informasjonsarkitekturen i løsningen legger premissene for hvordan man kan/skal navigere i metadata. Løsningen støtter brukergenererte tilbakemeldinger på datasett. I tillegg finnes det en moderator funksjon der tilbakemeldingen kan kontrolleres og redigeres før publisering. Integrering av RSS/Atomfeeds leveres som standard funksjonalitet i ez Publish og vil være inkludert i leveransen Alt innhold skal være synlig datert. Inkluderes i presentasjonsmalene Hvert datasett som er beskrevet i datakatalogen skal presenteres med nøkkeltall relatert til visningen av datasettet. Et eksempel på nøkkeltall er antall visninger i en gitt periode. Det skal være mulig å navigere etter slike nøkkeltall Det skal være mulig å registrere informasjon om applikasjoner. Det skal være mulig å registrere metadata om applikasjonen, i tillegg til at det skal være mulig å knytte metadata om applikasjonen til metadata om de datasettene applikasjonen benytter. 1.3 Krav til nettstedet Nettstedet skal ha en innbydende utforming hvor alt innhold redigeres i samme grensesnitt som visningen Løsningen skal ha en søkemekanisme som lar bruker søke i fritekst på alt innhold i løsningen. ez Publish kan presentere datasett på bakgrunn av ulike nøkkeltall. De vanligste nøkkeltall er Mest leste og Sist publiserte som er standard funksjonalitet i ez Publish. Det kan lages visning av andre nøkkeltall hvis det er ønskelig. Tilrettelegges i en mal for publisering av data om applikasjoner. I tillegg kan applikasjonen relateres til andre applikasjoner eller til andre datasett. Støttes som standard i ez Publish. Støttes som standard i ez Publish Det skal være mulig å karakterisere noen av de beskrevne datasettene som populære eller hotte. Disse skal kunne profileres på Som nevnt i punkt kan datasett presenteres på forskjellige måter. Visning av de mest populære

8 fremsiden og/eller i sidekolonner. datasettene kan presenteres ut fra gitte regler, Mest leste eller Mest brukte. Denne type lister kan også produseres manuelt av webredaktør, noe som kan være hensiktsmessig i enkelte tilfeller for å markedsføre nyttige datasett. 1.4 Krav til bloggen Det skal være mulig å importere alt innhold fra den nåværende bloggen på data.norge.no inn i den nye bloggen. 1.5 Presentasjon av datasett Eier av datasett skal kunne laste opp ett eller flere eksempel på datasettet. Disse skal både kunne lastes ned og kunne visualiseres i nettleseren av besøkende. Minimum støtte er JSON og XML. 1.6 Tilgjengelighet av rådata Katalogen over offentlige datasett skal beskrives som et eget datasett i løsningen, og gjøres tilgjengelig i standardiserte, strukturerte, maskinlesbare formater. Katalogen skal som et minimum gjøres tilgjengelig på veldokumentert JSON- og XMLformat (Dette er det eneste datasettet som skal gjøres tilgjengelig på data.norge.no). Beskriv forslag til format og programmeringsgrensesnitt for dette datasettet. Forutsetter at dagens blogg kan eksportere data på et strukturert maskinlesbart format, som for eksempel XML. ez Publish støtter visning av JSON og XML format. ez Publish kan importere XML og JSON format direkte inn i egen objektstruktur på råformat. Hvis datasettene skal benyttes og vises på andre måter vil vi lage en modul for å transformere datasettet til et fullverdig ez Publish objekt. Objektet vil da inneha alle de samme egenskapene som øvrige innholdsobjekter i løsningen. I utgangspunktet ingen begrensinger i programmeringsgrensesnitt, men Web Services eller REST (http eller URL) er anbefalt.

9 Skisse til løsning Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 2.1 Leverandøren må gi en skisse til løsningsforslag. Løsningsforslaget skal minst omfatte:! En modell for løsningen som synliggjør hvilke funksjoner som inngår i løsningen! En spesifikasjon av hvilke programvarekomponenter nettsted og database baseres på Oppgi hvilke deler av løsningen som baserer seg på hyllevare, egenutviklete standardløsninger og skreddersøm, og hvilke lisenser som gjelder for hver komponent. 2.2 Dersom løsningen bygger på programvare som leverandøren ikke selv står ansvarlig for, bes det om opplysninger om forhold mellom leverandør og rettighetshaver, og om planer for videreutvikling av programvaren og løsningen. Se vår løsningsskisse og beskrivelse av Programvarekomponenter under. ez Publish leveres og utvikles av ez Systems. ez Publish. All sprogramvare fra ez Systems er 100% Open Source og underlagt GPL lisensen eller New BSD. ez Systems har eierskap til systemet, men kan fritt benyttes av andre i nesten alle sammenhenger. For å få en fullverdig garanti på programvaren må det tegnes en egen Supportavtale med ez Systems. De vil da garantere for basis programvaren. Se vedlegg Supportavtale ez Systems for mer informasjon. 2.3 Leverandøren bes beskrive ansvarsforhold, ressurser og rutiner for utvikling, feilretting, kvalitetskontroll og support for tilbudt tredjeparts programvare. Se forklaring under.

10 Utdypning av punkt 2.1 Vi ser for oss følgende løsning: Selve layout og menyvalg / plassering vil utvikles i samarbeid med dere. Dette er ment som et utgangspunkt for utvikling. Vi har søkt å ivareta alle komponentkrav som det etterspørres. Programvarekomponenter som inngår i løsningen Data.norge.no ønsker et et nytt løsning for innholdsproduksjon og innholdsforvaltning og vi har vurdert kravene opp mot flere alternative CMS løsninger. I tillegg til de kravene som er definert i forespørselen har vi lagt vekt på noen viktige utfordringer man ofte ønsker løst i nytt publiseringssystem:! Større fleksibilitet og enklere publisering! Et system som supporteres og som har kompetanse hos flere leverandører! Større mulighet data.norge.no til å gjøre endringer med egne ressurser.! Bedre funksjonalitet i løsningen, som for eksempel: o Brukerinteraksjon med Blogg, Forum og brukerkommentering. o Rapportering og statistikk o Forhåndsvisning av innhold

11 o Større innslag av standard funksjonalitet, som gir mange muligheter fremover På bakgrunn av en totalvurdering anbefaler vi ez Publish CMS som plattform for data.norge.no. Under utdyper vi hvorfor vi mener dette er det riktige valget. Generelt om ez Publish Utstrakt publiseringssystem ez Publish er et meget utstrakt brukt publiseringssystem rundt om i verden. Publiseringssystemet benyttes for flere tusen nettsteder på verdensbasis. Se for en oversikt over noen av disse. ez Systems ez Publish er utviklet av det norske selskapet ez Systems. ez Systems har hovedkontor i Norge, med kontorer i USA (dekker nord Amerika), Tyskland (dekker øst Europa), Danmark (dekker Skandinavia sammen med det norske kontoret), Frankrike og Belgia (dekker vest Europa), og Japan (dekker Østen). Fri programvare levert av et kommersielt selskap Bak ez Publish står et kommersielt selskap. ez Systems er en programvareleverandør som leverer sine produkter med fri og åpen kildekode. Dette gjør at ez Systems skiller seg ut både fra vanlige programvareleverandører, og fra prosjekter basert på fri programvare. ez Systems har ikke lisens på sine produkter, men har sin inntektskilde blant annet gjennom å tilby support- og vedlikeholdstjenester på produktene de produserer. Samtidig tar selskapet produktansvar. Strukturert utviklingsløp og organisk, community-basert utvikling For produkter med fri og åpen programvare kan alle som ønsker det utvikle tillegg til eller modifikasjoner for programvaren, dette gjelder også ez Systems' produkter. Men disse skiller seg fra annen fri programvare ved at alt som utvikles av ez Systems er definert i en roadmap basert på kundenes ønsker og behov. Denne utviklingen følger en fast rytme og et strukturert utviklingsregime. Miljøet rundt ez bidrar med både ideer og konkrete utvidelser i den organiske utviklingen som er typisk for miljøer rundt fri programvare, men all programvare som slippes fra ez Systems selv er gjennomgått av ez Systems egne teknikere og innebærer en garanti om at det fungerer sammen med annen programvare fra ez Systems. Fri programvare med garanti og support ez Systems garanterer gjennom sin support- og vedlikeholdsavtale at deres programvare virker. Dette innebærer at dersom kunden oppdager feil eller mangler i programvaren, rettes dette opp av leverandøren. Enkelt sagt betyr det at kunden har en leverandør å henvende seg til dersom feil eller mangler oppdages. Support I tillegg til det som måtte oppdages av feil og mangler tilbyr ez Systems support til kundene. Denne kan enten leveres direkte fra ez Systems, eller gjennom kundens leverandør, avhengig av hva kunden foretrekker. Det betyr at man kan få direkte eller indirekte support fra de som faktisk har utviklet programvaren. Frihet og trygghet i leverandørvalg En av fordelene med fri programvare er at man kan ta med seg løsningen sin og gå til en annen leverandør dersom man skulle ønske det. Som for alle produkter basert på fri programvare kan alle som ønsker det laste ned, videreutvikle og levere produktene fra ez Publish til sine kunder. Men ez Systems har i tillegg til alle sine «community-partnere» et formelt nettverk av profesjonelle forretningspartnere. Dette er partnere av ulik størrelse og med spesialkompetanse innen ulike felter. ez Publish er utviklet i php, som er et velkjent og velprøvd programmeringsspråk med meget stor utbredelse i hele verden. Partnerapparat Tarantell får jevnlig opplæring i ez Systems' produkter, blant annet får de innføring i ny funksjonalitet ved hver ny versjon av ez Publish, og har utviklere som er sertifisert på ez Publish. Vi er også støttet av ekspertkonsulenter fra ez Systems. Dermed har kundene stor frihet til å velge akkurat den leverandøren de ønsker, og stor trygghet dersom de velger en partner anbefalt av ez Systems ut fra deres behov. Beskrivelse av modulene og standard funksjonalitet i ez Publish ez Publish - Modulen for administrasjon av alt innhold, bilder, filer med mer. Komplett løsning for alle organisasjoner med behov for god innholdsforvaltning.

12 ez Newsletter en modul for nyhetsbrev som er perfekt for e-post markedsføring av tilbudet til organisasjonen eller for å informere kunder om aktiviteter fremover. ez Flow - Levende nettsider fokuserer ofte på innholdsflyt og tidsstyring av innhold. ez Flow gjør redaktører i stand til å bygge komplekse sideoppsett og forprogrammere publiseringen av innhold fremover i tid, innenfor forskjellige deler av sideoppsettet. ez Find ez Find er en enterprise søkeløsning for ez Publish. Basert på Lucene Java/ Solrsearch muliggjør ez Find bla. søk på flere ez Publish installasjoner samtidig. ez Find hjelper besøkende på nettsidene med raskt og enkelt finne informasjon ved hjelp av relevante søkeresultater. Stor skalerbarhet og høye ytelser. ez Component - ez Components er et bibliotek av komponenter som kan brukes samlet eller hver for seg når man skal utvikle PHP applikasjoner.

13 Utdypning av punkt 2.3 Systemutvikling rutiner Fagområdet programmering, systemutvikling og systemarkitektur i Tarantell Beskrivelse av vår tilnærming og definisjon av fagområdet Vår forståelse og tilnærming til fagområdet Systemutvikling avviker i teorien ikke stort fra andre i samme bransje. Vi bestreber å følge anerkjent retningslinjer og følger prinsippene om Best Practice i alle sammenhenger. Vi ønsker ikke å eksperimentere med nye og uprøvde teknikker i kundeprosjekter, som kan gå på bekostning av kvalitet og kundetilfredshet. Vår definisjon av Systemutvikling Systemutvikling er metodisk og målrettet arbeid med å utvikle nye datasystemer eller informasjonssystemer. Metodisk Prinsipielt skal en systemutviklingsmetode organisere alle aktivitetene i prosjektet. Systemutviklingsmetoden deler inn og beskriver hovedaktivitetene i detalj. Metoden kan også dele hovedaktivitetene inn i faser, oppgaver, steg osv. Videre er det viktig at metoden klargjør ulike roller og ansvarsområder mellom teammedlemmene. Den kan i tillegg angi hvilke dokumenter og andre produkter som skal leveres og hvilke teknikker og verktøy man skal benytte underveis. Vi mener løsninger ikke bør detaljeres og planlegges for mye i starten. Gode løsninger skapes ut fra en kreativ prosess og utvikles best basert på erfaringer. Systemutvikling har i mange år forsøk å levere i faser innenfor en bestemt rekkefølge. Alle fasene har hatt sin avslutning og sin isolerte leveranse. Det har gitt mindre rom for endringer og tilpasninger underveis, noe som har resultert i løsninger som ikke har oppnådde ønsket effekt eller tilfredstilt mål kunden definert i starten. De siste årene har bransjen tatt dette på alvor og har utviklet metoder som bedre skal kunne håndtere de kreative prosessene i systemutvikling. Smidige metoder med Scrum er en slik metode som vi har god erfaring med og har benyttet med meget gode resultater både for oss og for kunden. Målrettet Når vi sier at det ikke er hensiktsmessig å beskrive løsningen ned til minste detalj i tidlige faser, er det derimot helt avgjørende at det er klare målsetninger med løsningen. Målsetningene kan være mange og ulike, men vi vil alltid jobbe sammen med kunden for å forankre en klar og entydig målsetningen. Tarantell har kompetansen som sammen med kunden egen domenekunnskap kan definere, utdype og konkretisere målsetningene som skal ligge som grunnlag for utviklingen av en god løsningen. Aktiviteter Kort fortalt omfatter systemutvikling flere aktiviteter. Viktig å påpeke at listen under ikke sier noe om rekkefølgen på aktivitetene, men er ment som en forklaring og beskrivelse av de enkelte. Kravarbeid innebærer å fastlegge de overordnede kravene til det planlagte systemet og vurdere de opp mot målsetningen. Utforming går ut på å bestemme overordnet informasjonsarkitektur, interaksjonsarkitektur og systemarkitektur. Bestemme grafiske prinsipper, overordnede skisser og dele systemet inn i delsystemer og moduler. Implementasjon går ut på å realisere systemet med gitt teknologi og definert metode. Testing på alle nivåer er en del av denne aktiviteten. Kunden har mulighet til å teste underveis om ikke bare på slutten av prosjektperioden Akseptanseperiode. Kunden periode for full utprøving og testing av løsningen. Går ut på å sjekke at systemet oppfører seg i henhold til kravspesifikasjonen. Innføring av løsningen med kvalitetsgaranti. En smidig overgang fra det gamle til det nye systemet med en garanti for vederlagsfri feilretting og forvalting i en gitt periode. T Tarantell AS Grev Wedels plass 5, 0151 Oslo, Norge Tlf: Faks:

14 Forvaltning og Support av systemet over tid. Vi tar ansvar også utover prosjektets levetid med en egen forvaltingsorganisasjon der systemet kan videreutvikles og vokse sammen med kunden. Vår praktiske tilnærming til fagområdet Tarantell har lang erfaring og høy kompetanse innenfor fagområdet Systemutvikling. Siden starten i 2000 har vi jobbet målrettet for å bygge riktig kompetanse og har stort fokus på kontinuerlig kompetansebygging. Med kvartalsvis kompetansesamtaler og med levende faggrupper er vi sikre på at våre konsulenter har den kompetansen som våre kunder forventer. Tradisjonelt har vi benyttet internett-teknologi til utviklingen av forretningsapplikasjoner, og vi har derfor vår største styrke på dette domenet. Uansett type løsninger, enten det er webapplikasjoner eller mer tradisjonelle desktop applikasjoner, følger vi den samme metodikken og de samme kvalitetsstandardene for vår systemutvikling. Praktisk metodikk Vi vet av erfaring at både prosjektets mål, behov og forutsetninger kan endres kraftig underveis. Med fastsatte kravspesifikasjoner vil det ofte være en utfordring å fange opp og tilpasse seg slike ting under prosjektets forløp. Med en metodisk tilnærming vil vi evaluerer løsningen fortløpende; hva er de viktigste komponentene å få på plass? virker de i praksis slik de bør, eller bør de endres noe? hvilke tilleggsbehov oppstår underveis? hvilke behov avtar eller forsvinner? Tarantell ønsker primært å gjennomføre prosjekter basert på Smidig systemutviklingsmetodikk, der Scrum er vår preferert modell. Scrum tar hensyn til kundens modningsprosess og endringsønsker på en mye bedre måte enn tradisjonell fossefallsmetodikk (RUP). Hovedtanken bak Scrum er at komplekse prosesser, som utvikling av programvare er, best håndteres ved en empirisk tilnærming. Med empirisk tilnærming mener vi en tilnærming som bygger på erfaring og observasjon, noe som er viktig i alle sammenhenger. Den beste løsningen gjør vi i tett samarbeid med kunden og ikke basert på tidlige antagelser. T Tilbud: data.norge.no Tarantell AS Side 77 av 89

15 Generelt Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 3.1 Dokumentasjon Følgende dokumentasjon skal tilpasses oppdragsgiver og utarbeides:! Brukerdokumentasjon for innholdsleverandørene! Bruker/system-dokumentasjon for administrator! Driftsdokumentasjon for leverandør av tjenesten! Brukerveiledning for sluttbruker, tilgjengelig på nettstedet! Teknisk dokumentasjon (programvare, versjoner, plattform, osv.) Brukerdokumentasjon utarbeides spesielt for data.norge.no og inkluderer de tilpasninger som er gjort med rammeverket. Bruker/Systemdokumentasjon for administrator beskrives spesielt for denne løsningen. Driftsdokumentasjon for leverandør av tjenesten er standard dokumentasjon fra ez Systems Brukerveiledning for sluttbruker, på nett utarbeides spesielt for denne løsningen. Teknisk dokumentasjon er standard dokumentasjon fra ez Systems. Standard dokumentasjon fra ez Systems finnes her: Løsningen i seg selv skal være mest mulig selvforklarende, og alle moduler og funksjoner skal beskrives i dokumentasjonen. Inkluderes i dokumentasjonen beskrevet over. Vi vil i tillegg til dokumentasjon anbefale at alle interne brukere gjennomfører et brukerkurs. Tarantell kan ta ansvar for gjennomføring av kurset. T Tilbud: data.norge.no Tarantell AS Side 78 av 89

16 3.1.3 Alle skjema skal følge ELMER standarden. /anvendelsesomraade/naeringslivskjema-paaoffentlige-nettsider /standard/elmer/elmer-v All dokumentasjon som utarbeides for løsningen skal leveres i elektronisk form Driftsdokumentasjon skal være så presis og detaljert at personer som ikke har deltatt i utviklingen har mulighet til å drifte systemet. 3.2 Kildekode og rettigheter Kildekoden skal leveres med historikk i form av versjonskontroll, og det skal være mulig for tredjepart å bidra med nye funksjoner til kildekoden. Oppgi hvilket versjonskontrollsystem dere vil levere kildekoden i Spesialutviklet kildekode skal dokumenteres grundig. Det skal være mulig for andre å bruke kildekoden til å sette opp tilsvarende nettsteder. Dokumentasjonsspråket er engelsk. Ikke en del av tilbudet, men kan prises separat. Vi kjenner godt til ELMER standarden og har benyttet den helt eller delvis i andre prosjekter. ez Publish legger ingen begrensninger i forhold til utforming av skjema. ELMER standarden kan følges 100%. Dette dekkes som standard. Dette dekkes som standard Tarantell benytter SubVersion og vil levere kildekode fra dette systemet. Dette imøtekommes. T Tilbud: data.norge.no Tarantell AS Side 79 av 89

17 Test Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 4.1 Leverandøren skal lage en testplan for følgende tester: 1) funksjonstest 2) robusthetstest 3) integrasjonstest 4) volum-, kapasitets- og svartidstest 5) gjennomgang av all dokumentasjon 6) installasjonstest 7) test av driftsprosedyrer, herunder sikkerhetskopiering 8) nettlesertest 4.2 Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer rundt dette. Prosjektet inkluderer en testplan for alle tester beskrevet i kravet. Vi har her beskrevet prinsippene for hvordan vi går frem for å kvalitetssikre og teste løsningen gjennom hele prosjektperioden. Se egen beskrivelse under. Tarantell benytter oss av et rapporteringssystem for endring- og feilretting som kalles Bug-Aware. Se beskrivelse under. Utdypning av punkt 4.1 Test Sentralt i Tarantells metodeverk er planlegging og gjennomføring av repeterende testing. Dette er viktig både for å sikre robusthet og kvalitet i leveransene, men også for å sikre at leveransene blir korrekte: Det at man tidlig vet hvilke tester og leveranseprøver en skal gjennom gir høy grad av sikkerhet på at leveransen kan testes og aksepteres ihht de definerte krav. Begreper og definisjoner Enhetstest: Separat test av løsningens enkeltkomponenter. Enhetstest gjøres ofte for å verifisere ferdigstillelsen og kvaliteten i en enkelt komponent, og kan gjennomføres uavhengig av systemets ferdigstillelsesgrad. Systemtest: Sentral test av systemet. Systemtest gjennomføres for å avdekke avvik eller uregelmessigheter i systemets prosesser og gjennomgripende funksjoner, og skal verifisere at systemet isolert sett fungerer etter spesifikasjonene. Integrasjonstest: Global testing av system i komplette og representative omgivelser. Under integrasjonstest skal alle grensesnitt mot andre, tilgrensende systemer være etablert, og det er en primær oppgave for integrasjonstesten å avdekke evt. avvik og uregelmessigheter i disse grensesnittene. Integrasjonstest gjennomføres etter at systemtest er godkjent. T Tilbud: data.norge.no Tarantell AS Side 80 av 89

18 Akseptansetest: Mottakerorganisasjonen test og verifisering av at leveransen er ihht spesifikasjonene. Dette er den endelige leveranseprøven, og representerer det juridiske tidspunktet for overtakelse av systemet. Akseptansetest gjennomføres etter at integrasjonstest er godkjent. Kjørebeskrivelse: For alle testgjennomføringer skal det eksistere kjørebeskrivelser som beskriver hvilke handlinger testeren skal utføre i systemet samt hvilket resultat testeren kan forvente å få. Avvikshåndteringssystem: Ved gjennomføring av test ihht kjørebeskrivelse skal avvik fra forventet resultat rapporteres i et avvikshåndteringssystem. Systemet holder logg over alle rapporterte avvik, og gir status på ferdigstillelse av rettelser. Iterasjon: Enhver test gjennomføres i et nødvendig antall gjentakelser til definerte avvik er rettet. For planlegging av testene settes det opp et antall gjentakelser eller iterasjoner, som vil være utgangspunkt for testgjennomføringen. Kategorisering av feil/avvik For kategorisering av feil/avvik benyttes følgende: A-feil: Kritiske feil (systemfeil) B-feil: Alvorlige feil (funksjonelle feil som hindrer testgjennomføringen) C-feil: Feil av mindre betydning (kosmetiske feil ) Stopp- og fortsettelseskriterier Gjennomføring av system-, integrasjon- eller akseptansetest stoppes hvis: det finnes feil som medfører at testen ikke kan gjennomføres det identifiseres et stort antall feil som skulle vært funnet i tidligere testfaser det identifiseres feil i en funksjon som påvirker test av andre funksjoner. Gjennomføring av system-, integrasjon- eller akseptansetest stoppes midlertidig hvis: forsinkelse i rettingen av feil, umuliggjør test av resterende funksjonalitet i syklusen/systemet. Testdatagrunnlaget viser seg å inneholde alvorlige mangler/feil Testen fortsettes enten fra avbruddstidspunkt eller fra begynnelsen av testsyklusen etter at avbruddet er analysert og rettet. Testen gjennopptas så snart stoppkriteriene er løst. Regresjonstest Alle testsykluser skal kjøres en gang uten feil av kategori A og kategori B. For akseptansetest (endelig leveranseprøve / SAT) henvises til kravspesifikasjonen. Iterasjoner og planlagte tester Alle tester gjennomføres etter noen grunnleggende prinsipper: Først testes installasjon og funksjoner i standard programvare. Deretter testes tilpasninger og parametersettinger som er spesielle for installasjonen (men fortsatt innenfor rammene av standard programvaren). Dernest funksjonstestes skreddersydde moduler og komponenter som ikke er en del av standard programvaren. Til slutt testes alle grensesnitt og datakvaliteten i integrasjonen med tilgrensende systemer. Alle disse nivåene av testing vil være tilstede i varierende grad i system-, integrasjon- og akseptansetest. Parallelt med funksjonell test kan det gjøres ytelsesanalyse og ytelsestest av systemet. Ytelsesanalyse vil gi indikasjon på eventuelle flaskehalser i systemet, og er vesentlig mye enklere å gjennomføre enn en fullskala ytelsestest. Tarantell har lagt opp til flere ytelsesanalyser av systemet underveis i utviklings- og testløpet. Som opsjon kan Tarantell også tilby analytisk brukertesting med videoopptak. Denne typen brukertesting T Tilbud: data.norge.no Tarantell AS Side 81 av 89

19 kan benyttes for å avdekke bruksmessige problemområder ved presentasjonen og brukergrensesnittet. Vi kan også tilby andre brukertester skulle det være behov for det. Illustrasjonen under viser sammenhengen i tid mellom de forskjellige testtypene: Stresstesting: Denne testen gjennomføres når løsningen er etablert på driftsplattform, og de øvrige tester er gjennomført. Testen skal kvalitetssikre at løsningen takler intensiv trafikk. Til denne testen benyttes anerkjente verktøy, og selve testen gjennomføres av systemansvarlig. Feilrapportering All feilrapportering skal registreres i Tarantells rapporteringssystem. Alle feil og nødvendige korreksjoner legges inn i en felles webbasert ToDO list rapporteringsverktøyet. Dette verktøyet vil bli benyttet i alle de ulike testfasene og Kundens navn vil få en egen gjennomgang. Når det gjelder dokumenter som skal benyttes ved Systemtestingen (pkt 4) er disse beskrevet under dette punktet. Utdypning av punkt 4.2 Endringshåndtering FEILRAPPORTERING OG OPPFØLGINGSSYSTEM / BUGAWARE Bugaware er et åpen og tilpassbar system for forvaltning og oppfølging av feil og endringsønsker. I tillegg kan Bugware brukes også som helpdesksystem. For en detaljert beskrivelse se: Fordeler med BugAware er: Ett web-sted å forholde deg til, slik at en slipper å lete gjennom mailer for å få oversikt over aktive saker. Saker blir ikke borte i mail. Aktive saker er tilgjengelig for alle som er definert som stakeholders eller har blitt tildelt tilgang. Ved sykdom, ferie, og lignende så kan andre følge opp saker som allerede er under arbeid, med en helhetlig sakshistorikk og bakgrunn. T Tilbud: data.norge.no Tarantell AS Side 82 av 89

20 Oppgaver kan vises som kun dine egne eller din gruppe, slik at man kan fokusere på det som skal følges opp, og/eller forbedre samarbeidet. Sakshistorikk på utførte oppgaver blir ivaretatt. Ved å ikke være bundet til enkeltes e-post kan saker tas over av andre for å holde tidsfrister, eller sikre fremdrift. T Tilbud: data.norge.no Tarantell AS Side 83 av 89