Logotyp vetenskapsrådet
logo_mobile

Så jobbar vi med utveckling

I utvecklingsprojekt strävar Vetenskapsrådet efter att arbeta agilt.

Nyutveckling görs i tätt samarbete med förvaltnings­organisationen som teknisk kravställare och baseras på användarnas behov och myndighetens övergripande strategiska mål.

Checklista vid nyutveckling

Vid utveckling av en ny webbplats, tjänst eller funktion följer vi denna checklista:

1. Förstudie

En gedigen och förankrad förstudie gör utvecklingsfasen snabbare och enklare. Förstudien ska kartlägga användarnas behov. Vid behov ska den ta ställning till lämpliga teknikval och klargöra risker samt hur dessa kan hanteras.

Innan ett större utvecklingsprojekt startas ska det vara beslutat av ansvarig chef, resurssatt (pengar och personella resurser) och definierat/avgränsat avseende vad det ska leverera och inom vilken tidsram. Målsättningar, vilka problem som ska lösas etc behöver ramas in.

Vid behov ska ett varumärkesarbete med fokus på identitet, tonalitet etc ingå som ett första steg i förstudien.

En effektkarta och användarberättelser (user stories) är viktiga leverabler i en förstudie.

I en del fall kan det vara lämpligt att en förstudie innehåller wireframes och designskisser, men det kan också ingå i utvecklingsprojektet. KPI:er eller andra mål för det som ska nyutvecklas kan också ingå.

2. Teknikval

Vi strävar efter en tekniskt enhetlig, säker och lättförvaltad miljö.

VR:s förstahandsval för webbpublicering är SiteVision. För webbplatser som förvaltas av VR men drivs i samarbetemed andra kan Wordpress användas.

Vi väljer standardfunktionalitet. I de fall detta inte kan användas ska valet motiveras och dokumenteras. Vi undviker att föra in nya tekniklösningar (ramverk, plug ins, tredjepartsprodukter etc) om det inte är nödvändigt. Vi är noggranna med att kontrollera lagring av data, personuppgifter och cookies och samrådet vid behov med vårt dataskyddsombud.

Teknikval ska göras efter samråd med webbleverantör, digital strateg, förvaltningsledare verksamhet och förvaltningsledare it. Då helt ny teknik tas in ska synpunkter inhämtas från VR:s arkitekturråd och beslut fattas i objektstyrgrupen för digitala kanaler.

3. Design

Om design inte ingår i förstudien så är den en viktig del av det inledande arbetet i utvecklingsprojektet. Designen ska utgå från de riktlinjer som finns dokumenterade i VR:s designsystem.

Användarvänlighet, tillgänglighet och mätbarhet är nyckelfaktorer i designarbetet.

4. Hantering av kod

Kod ska granskas, lagras och hanteras på samma sätt som övrig kod för digitala kanaler. OM undantag görs ska dessa vara godkända av VR och väl dokumenterade.

Kod ska också, i de fall då det är relevant, kommenteras direkt i den miljö där koden används.

5. Migrering

När det är en befintlig webbplats eller digital tjänst som görs om så måste det på ett tidigt stadium definieras hur det befintliga innehållet ska tas omhand.

Migrering av innehåll och ompekningar av url:er är ett resurskrävande arbete och det behöver finnas en tydlig plan för hur detta ska göras.

Grundregler:

  • Sidor som används aktivt (kan ses via t ex webbanalys) ska de migreras och url:en pekas om. Detta är en viktig service till användare och gynnar även webbplatsens position i sökmotorer.
  • Sidor som vi inte flyttar med (för att innehållet inte besöks/används eller för att den nya sajten inte ska hålla detta innehåll p g a t ex ny inriktning/ändrat uppdrag) ska hanteras via en sk 410-sida. Denna kommer att skicka en tydlig signal till användare och sökmotorer att sidan/dess innehåll är permanent borttagen.

6. Dokumentation

Systemdokumentation ska göras av leverantören och hanteras som annan teknisk dokumentation för VR:s digitala kanaler.

Manual för redaktörer ska ingå i leveransen. Redaktörsmanualen ska beskriva hur det dagliga arbetet med sajten gör. Denna dokumentation placeras om det är möjligt som en intern del i den sajt/applikation som nyutvecklas.

Dokumentationen testas under utvecklingen, samtidigt som man testar de funktioner som dokumentationen beskriver. VR:s redaktörer kan (och ska) komplettera dokumentationen löpande.

Testprotokoll, som ska användas av VR:s redaktör vid t ex framtida uppgradering av CMS, ska ingå i leveransen. Testprotokollet ska vara anpassat till sajten och dess funktioner.

Cookies: En text som beskriver vilka cookies som används, namn på cookien och vad den gör, hur länge den lagras etc (se VR:s mall) ska följa med vid leverans. Texten ska utgöra en del i informationen om kakor.

Tillgänglighet: En dokumentation av lösningens tillgänglighet och hur denna testats ska ingå i leveransen och kunna utgöra en del i tillgänglighetsredogörelsen.

7. Testning

Alla lösningar som utvecklas ska testas och kvalitetssäkras av leverantören innan VR acceptanstestar.

Utöver testning av funktioner är det viktigt att även involvera riktiga användare för att i ett tidigt skede testa så att det som utvecklas fyller användarnas behov. Testning kan t ex ske med hjälp av en enkel skiss på papper eller med en prototyp.

Tillgänglighetstestning ska ske, både av leverantören och av dig som beställare.

Kom överens med leverantören innan arbetet startar vilka tester som de gör och vilka som du ska göra. Om du bedömer att du kommer att behöva hjälp att acceptanstesta – rådgör med digital strateg och leverantör.

8. Mätning

Vad som ska mätas och hur har ofta direkt bäring på design och kod. Som del i projektet ska mätningar sättas upp eller mätmetoder tas fram.

9. Överlämning

När utvecklingsprojektet är klart ska överlämning ske till förvaltningsorganisationen. Även detta ska ingå i kravspecifikationen.

Minimum är ett överlämningsmöte mellan utvecklare som med fördel spelas in.

Om förvaltande (mottagande) part är annan än den som utvecklat är överlämningen av stor vikt och det ska planeras in gott om tid för denna samt en period då den förvaltande parten lär känna produkten och kan ställa frågor till den som utvecklat.

10. Utvärdering

I samband med att en ny lösning levereras ska en utvärdering planeras in. När den ska ske beror på vad det är som levererats, men senaste inom ett år rekommenderas.

I utvärderingen går vi tillbaka till förstudien och utvärderar mot t ex effektkarta. De uppsatta KPI:erna och andra mål i utveclingsprojektet är givetvis också centrala.