Joint application development

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

Joint application development (JAD) is een techniek die het mogelijk maakt om ontwikkelaars, het management en de klant(en) samen te laten werken om zo een systeem te bouwen. De methode is bedoeld om ontwikkelaars en gebruikers van verschillende achtergronden samen te brengen in een creatieve en productieve omgeving.

Geschiedenis[bewerken]

De methode JAD is ontwikkeld in de late jaren '70 door Chuck Morris en Tony Crawford van IBM. In de jaren '80 won de methode aan populariteit en begonnen steeds meer bedrijven deze toe te passen. Naarmate de methode steeds meer gebruikt werd, werd de term "JAD" vaak gebruikt om steeds andere trajecten te beschrijven. Vaak werd maar één enkel aspect van de methode gebruikt, deze werd dan verder uitgewerkt, maar het werd nog steeds "JAD" genoemd. Naar de originele methode wordt nog steeds verwezen als "classic JAD".

Opzet methode[bewerken]

Ondanks dat er veel verschillende definities zijn van JAD, hebben ze allen een aantal dingen gemeen. De methode is gebaseerd op JAD-sessies. Hierbij komen de volgende aspecten terug:

  • Betrek alle "stakeholders", iedereen die belang heeft bij het systeem en er op één of andere manier mee te maken krijgt.
  • Het JAD-team moet gesteund worden door het hogere management. Het management moet hoog genoeg in de organisatie zitten om de autoriteit te hebben om beslissingen te nemen en de nodige bronnen en ondersteuning voor het project te kunnen leveren.
  • Het is essentieel om een persoon in de projectgroep te hebben welke de "taal" spreekt van de klant en ontwikkelaar. Dit komt ten goede van het ontwikkelproces.
  • Tijdens de sessie mogen personeelsleden of specialisten aanwezig zijn om gedetailleerde vragen te kunnen beantwoorden.
  • De gebruikers bepalen de snelheid waarmee het project verloopt. Sessies worden gehouden op initiatief van gebruiker, maar het is aanbevolen om wekelijks een evaluatie sessie te houden.
  • Elke sessie moet ongeveer 2 uur duren. Wanneer het project versneld moet worden afgerond is het mogelijk om een sessie 4 uur te laten duren. Houdt rekening met het feit dat de effectiviteit van de sessie daalt na 2 uur.

De volgende personen dienen aanwezig te zijn bij een JAD-sessie[bewerken]

  • Projectleider; Over het algemeen beantwoordt de projectleider van het ontwikkelteam vragen over het project betreffende de scope, tijd, coördinatie en benodigde bronnen. De projectleider kan meedoen met een sessie zolang zij de overige participanten niet dwarszitten
  • Sessieleider; Deze persoon leidt de sessie en zorgt dat alle agendapunten aan de orde komen. De sessieleider is verantwoordelijk voor het identificeren van de aandachtspunten die moeten worden opgelost tijdens sessie.
  • Opdrachtgever; Dit kan een afgevaardigde zijn van de stakeholders. Zoals eerder gezegd moet deze persoon hoog genoeg in de organisatie zitten om bepaalde beslissingen te kunnen nemen.
  • Notulist; Deze persoon noteert de voortgang van de sessie. Deze draagt niet bij aan de inhoud van de sessie.
  • Gebruikers; Deze personen moeten direct of indirect te maken krijgen met het systeem. Ze moeten over kennis beschikken over hun dagelijkse bezigheden en deze overdragen op het ontwikkelteam.
  • Observeerders; Dit zijn vaak leden van het ontwikkelteam en moeten de voortgang van de sessie observeren.

Taken[bewerken]

  • Identificeer de stakeholder / opdrachtgevers.
  • Identificeer de requirements (vereisten).
  • "Verzoen" de verschillende perspectieven van alle gebruikers tot één enkele samenvatting van de vereisten.
  • Definieer de interactie / wisselwerking tussen de gebruikers, andere systemen en de organisatie.
  • Definieer de wijze waarop gebruikers gebruikmaken van het systeem, door middel van "usecases".
  • Prioriteer de usecases door te kijken wat de gebruikers het meest belangrijk vinden en wat welke het meest kritiek is voor het functioneren van het systeem.
  • Valideer de usecase scenario's.
  • Organiseer de usecases, beperkingen, aannames en andere vereisten in de "Software Requirements Specification" (SRS).
  • Ontwerp de benodigde userinterfaces en rapporten.

