Checklist voor een informatief website.

1. Beleidsniveau

   • Doelstelling van de website (vb: informatie verschaffen over bedrijf en nieuwe activiteiten)

   • Welke doelgroepen wil men bereiken: eventuele onderlinge prioriteit vastleggen tussen verschillende doelgroepen die men wil bereiken (Het antwoord iedereen zal niet gaan. Mogelijke antwoorden zijn: Het hoogste prioriteit leegt aan groepen die zullen onze drankautomaten koppen en minder op groep die zal dergelijke automaten gebruiken om een drank te serveren.)

   • Beschikbaar budget: zowel tijd als geld (voor een informatief website 1 dag alleen voor ontwerp is nodig. Doelgerichte teksten, aantrekkelijke foto’s, beter voordien te verzamelen)

   • Hoe is de website geïntegreerd in het totale informatie-en publicatiebeleid van de organisatie: verhouding met andere publicaties, tijdschriften, boeken. Het plaatsen van brochures op het net kan de verkoop van publicaties doen dalen. Het effect van elk informatiemedium moet in overweging worden genomen.

2. Inhoud

   • Tekst: copywriting en redactie.

   • Foto’s (Het best digitale. Gescande afbeeldingen zijn meestal minder goed van kwaliteit)

3. Technische aspecten

   • Hoe moet het eindproduct eruit zien op het scherm (resolutie)? Rekening houden met de kleuren? (Kleuren worden meestal gebruikt van uw al bestaande logo.)

   • Hoe moet de tekst uitgelijnd worden. Moet hij met foto’s gecombineerd worden? Als ja dan in welke volgorde.

   • Hoe gebeurt de navigatie (Niet vergeten! navigatie is een heel belangrijke onderdeel van uw website. Het moet duidelijk zijn met twee of drie klikken moet u iedere pagina van uw website kunnen bereiken vanaf uw home pagina. Meestal voor dergelijke informatief websites wordt een navigatie balk gebruikt van boven als minder dan zeven pagina’s in totaal of van linker kant als zeven en meer)

   • Hoe de feedback of het effect van uw website meten (o.a. ter verantwoording van de investeringen en als signaal voor eventuele wijzigingen, teller)

   • Hoeveel plaats heeft u nodig om uw website op het net te plaatsen.(Wil je bijvoorbeeld video presentaties verspreiden dan moet u meer ruimte hebben dan voor foto’s en tekst)

Checklist voor een informatiesysteem die met website verbonden is

Ojectgeorienteerde analyse

Het doel van analyse als onderdeel van informatiesysteemontwikkeling, is te bepalen wat er precies gebouwd moet worden. Het noodzakelijke voortraject heef in het Unified process de inceptiefase. In deze fase wordt een antwoord gezocht op de volgende vragen.

• Waarom willen we dit systeem: wie zijn de betrokkenen en wat hebben die erbij te winnen?

• Is het systeem haalbaar? (technische aspect. Bestaan nu gelijkaardige systemen of dat een totaal nieuw uitvinding)

• Wat gaan we kopen en wat gaan we zelf bouwen?

• Hoeveel gaat het ongeveer kosten (een zeer ruwe schatting; een goed antwoord zou bijvoorbeeld kunnen zijn: duizenden, maar geen tienduizenden euro’s, of voor een groot project: ‘enkele honderdduizenden’)?

Het antwoorden op deze vragen wordt vastgelegd in een visiedocument. Een dergelijk document kan meer of minder uitgebreid zijn. Een eenvoudig visiedocument heeft de volgende indeling.

1. Inleiding: wat willen we en wat was de aanleiding daarvoor?

2. Wie zijn er bij het systeem betrokken en wat zijn hun doelen?

3. Wie van de betrokkenen zijn toekomstige gebruikers van het systeem en voor welke taken gaan zij het systeem gebruiken?

4. Wat zijn de belangrijkste risico’s die vroeg aangepakt moeten worden?

5. Wat gaan we kopen en/of bouwen en hoeveel tijd en geld gaat dat ongeveer kosten( alleen orde van grootte)?

