Home » Business, Techniek

Websites op maat in het watervalmodel: Analysefase

Geschreven door Bart Lelieveld (Liones) op woensdag 4 november 20097 reacties
Websites op maat in het watervalmodel: Analysefase

Dit is het tweede artikel in een reeks artikelen over het tot stand komen van een maatwerk-website. De reeks artikelen volgt de fasering van het watervalmodel. Per fase wordt een omschrijving van de acties, de deliverables en de valkuilen gegeven. De eerste fase is de Analysefase. Een zeer belangrijke fase, maar te vaak onderschat. Het doel van deze fase is het verzamelen van zoveel mogelijk relevante informatie voor het tot stand komen van de site.

Het proces is als volgt gefaseerd:

Businesscase / Verdienmodel

‘We willen een nieuwe website waar we geld mee gaan verdienen’. Een mooi uitgangspunt, maar hoe ga je dat bereiken? Het opstellen van een heldere businesscase is ontzettend lastig, maar dwing jezelf om erover na te denken en er een op papier te zetten. Zorg dat je site (indien van toepassing) een duidelijk verdienmodel heeft. De investering moet uiteindelijk gerechtvaardigd zijn. Welk doel dient de site, welke doelgroep wil je gaan bereiken of bedienen, en hoe denk je dat dan te gaan doen? Neem ook het onderhoud van de website mee in je business case. Lastige vragen maar key voor het succes van de site.

Lukt dit niet goed, win dan advies in. Should all else fail, zet dan minimaal het beoogde aantal bezoekers en pageviews op papier, zodat er in ieder geval een doel is om naartoe te werken. Meet na verloop van tijd in hoeverre je resultaten zijn bereikt (bijvoorbeeld met Google Analytics).

Scope

Vaak hebben mensen al een idee van hoe de site eruit moet komen te zien of welke functionaliteit er in grote lijnen in moet zitten. In deze fase volstaat het om in grote lijnen een lijst te maken van gewenste functionaliteit. Prioriteer deze waar mogelijk. Laat je indien nodig adviseren door een Business Consultant zodat je voorkomt dat je zelf het wiel opnieuw uitvindt. Er zijn zoveel sites en reeds bestaande modules dat de kans groot is dat een deel van je idee al bestaat en opnieuw gebruikt kan worden !

Binnen de scope van maatwerksites vallen vaak ook complexere onderdelen die grofweg te verdelen zijn in 3 categorieën:

  • Koppelingen
  • Content
  • Workflow

Identificeer vooraf met welke belangrijke systemen de applicatie gekoppeld moet worden binnen de organisatie. Denk na over de content die op de site moet, is deze voldoende verrijkt (gemetadateerd) ten behoeve van SEO of het ontsluiten van de content? Kan de content worden geïmporteerd of moet dit handmatig? Daarnaast zijn er vaak workflows (logische paden, denk bv aan een bestelproces) binnen een applicatie nodig. Genoemde onderdelen zijn vaak een stuk complexer dan het simpelweg bouwen van een site en dienen daarom (in de volgende fase : de ontwerpfase) goed in kaart gebracht te worden, dus het loont om deze (vaak niet direct zichtbare) hindernissen vroeg boven tafel te krijgen.

Planning

De planning is natuurlijk grotendeels afhankelijk van de omvang van het project. De uitdaging is om al vroeg een realistische planning op te stellen. Een voorbeeld: een planning waarin het ontwerp twee maanden mag duren maar de site binnen een maand gerealiseerd, getest en gevuld moet zijn is niet realistisch. De doorlooptijd van een kwalitatief goede site van gemiddelde omvang (30K-60K) is al gauw 2-4 maanden. Vaak helpt het om terug te rekenen vanaf de deadline. Houd hierbij de bovengenoemde fasering aan. Houd bij de acceptatie- en lanceerfase rekening met het feit dat wanneer een applicatie eindelijk is opgeleverd , er ook content in geplaatst moet worden. Vaak een tijdrovende klus die over het hoofd wordt gezien of wordt onderschat.

