Iterative application development

Iterative application development (IAD) is een softwareontwikkelmethode die de gebruikers en ontwerpers als gelijkwaardige partners ziet. De I staat voor het ontwikkelen in herhalingen (iteratief), samen met de gebruiker (interactief) en stapsgewijs uitbouwen tot een grotere bruikbaarheid (incrementeel).

In het verleden zijn er meerdere ontwikkelmethoden uitgedacht en in de praktijk beproefd. Methodes moeten ervoor zorgen dat het ontwikkelen van een systeem goed verloopt.

IAD beschrijft een methode waarbij een project in relatief kleine stappen wordt opgedeeld. Deze delen worden onafhankelijk van elkaar ontwikkeld, de tijd die voor de ontwikkeling wordt genomen is afhankelijk van de grootte van het deel, na ontwikkeling is het mogelijk dat het deel direct bruikbaar is. Elk deel is een zogenaamde pilot. Door deze methode toe te passen, wordt het onder meer mogelijk om een groot project door een grote groep mensen uit te voeren. Teams kunnen parallel een pilot ontwikkelen. Tijdens de fase "invoering" worden de pilots samengevoegd tot één bruikbaar product.

De ontwikkelcyclus (een iteratie) bestaat uit drie fasen die op een herhalende manier worden uitgevoerd: definitiestudie, pilot-ontwikkeling en invoering. Elke cyclus levert een pilot op. Dat een pilot een klein gedeelte is, betekent dat het maar een aantal van de totale (en ook mogelijk dan nog onbekende) systeemeisen dekt. Pas in de laatste pilot wordt aan alle systeemeisen voldaan. Na afloop van elke cyclus wordt een bruikbaar resultaat geleverd. Er wordt veelvuldig gecommuniceerd met de gebruikers en de opdrachtgever, of deze nog tevreden zijn, of er nieuwe eisen zijn, of er problemen gezien worden. Dit levert een belangrijk voordeel op: op elk moment kunnen er aanpassingen worden gemaakt, naar de behoefte van de opdrachtgever. Zo wordt getracht tot een optimaal resultaat voor de opdrachtgever te komen.

Er zijn vier verschillende varianten van ontwikkelen. Welke variant geschikt is om te gebruiken hangt af van de organisatie en het eindproduct. Dit is afhankelijk van de complexiteit van het systeem, de stabiliteit van de systeemeisen en het al dan niet aanwezig zijn van de noodzaak tot snelle oplevering.

De verschillende varianten zijn: evolutionair ontwikkelen, incrementeel opleveren, incrementeel ontwikkelen en Big-Bang invoeren.

Bij het toepassen van evolutionair ontwikkelen worden alle drie de fasen iteratief doorlopen. Het systeem wordt stap voor stap ontwikkeld tot het uiteindelijk gewenste resultaat. Wat het resultaat wordt is in het begin vaak nog niet in detail bekend, maar in deze variant evolueert het inzicht daarin mee.

Bij incrementeel opleveren is het de bedoeling dat alle eisen eerst volledig worden beschreven. Daarna wordt het systeem in iteratieve fasen ontwikkeld. De eerste fase definitiestudie wordt dus eenmalig uitgevoerd. Dit in tegenstelling tot evolutionair ontwikkelen, alwaar die fase net zo vaak wordt uitgevoerd als de fasen pilot ontwikkeling en de invoering.

Bij incrementeel ontwikkelen (Rapid Application Development) wordt er vanuitgegaan dat de systeemeisen en het systeemconcept van tevoren zijn beschreven. Hierna wordt het systeem in een aantal iteraties ontwikkeld, waarna het resultaat in één keer wordt ingevoerd.

Bij Big-Bang invoeren wordt het systeem op iteratieve wijze ontwikkeld, net als bij evolutionair ontwikkelen. De invoering vindt echter pas plaats nadat de laatste pilot afgerond is, zoals bij incrementeel ontwikkelen. De eerste twee fasen, het maken van een definitiestudie en het ontwikkelen van pilots, gebeuren iteratief. De laatste fase invoering wordt eenmalig doorlopen.

Door gebruik van IAD zijn een aantal voordelen te behalen. Daar zijn vanzelfsprekend wel voorwaarden voor. IAD steunt bijvoorbeeld sterk op goede participatie van en communicatie tussen ontwikkelaars en gebruikers.