Richtlijnen voor succesvol JAD[bewerken]

Niet alle JAD-sessies verlopen succesvol, sommige verlopen zelfs rampzalig. Daarom zijn er een aantal richtlijnen opgesteld gebaseerd op onderzoeksresultaten en persoonlijke ervaringen. Deze worden gegeven om mislukkingen te voorkomen. Deze richtlijnen vertegenwoordigen de kritische succesfactoren en dienen nauwkeurig gevolgd te worden. De richtlijnen staan hieronder samengevat:

  • Gebruik ervaren en bekwame gespreksleiders.
  • Zorg voor steun van het hogere management.
  • Zorg ervoor dat de juiste personen deelnemen, baken vooraf hun rollen en verantwoordelijkheden af.
  • Stel helder gedefinieerde, goed te begrijpen en haalbare doelen.
  • Stel een gedetailleerde agenda op en houd hieraan vast.
  • Definieer vooraf duidelijk welke producten opgeleverd dienen te worden.
  • Probeer zo min mogelijk technisch jargon te gebruiken.
  • Zorg dat het einddocument zo snel mogelijk wordt opgeleverd.

De belangrijkste taak voor een gespreksleider is het goed voor bereiden van een JAD-sessie. Er zijn vijf fasen die correct uitgevoerd moeten worden om een JAD-sessie succesvol te laten verlopen, van deze vijf fasen zijn er drie “pre-session”. Deze vijf fasen zijn:

  • JAD-projectdefinitie.
  • Onderzoek naar gebruikersvereisten.
  • Voorbereiding voor de JAD-sessie.
  • Het leiden en ondersteunen van de JAD-sessie zelf.
  • Het voorspellen en verkrijgen van goedkeuring van het einddocument dat alle genomen besluiten bevat.

Als al deze vijf fasen correct worden uitgevoerd, zal de JAD-sessie succesvol zijn. Geen van deze fasen mag in principe worden weggelaten.

Voor- en nadelen[bewerken]

Voordelen[bewerken]

  • Kortere ontwikkeltijd; Bij JAD wordt sneller informatie ingewonnen door alle gebruikers en stakeholders te betrekken bij de ontwikkeling. Aangetoond is dat JAD de ontwikkeltijd verkort met 20% tot 50%.
  • Verhoogde kwaliteit van het ontwikkelde systeem; De kwaliteit van het systeem hangt sterk af de verzamelde requirements (vereisten/kenmerken). Bij JAD worden gebruikers en stakeholders betrokken bij de ontwikkeling, deze definiëren de requirements. Hiermee verzekert men zich van het feit dat het systeem tegemoet komt aan eisen van alle stakeholders/gebruikers.
  • Lagere systeemkosten; De meeste kosten bij systeemontwikkeling zijn kosten op het gebied van man-uren van systeemontwikkelaars en zakelijke gebruikers. De verminderde ontwikkeltijd drukt de loonkosten van ontwikkelaars evenals gebruikers.
  • Verbeterde communicatie en relatie tussen zakelijke eindgebruikers en IT-personeel.
  • Bevordert de bijdrage en participatie van gebruikers, omdat ze betrokken worden bij het ontwikkelproces.
  • Verbeterde informatievoorziening voor deelnemers en observatoren. Door deel te nemen aan JAD zullen eindgebruikers volledig geïnformeerd blijven over de voortgang van de systeemontwikkeling.

Nadelen[bewerken]

  • Ten opzichte van andere ontwikkelmethoden is JAD redelijk duur.
  • JAD-sessies kunnen log en onhandig zijn wanneer gewerkt wordt met een te grote groep.

Conclusie[bewerken]

JAD is een nuttig proces om veel informatie en adviezen / opinies te verzamelen. De definitie van JAD blijft constant veranderen doordat de methode steeds meer gebruikt wordt. Hoewel verschillende gebruikers een verschillend beeld hebben van JAD, is de essentie van JAD steeds hetzelfde. Namelijk het houden van sessies onder leiding van een “facilitator”. De basis componenten van JAD worden erkend door JAD-professionals. Zij verstrekken ook een aantal richtlijnen voor het leiden van JAD-sessies. Het volgen van deze richtlijnen kan de kans op succes aanzienlijk verhogen.

Bron[bewerken]

http://www.umsl.edu/~sauter/analysis/JAD.html