Organisatie

Het gebeurt helaas soms dat een website wordt opgeleverd maar dat er geen mensen zijn die de tijd hebben om de site te beheren. Vaak wordt het webmasterschap bij mensen die al een volledige dagtaak hebben erbij gefrommeld. Dit is funest voor de site. Zorg dat er mensen aanwezig zijn binnen de organisatie die kennis van zaken hebben, en dus weten hoe de website en het contentmanagementsysteem werken, kennis hebben van bijvoorbeeld Analytics en Adwords en overall ‘internet-minded’ zijn. Het actueel houden van content is wederom een succesfactor van de site, evenals het schrijven voor Google!

Techniek

Als er eisen zijn die vooraf aan de techniek gesteld worden, breng deze dan in kaart. Denk hierbij aan het te gebruiken besturingssysteem of de te gebruiken programmeertaal. Waar wordt er gehost, intern of extern? Zijn er bepaalde eisen die de ICT-organisatie stelt aan de applicatie of de beveiliging?

Tot slot

Het loont om over bovenstaande zaken vooraf goed na te denken en het geheel samen te vatten in een document. We noemen dit ook wel het requirementsdocument (een parallel naar projectmanagement voor de Prince II-ers onder u, ik vergelijk dit document vaak met een PID). Er mag van een professionele bouwclub verwacht worden dat zij meedenken over bovengenoemde punten om de website tot een succes te maken!

Organisaties die een maatwerk-website willen bouwen hebben vaak moeite met het in kaart brengen van bovenstaande gegevens. Hierdoor is het lastig om een ontwikkelpartij goed te briefen over de te maken website en ontstaan vaak al vroeg in het proces onduidelijkheden die kunnen leiden tot ontevredenheid.

Een Business Consultant kan hier een belangrijke rol vervullen. Deze kan op alle punten adviseren en stelt samen met met u de requirements op zodat men goed beslagen ten ijs komt bij het benaderen van een leverancier  voor het realiseren van de website.

In het volgende artikel: de ontwerpfase. Stay tuned!

Gerelateerde berichten:

  • Facebook
  • LinkedIn
  • Twitter
  • Hyves
  • NuJIJ
  • email
  • Print

Trefwoorden: , , , , , , , , , , , , , ,

Bart Lelieveld is werkzaam als Manager Bouw bij Liones, internetbureau voor uitgevers. Als programmamanager overziet hij alle projecten binnen Liones, en is hij verantwoordelijk voor de dagelijkse operatie en het procesmanagement. Daarnaast is hij werkzaam als Senior projectleider en Business Analist.
Bekijk meer berichten van Bart Lelieveld