• Er is een grote(re) betrokkenheid van gebruikers en opdrachtgever. Dat leidt ertoe dat misverstanden vanwege verschil van inzicht tussen ontwikkelaars en gebruikers snel uit de weg kunnen worden geruimd. Omdat er sneller een "tastbaar" resultaat is, zullen gebruikers ook makkelijker in staat zijn gerichte(re) eisen te stellen.
• Door snel "tastbare" resultaten te zien zullen gebruikers en opdrachtgever meer vertrouwen krijgen in een goed eindresultaat.
• Doordat na elke doorlopen cyclus een deel van het systeem voor de gebruikers en opdrachtgevers direct te gebruiken is, worden deze nadrukkelijk bij het ontwikkelproces betrokken en wennen zij tijdens de ontwikkeling aan het systeem.
• Risico's kunnen beter worden beheerst doordat kleinere stukken worden ontwikkeld. Knelpunten komen zo snel aan het licht.
• Complexe systemen worden overzichtelijker en eenvoudiger implementeerbaar doordat er stap voor stap naar een totaalresultaat gewerkt wordt, zonder dat daarvoor eerst een compleet ontwerp wordt gemaakt.
• Aan het eind van iedere iteratie ligt er een bruikbaar product, ook als de verdere ontwikkeling wordt stopgezet. Bij een lineaire methode zou er vaak nog niets bruikbaars zijn gemaakt.
• Veranderingen in organisatie kunnen sneller worden opgenomen in het ontwikkeltraject.

Er zijn vanzelfsprekend ook nadelen. Enkele nadelen:

• Doordat gedurende het ontwikkelproces eisen aangepast en verfijnd worden, kan het zijn dat het oorspronkelijke doel vervaagt. Dan kan het gebeuren dat het blijft worden bijgesteld en het nooit af is. Dit is zogenaamde Scope creep.
• Projectmanagers die lineaire ontwikkeling gewend zijn kunnen in verwarring raken door de grote dynamiek.
• Het snelle ontwikkelen heeft de potentie een wissel te trekken op de organisatie en de hulpmiddelen, vanwege de grote dynamiek.
• Onervarenheid met de manier van werken kan leiden tot teleurstellingen en misverstanden.

Zoals al beschreven is wordt bij IAD een aantal activiteiten uitgevoerd. Het werken volgens een iteratieve methode levert een aantal voordelen op.

De complexiteit van het op te lossen probleem vermindert, doordat er altijd enkel een deel van het probleem wordt aangepakt.

Concretere resultaten worden snel opgeleverd. Hierdoor is het eenvoudiger om feedback te krijgen of het oplossen van dringende knelpunten door deze te overleggen.

Doordat na elke doorlopen cirkel het mogelijk is om doelen, eisen, oplossingen en de gevolgde strategie te bespreken en indien nodig aan te passen ontstaat de flexibiliteit dit nodig is een snel veranderende projectomgeving.

Door het te ontwikkelen systeem op te delen in stukken die iteratief een voor een worden ontwikkeld, kan de maximale rendement uit de gepleegde inspanning worden gehaald.

Risico’s kunnen beter worden beheerst doordat de producten na elke iteratie worden beoordeeld.

Het ontwikkelen van een systeem bestaat uit drie fasen; definitiefase, pilotontwikkeling en invoering. Deze fasen worden per pilot een voor een doorlopen wat een deel van het systeem zal worden. Later worden alle delen samengevoegd als één systeem.

In de eerste fase worden de doelen van het te ontwerpen systeem onderzocht en beschreven. Hierin worden ook de beperkingen en randvoorwaarden genoteerd. Wanneer er al een pilot is afgerond wordt de pilot in deze fase geëvalueerd. Deze fase vormt het aanpassen en verder uitdenken van het uiteindelijke systeem een belangrijke inbreng. Bij elke cycli van de ontwikkeling van het systeem wordt het uiteindelijke plan steeds verder uitgewerkt en uitgedetailleerd. Hierdoor wordt de wens hoe het systeem eruit moet zien steeds duidelijker.

Nadat van een pilot duidelijk is hoe deze eruit moet zien wordt er begonnen aan de pilotontwikkeling. Er kan één pilot, of wanneer meerdere pilots parallel worden afgehandeld, meerdere pilots tegelijk worden uitgevoerd. In deze fase vindt de ontwikkeling van het pilotontwikkeling plaats en worden pilotontwerp workshops gehouden.

Tijdens de pilotontwerp workshops wordt er gekeken hoe de globale functionele specificaties van de in aanbouw zijnde pilot eruitzien. Er wordt een prototype gemaakt van het uiteindelijke systeem. Delen van de pilot of pilots worden hierna door één of meerdere ontwikkelteams gebouwd, zogenaamde A-teams. Tijdens deze werkzaamheden is het budget en de tijdsplanning strak gepland en niet veranderbaar. Door ervoor te zorgen dat pilots hergebruikt kunnen worden in andere pilots, is een goed doordachte softwarestructuur nodig. Wanneer dit gerealiseerd is kunnen snel hoogwaardige en aan elkaar afgestemde producten geleverd worden. A-teams zijn kleine groepen goed samenwerkende professionals, die elk hun eigen specialisatie hebben en allemaal in alle fasen van de ontwikkelcycli kunnen werken. Tegengesteld zullen gebruikers die betrokken zijn bij de ontwikkeling opereren in U-teams.

Nadat de pilot in de voorgaande fase is ontwikkeld, zal deze in de fase invoering operationeel worden gemaakt en worden ingevoerd in de organisatie. Om ervoor te zorgen dat de ervaringen die zijn opgedaan met de pilot worden gebruikt in de volgende pilots, moet er worden gezorgd dat er effectief informatie kan worden verzameld en opgeslagen.