Att skapa en webbplats i Content Studio kan vara alltifrån ett väldigt enkelt projekt till ett mycket komplext och omfattande projekt som pågår under flera år. Att skapa en väldigt enkelt webbplats kan ta ett par arbetsdagar för en erfaren CS-utvecklare, och upp till ett år för ett stort komplext uppdrag med många involverade utvecklare. Grunden till en bra webbplats är god planering, struktur och bra kravspecifikationer – att påbörja byggandet utan ritningar, tidplan eller struktur leder ofta till sämre kvalité, lång projekttid eller överskriden utvecklingskostnad.
Denna dokumentation ger inte alla svar på hur ett webbprojekt bör genomföras – istället väljer vi att nämna hur ett klassiskt webbprojekt genomförs.
Från kravspecifikation till webbplats i drift
De flesta projekt börjar med en idé hos kunden. Kunden, dvs ett företag, organisation eller en föreningen, har ett problem/behov de vill lösa, och om detta berör internet/intranät kan ett CMS-verktyg (Webbpubliceringsverktyg) bli aktuellt. I ideala fall har kunden tagit fram en förstudie som undersöker problemet/behovet, och redovisar detta i en förstudierapport. Utifrån denna rapport tas en kravspecifikation fram. Kravspecifikationen beskriver hur problemet/behovet ser ut, hur det bör lösas och på vilket sätt. Kravspecifikationen tas oftast fram av kunden själv, men ibland är externa konsulter/resurser involverade.
Ibland är kravspecifikationerna väldigt ytliga och ibland väldigt omfattande och detaljerade. Beroende på kundens budget, projektets komplexitet, kundens önskan att vara involverad i utvecklingsarbetet samt många andra faktorer, kan det finnas både fördelar och nackdelar med en detaljerad kravspecifikation. Rent generellt är det dock oftast bättre med en mer detaljerad kravspecifikation eftersom detta troligen återspeglar en mer genomtänkt behovsbild. Kunden har helt enkelt tänkt igenom problematiken mer.
I många fall sker någon slags upphandling eller urval av leverantörer som kan leverera en lösning för kunden. Upphandlingen kan vara riktad, öppen eller utformas på andra sätt. I denna typ av upphandlingar förekommer ofta Content Studio som en möjlig produkt. I upphandlingen används ofta kravspecifikationen som underlag.
Om Content Studio väljs som publiceringsverktyg påbörjas ett projekt som ofta följer en förlopp enligt nedanstående exempel.
- Upprättande av styrgrupp och projektgrupp
- Uppstartsmöte med projektgrupp
- Workshop och riskanalys
- Fördjupning i kravspecifikation
- Eventuell justering av projetbudget eller tidplan
- Framtagning grafisk form
- Framtagning CSS-strategi
- Framtagning HTML-dummy
- Tillgänglighetstest av HTML-dummy
- Framtagning av informationsstruktur
- Servrar förbereds för installation (Windows 2003 Server samt SQL Server)
- Content Studio installeras hos kund eller hos hostingpartner
- Fjärraccess upprättas för kund och utvecklare
- CSS och grafisk form implementeras i Content Studio
- Funktionalitet byggs enligt kravspecifikation
- Test av funktionalitet, eventuellt av tredjepart
- Test av tillgänglighet, eventuellt av tredjeart
- Utbildning av skribenter och redaktörer
- Utbildning av administratörer och/eller superusers
- Utbildning av eventuella webbutvecklare hos kunden
- Dokumentation av leverans
- Acceptanstestperiod, i vanliga fall 30 dagar
- Överföring av material från gammal webbplats
- Övertagande/leveransgodkännande
- Driftsättning och publicering av ny webbplats
Naturligtvis finns det oändligt många varianter på hur ett webbprojekt genomförs. Ovanstående exempel skall ses som en skiss över hur ett projekt kan genomförs. Vad som passar just er beror på webbprojektets karaktär, omfattning, komplexitet, er kompetens, val av projektmodel, val av utvecklingsmodell och många andra faktorer.
Vanliga fallgropar och problem
Under åren har ett stort antal webbprojekt genomförts med Content Studio som grundplattform. De flesta projekt kan anseas vara lyckade - funktionellt och ekonomiskt. I projekten har dock ibland vissa problem uppstått – allt från små problem till mer omfattande och komplexa problem som försent eller fördyrat projektet. Alla inblandade i projekt vill undvika problem, stora som små, varför vi ska här försöka belysa de vanligaste fallgroparna och problemen (ingen speciell ordning):
- Kravspecikationen är för otydlig eller ytlig – vad ska byggas?
- Kravspecikationen är svår att förstå – vad ska byggas?
- Kunden har inte kompetens att ta fram en kravspecifikation
- Det saknas designskisser som beskriver hur funktionen skall implementeras i det grafiska gränssnittet
- Tidplanen är för kort vilket innebär att många resurser behöver arbeta parallellt – detta är mer komplext och dyrbart än att arbeta inom en längre tidplan.
- Kunden har inte tillräckligt mycket resurser för att arbeta med krav och test.
- Projektmöten och beslut i projektet dokumenteras ej.
- Den grafiska formen är svårt att implementera på ett tillgängligt sätt
- Krav förändras under projektets gång och riskerar fördyra projektet
- Att implementera en bra och överskådlig CSS är ofta mer komplext än vad man anar
- Tidsuppskattningarna har inte tagit höjd för test, dokumentation eller projektledning
- Projektet har inte tillräcklig intern förankring hos kunden vilket skapar irritation eller förvirring i projektets slut.
- IT-avdelning och informationsavdelning hos kund är inte synkroniserade och kan ha olika uppfattningar och prioriteringar.
- Kunden har svårt att göra val som påverkar IT-säkerhet vs funktionalitet.
- Kunden har svårt att prioritera ned/bort funktioner i ett läge när budgeten spruckigt av någon orsak
- Servern har för låg kapacitet mot den belastning som uppstår
- Den SQL Server som används av webbplatsen används även av andra applikationer vilket genererar en ojämn prestanda för webbplatsen.
- Den SQL Server som används av webbplatsen har felaktig sorteringsordning
- Active Directory hos kunden är inte organiserat på ett bra sätt vilket försvårar konfiguration av grupper/roller för redaktörer, skribenter och administratörer.
- Cacheteknik används inte på webbplatsen – prestandan blir för dålig.
- Belastningstest genomförs inte – webbplatsen kan inte hantera den trafikvolym som genereras efter driftsättning.
- Kunden vill att redaktörer ska börja jobba med innehåll innan webbplatsen är färdigbyggd – detta försvårar och fördyrar projektet eftersom processen blir mer komplex.
- Integration med externa system kan vara mer komplexa än man anar
- ”Standard” innebär inte alltid att systemen är kompatibla
- Driftsatt webbplats säkerhetskopieras inte
Erfarenheterna från webbprojekt varierar naturligtvis från organisation till organisation. Vilka problem som uppstår skiljer sig och det är svårt att ta fram ett ”facit” för alla typer av webbprojekt. Vi hoppas dock att ovanstående lista med klassiska fallgropar påminner om det faktum att det finns risker, problem och svårigheter i stort sett alla projekt. Det gäller att vara medveten om dem och att hantera dem på rätt sätt.