7 reacties »

  • Marco schreef:

    Is de watervalmethode niet een beetje gedateerd? Er zijn veel meer ontwikkelmethodes die je zou kunnen hanteren.

  • Bart Lelieveld (author) schreef:

    Hi Marco,

    allereerst dank voor jouw reactie. Het klopt dat het een ouder model is. Wiki beweert zelfs uit 1970. Ik ben er echter van overtuigd dat het een prima methodiek is om een website of webapplicatie in de lucht te brengen. Wij hebben hem zelf namelijk helemaal geoptimaliseerd zodat we binnen planning en budget opleveren en een kwalitatief goed product neer zetten.

    Natuurlijk zijn er zijn legio methodieken die gehanteerd kunnen worden. We zijn bekend met Scrum, RUP, DSDM, Extreme en Agile programming, maar toch blijf \ik terugkomen bij deze vertrouwde methode. Welke methodiek heeft jouw voorkeur?

  • Websites op maat in het watermodel: ontwerpfase | Publishr schreef:

    [...] over het tot stand komen van een maatwerk-website. Een introductie en het artikel over de Analysefase gingen hier reeds aan vooraf. Per fase wordt een omschrijving van de acties, de deliverables en de [...]

  • Lenard Kaptein schreef:

    Bart,
    Naar mijn mening en ervaring is de waterval als basis voor website ontwikkeling helemaal geen slechte; eenvoudig te begrijpen en te beheersen. Belangrijk is m.i. dat je als leverancier of projectmanager (analoog aan situationeel leiding geven) tijdig weet te onderkennen wanneer je moet kiezen voor een andere benadering/methode. In de praktijk zie je m.i. ook dat “waterval projecten” agile achtige uitstapjes kennen of andersom.
    Op het moment doe ik de eindfase van een portal project bij AEGON waarbij ik vooral omdat er diverse webservices geimplementeerd moeten worden dagelijks betreur dat er niet strak volgens een “V” of “Dual V” model ontwikkeld is. Aan de andere kant had de eindgebruikers interface beter op een agile manier benaderd kunnen worden.
    Vooral de laatste maanden heb ik gekozen om scrum en agile technieken te gebruiken: sprint concept van scrum om in 4-6 weken de laatste “build” te maken. Agile om de laatste RFC´s met de ontwikkelaar achter het scherm te implementeren. Ik leg deze keuzen niet voor aan opdrachtgever of team als: zullen we nu maar eens gaan “scrummen”? maar stel ze het concept van de sprint voor als manier om sneller en interactiever met een oplevering te komen.

    Mijn motto: Kies niet dogmatisch voor één methode maar kies voor een basis methode en pas die aan afhankelijk van de omstandigheden en ontwikkelingen.

  • Bart Lelieveld schreef:

    Beste Lenard, bedankt voor je reactie!

    Ik denk ook dat sommige projecten zeker gebaat kunnen zijn met een dergelijke aanpak, of dat het zinnig kan zijn om bepaalde onderdelen op die manier aan te vliegen. Dit zijn mijns inziens vaak projecten met een hogere ‘R&D’- factor. Als je vooraf niet weet wat er gebouwd moet worden en geen ontwerpen kunt maken, dan kan Scrum / Agile een optie zijn.

    Scrum / Agile development stellen ook wel echt eisen aan de betrokkenheid van de opdrachtgever in het project. Deze is budgethouder en bepaalt welke functionaliteit er gebouwd gaat worden of niet. Als je expert bent in het bouwen van sites en applicaties durf ik echter ook wel te beweren dat een goed ontwerp vooraf toch een strak project oplevert en dat je niet perse scrum / agile aan de slag moet…wellicht was dit niet mogelijk bij AEGON dat weet ik natuurlijk niet..maar het implementeren van goed gedocumenteerde webservices zou toch niet heel spannend moeten zijn??

    Kun je aangeven waarom je betreurt dat er niet met een V-model is gewerkt? ik ben erg benieuwd naar de problemen die je bent tegengekomen die je binnen het watervalmodel niet goed hebt kunnen oplossen.

    PS: Mijn ervaring met Scrum / Agile is dat op het eind van het project de kwaliteit te wensen overlaat (beheersbaarheid,onderhoud,doorontwikkeling, architectuur etc) en dat de klant keuzes heeft moeten maken in welke functionaliteit hij laat vallen (en dus uiteindelijk niet alles heeft).

    Wat is jouw ervaring hiermee?

  • Watervalmodel: Functioneel ontwerp | Publishr schreef:

    [...] een reeks over het tot stand komen van een maatwerk-website. Een introductie en een artikel over de analysefase en ontwerpfase gingen hieraan vooraf. In dit artikel wordt besproken wat er in een functioneel [...]

  • De top 100 best gelezen artikelen aller tijden van weblog Publishr.nl schreef:

    [...] Websites op maat in het watervalmodel: Analysefase [...]

Laat een reactie achter!

Voeg je reactie toe of maak een trackback vanaf je eigen site.

U kunt gebruik maken van de volgende tags:
<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Deze website maakt gebruik van Gravatar avatars. Voor uw eigen Gravatar avatar kunt u registreren op Gravatar.