Dan opstellen van eisen. Er kan een onderscheid gemaakt worden tussen twee soorten eisen aan een systeem, namelijk functionele en niet-functionele.

Functionele eisen betreffen eisen aan de relatie tussen de invoerinformatie en de uitvoerinformatie van het systeem. Functionele eisen beschrijven wat het systeem moet kunnen.

Niet-functionele eisen zijn alle andere eisen aan het systeem. Voorbeelden zijn eisen aan de snelheid, het gebruiksgemak, aan de betrouwbaarheid.

Een beschrijving in gewoon Nederlands of Engels kan daarentegen weer tekortschieten in precisie. Het opstellen van eisen in de vorm van use cases is een techniek die zowel ontwikkelaars als gebruikers zo goed mogelijk wil bedienen. Een use case geeft weer hoe het systeem een bepaalde gebruiker ondersteunt bij het bereiken van een gegeven doel.

VOORBEELD USE CASE

Use case: Drankje serveren

Primaire actor: Gebruiker van drankautomat

Doel: Een drankje uit de automaat halen.

Hoofdsuccesscenario:

1. Gebruiker gooit munt in de gleuf.

2. Automaat telt de waarde van de munt op bij het tegoed en toont het nieuwe tegoed. Stappen 1 en 2 kunnen worden herhaald

3. Gebruiker maakt een keuze voor een drank.

4. Automaat controleert het tegoed.

5. Automaat levert een bekertje uit.

6. Automaat mengt de drank uit de benodigde ingrediënten en laat die in het bekertje lopen.

7. Gebruiker neemt het bekertje uit.

8. Automaat neemt munten in een toont tekst “Werp geld in”.

Uitbreidingen:

1a. De bekertjes zij op:

1.Automaat toont een geschikte melding.

2.Automaat geeft de ingeworpen munt meteen terug via de retourgleuf en de use case wordt afgebroken.

2a. Automaat herkent een ingeworpen munt niet:

1.Automaat geeft de munt meteen terug via de retourgleuf, zonder het tegoed te veranderen.

2b. Gebruiker drukt op retourknop:

1.Automaat geeft gegoed terug; de use case wordt afgebroken.

3a. Een van de benodigde ingrediënten is op:

1.Automaat meldt welk ingrediënt niet beschikbaar is.

2.De use case gaat terug naar stap 3.

4a. Het tegoed is lager dan de prijs van de drank:

1.Automaat meldt dat het tegoed te laag is.

2.De use case gaat terug naar stap 1.

Een manier om concepten op te sporen die een plaats verdienen in het domainmodel, begint met het maken van een lijst van alle zelfstandige naamwoorden die in deze use case voorkomen. We vinden de volgende lijst: drankje, drank, gebruiker, drankautomaat, automaat, munt, gleuf, waarde, tegoed, bekertje, ingrediënten, melding, retourgleuf, retourknop, prijs.

Verder worden diagrammen samen gesteld door analisten of ontwikkelaars. En neemt de plaats over een objectorenteerend ontwerp.

Het enigste waarschuwing die we willen doen. Gebruik geen watervalmethode voor uw ontwerp Dat is een methode waar u bepaalde stappen volgt zoals( analyse->ontwerp->implementatie) Op het einde van de ontwerpfase word een product opgeleverd. Een probleem is dat niet over alle risico’s in een vroeg stadium van het project duidelijkheid kan worden verkregen. Alle onderdelen van een informatie systeem zijn aan elkaar gekoppeld en als een essentieel ding werkt niet zoals het verwacht werd dan kan hele werking verhinderd worden. Tweede probleem te veel onverwachte aanpassingen moet u doen tijdens implementatie soms grote aanpassingen die veel tijd zullen kosten. Als gevolg daarvan een derde probleem is dat vrijwel alle systemen te laat en met overschrijding van het budget worden opgeleverd.

De oplossing voor dergelijke problemen is ITERACTIEF ONTWIKKELEN. Bij een iteratieve ontwikkelmethode wordt het systeem in stappen ontwikkeld. Aan het eind van iedere stap is er een werkend en getest systeem dat in een volgende stap wordt uitgebreid.