Processen in Softwareontwikkeling

Er zijn veel ontwikkelmethodes voor het realiseren van software. Op de pagina softwareontwikkel-methoden worden deze toegelicht. Al deze methoden geven een eigen invulling aan het voortbrengingsproces van de softwareontwikkeling en de aansturing daarvan. Toch maakt elke methodiek, in welke vorm dan ook, gebruik van onderstaande processen:  

a  Specificeren

b  Definitiestudie

c  Ontwerpen

d  Programmeren

e  Testen

f   Accepteren

De ontwikkelmethoden hebben overeen dat onderstaande ontwikkelprocessen, in welke vorm dan ook, terugkomen. Bij elke ontwikkelmethode moet de klant zijn wens specificeren en zullen opgeleverde (deel)systemen getest moeten worden. Hieronder wordt verder ingegaan op een aantal karakteristieken (processen) van het ontwikkelproces

 

a  Specificeren

De eerste fase binnen systeemontwikkeling is het opstellen van de eisen waaraan de geautomatiseerde systemen moeten voldoen. Het lijnmanagement beschikt vaak echter over onvoldoende kennis om te bepalen welke eisen dit nu zijn. Op basis van de ISO indeling van hardware- & softwarekwaliteit onderkent House of Control een aantal eigenschappen van een geautomatiseerd systeem (Samenvatting ICT-kwaliteitseisen ). Die kunt u vervolgens vertalen naar uw eigen situatie en vastleggen in een Programma van Eisen (c.q. requirements of specificaties). Eisen met betrekking tot:

• Functionaliteit: eisen die u stelt aan de software om de processen binnen uw organisatie goed te ondersteunen. De business bepaalt bijvoorbeeld of er een digitaal klantdossier komt en welke gegevens daarin worden opgenomen.
• Onderhoudbaarheid: hoe makkelijk is het om wijzigingen in uw systemen door te voeren? Hoe makkelijk is het om een extra gegeven in het elektronisch klantdossier op te nemen?
• Portabiliteit: hoe makkelijk moet het zijn om software van bijvoorbeeld de testomgeving naar de productieomgeving over te zetten?
• Betrouwbaarheid: onder welke omstandigheden moet het prestatieniveau gehandhaafd blijven? Hoe vaak mag ‘het systeem’ eruit liggen? En hoe lang mag het maximaal duren voordat het systeem weer operationeel is?
• Gebruikersvriendelijkheid: welke eisen stellen we aan de hardware en software om het de gebruikers gemakkelijk te maken? Is het makkelijk om wijzigingen in het klantdossier door te voeren? Worden de gegevens op een logische manier op het computerscherm gepresenteerd?
• Efficiency: Wat is de relatie tussen de investeringen die u doet en het prestatieniveau van de hardware en software?

b  Definitiestudie

Is een onderzoek naar de impact en haalbaarheid van mogelijke oplossingsrichtingen. Een definitiestudie wordt uitgevoerd als er onzekerheid bestaat over de impact en haalbaarheid van het PvE. Op basis van de Definitiestudie wordt samen met de opdrachtgever besloten voor welke oplossingsrichting wordt gekozen. Om de haalbaarheid van een oplossingsrichting te bepalen, kan men de volgende vragen als leidraad hanteren:

• Is de oplossingsrichting mogelijk en zinvol?; is de huidige programmatuur toe aan vervanging? Is er voldoende kennis en manuren beschikbaar om de gewenste oplossing te realiseren? Hoe groot is het budget? 
• Is de oplossing technisch haalbaar?; wanneer men eisen gaat stellen, waaraan de hardware (bijvoorbeeld de processor) niet kan voldoen, kan met behulp van het systeem ook niet aan de eis worden voldaan.
• Is de oplossing economisch verantwoord?; indien de kosten, die gemaakt worden met het ontwikkelen en beheren van het systeem, groter zijn dan de winst die ermee wordt behaald, dan is het financieel gezien niet verstandig om te ontwikkelen.
• Is het nieuwe systeem organisatorisch inpasbaar?; de mensen, die binnen de organisatie werken, moeten met het toekomstige systeem kunnen werken. Veelal wordt hier het begrip COPAFIJTH-BI gebruikt. Dat wil zeggen dat de oplossing getoetst moet worden op alle bedrijfsvoeringsaspecten zoals Communicatie, Organisatie, Personeel, etc..

De Definitiestudie moet in ieder geval bevatten: een systeemconcept met de hoofdfuncties van het systeem. Hier staat in welke onderdelen van het betreffende bedrijfsproces geautomatiseerd worden en welke handmatig worden uitgevoerd. En een totaalplan met kosten/batenanalyse. Hierin wordt beschreven hoe men het systeem gaat bouwen, met welke voorwaarden en welke kosten eraan verbonden zijn.

c  Ontwerpen

Op basis van het programma van eisen (en eventueel een definitiestudie) wordt het ontwerp gemaakt. Ontwerpen is het inrichten van de gekozen oplossingsrichting. De in het Programma van Eisen vastgestelde hoofdfuncties worden verder uitgewerkt in een functioneel- en technisch ontwerp. 

• Functioneel Ontwerp; in het Functioneel- of Globaal ontwerp wordt beschreven wat het systeem zal doen. Hiervoor wordt onderzocht wat de relatie is met andere systemen, welke functies de andere systemen hebben en welke gegevensuitwisseling er is. De mijlpaalproducten voor deze fase zijn:
  • Bepaling basisfunctiestructuur; wat worden de (nieuwe) functies van het systeem. Hier wordt dus exact aangegeven welke onderdelen van het proces geautomatiseerd worden. Ook wordt precies aangegeven uit welke subsystemen het toekomstige systeem zal bestaan. Na het vaststellen van de subsystemen wordt er per onderdeel de systeemeisen opgesteld.
  • Bepaling basisgegevensstructuur; met welke gegevens wordt in het nieuwe systeem gewerkt, hoe worden de gegevens omgezet van het oude naar het nieuwe systeem.
  • Bepaling technische systeemstructuur; hoe gaat het systeem er technisch uitzien? Welke apparatuur, programmatuur, bestandsstructuur wordt er gebruikt. De koppeling en interfaces met andere systemen worden ook beschreven.

• Technisch Ontwerp; het technisch- of detailontwerp borduurt verder op het functioneel ontwerp. Dit wordt gedaan door specifieker te beschrijven wat elk onderdeel van het systeem doet. Tevens legt men in deze fase vast hoe de beschreven onderdelen gerealiseerd worden. De mijlpaalproducten voor deze fase zijn:
  • Rapport functioneel ontwerp; dit rapport bestaat uit een volledige beschrijving van de functies, van de gegevensstructuur en van de mens/machine interface (welke invoer moet door het nieuwe systeem worden verwerkt en welke uitvoer geproduceerd).
  • Rapport technisch ontwerp; hierin staan zaken als beschrijving van de formulieren en procedures (welke documenten worden gebruikt, hoe ziet de randapparatuur eruit), beeldschermbeschrijvingen (interfaces), opslagstructuur en uit welke hardwarecomponenten zal het nieuwe systeem bestaan (specificatie componenten).
  • Plan voor systeemtest; dit is een gedetailleerd testplan, waarin opgenomen is op welke manier getest wordt, hoe de test eruit zal zien, wie de test uit zal voeren, wie besluit of de test met goed gevolg is afgerond, welke gegevens worden gebruikt (testcriteria en testgevallen) etc.
  • Plan voor acceptatietest; deze test is soortgelijk aan de systeemtest, alleen is deze test bedoeld voor de gebruiker c.q. opdrachtgever. Op basis van een (gebruikers)acceptatietest kan de opdrachtgever het systeem wel of niet accepteren.  

d  Programmeren

op basis van het programma van eisen en het ontwerp wordt het computerprogramma daadwerkelijk geschreven c.q. gebouwd. Feitelijk is dat niks anders dan het schrijven van een verzameling van instructies die de computer moet uitvoeren. Deze verzameling van instructies ten behoeve van een specifiek doel noemen we software of een (computer)programma. Op basis van het programma van eisen en het ontwerp kan een computerprogramma daadwerkelijk worden geschreven. Dit is de taak van een softwareontwikkelaar of programmeur. Hieronder worden een aantal karakteristieken van programmeren toegelicht:

• Omvang; de omvang van programmeerwerk verschilt sterk. Veel programma's bestaan uit enkele regels broncode, die na eenmalig gebruik worden afgedankt. Denk daarbij bijvoorbeeld aan een opdracht (c.q. programma) om een specifiek op de omstandigheden afgestemde rapportage te draaien. Maar er zijn ook programma's met miljoenen regels broncode, die gedurende tientallen jaren worden gebruikt. De omvang van een programma wordt uitgedrukt in het aantal functiepunten.
• Aard van toepassing; ook de aard van het programmeren kan sterk uiteenlopen: verschillende soorten toepassingen vereisen verschillende soorten programmeertalen. Zo zal een grafisch programma zaken als venster, tekstblok, invulbaar tekstblok, indrukbare knop gebruiken terwijl een programma voor statistische berekeningen ondersteuning zal bevatten voor bijvoorbeeld variantie en exponentiële distributie.
• Programmeertalen; soms is een gegeven programmeertaal minder geschikt voor het schrijven van specifieke software. Dit omdat de taal niet aansluit op de specifieke functionaliteit die wordt geschreven. Programmeertalen voor grafische programma's voldoen niet voor programma's met statistische karakteristieken. Dan leidt dit  vaak tot het ontwikkelen van nieuwe talen. Er bestaan dan ook duizenden verschillende programmeertalen.
• Platform; gezien het groot aantal verschillende programmeertalen zijn professionele softwareontwikkelaars gespecialiseerd in bepaalde talen en bepaalde soorten toepassingen. En een aantal van deze talen zijn tot een standaard verheven. In dat geval wordt gesproken over een ontwikkelstraat of een platform. Bekende voorbeelden daarvan zijn: Java, .NET, Linux en Windows.

Een programma-code is goed als deze herbruikbaar, robuust, uitbreidbaar en verstaanbaar is. Dit zijn dan ook de belangrijke criteria voor softwarespecialisten om de kwaliteit van een bepaalde programma-code te beoordelen.  

Programmeertalen

Een programmeertaal is een formele taal waarin de opdrachten die een computer moet uitvoeren, worden geschreven. De meest basale vorm van programmeren, de machinetaal, vindt in enen en nullen plaats. Programma’s die zijn geschreven in enen en nullen zijn echter lastig te onderhouden. Om programmeren makkelijker te maken, zijn daarna andere programmeertalen, de zogenaamde hogere programmeertalen ontwikkeld. Hoe hoger de orde, hoe verder de taal van de machine-instructies af staat. Programmeertalen worden ook wel onderverdeeld in generaties:

• Eerste generatie: programmeren vindt plaats door computers direct in hun eigen machinetaal instructies uit te laten voeren. Dit door direct de enen en nullen te specificeren die door de processor kunnen worden begrepen.
• Tweede generatie: de kale machine-instructies wordt in een door de mens leesbare taal neergezet. Het is dus feitelijk een vertaling van de machinetaal. Het sturen van de machine vormt echter nog steeds het uitgangspunt. De functionele wensen zijn hieraan ondergeschikt. 
• Derde generatie: bij deze zogenaamde procedurele talen staat het te programmeren (computer)programma centraal. Dit door gebruik te maken van vooraf gedefinieerde instructies die zich (op de achtergrond) vertalen in enen en nullen. Het betreft talen zoals als COBOL, Pascal en Java. De meeste (computer)programma’s worden in een derde generatie taal geschreven.
• Vierde generatie: talen met een hoger abstractieniveau die voor een bepaald doel zijn ontwikkeld. Deze taal is gebaseerd op een dichter bij de machine (computer) staande programmeertaal en zodanig gestructureerd dat kennis van deze "lagere" programmeertaal niet nodig is, om toch toepassingen te kunnen schrijven. Voorbeelden van zijn Progress 4GL en Uniface.
• Vijfde generatie: probleemoplossende talen. Hierbij specificeert de programmeur geen algoritme maar het probleem zelf, met een aantal bijbehorende beperkingen. Vijfde generatie-talen worden vooral gebruikt op het gebied van kunstmatige intelligentie. Het bekendste voorbeeld is Prolog.

Programmeertalen; Veel voorkomende instructies;

Programmeren is het schrijven van een concrete verzameling instructies die een computer uitvoert. Elke programmeertaal kent haar eigen instructies. Sommige instructies komen echter in elke programmeertaal voor. Deze woorden zijn steeds uit het Engels afkomstig. Veel voorkomende sleutelwoorden zijn:

• If; hierop volgt een voorwaarde en een reeks statements die voorwaardelijk uitgevoerd moet worden. Na de voorwaarde komt soms het woord then (ook wel eens do). Na de voorwaardelijk uit te voeren statements komen eventueel else gevolgd door een reeks statements die juist wordt uitgevoerd als niet aan de voorwaarde is voldaan.
• Goto; hier springt de uitvoering van het programma naar een ander statement. Dat andere statement is gemarkeerd met een label. Bijna alle programmeertalen kennen goto, maar het gebruik ervan wordt in de moderne programmeerpraktijk afgeraden.
• For; hierna komt een reeks statements die die herhaaldelijk uitgevoerd moet worden. Er wordt een lopende variabele gegeven, met begin- en eindwaarde en wijzigingsoperatie, meestal het met één verhogen of verlagen. Deze constructie wordt meestal gebruikt voor herhalingen waarvan het aantal slagen tot een vooraf bepaalde grens is beperkt.
• Foreach; geeft een iteratie, een lopende variabele en een enumeratie, dat wil zeggen, een object dat zelf al een standaardmethode definieert op iteratie over de waarden ervan mogelijk te maken. Het kan gaan om een al bepaalde collectie waarden (zoals een lijst of array), maar dat hoeft niet.
• While; ook dit is een iteratie, maar in plaats van een lopende variabele wordt een voorwaarde gegeven; de iteratie wordt uitgevoerd totdat niet meer aan de voorwaarde voldaan is. Dit wordt meestal gebruikt voor iteraties waarvan het aantal stappen op het moment van ingaan nog onbekend is.
• Do en/of loop; geeft alleen een iteratie; kan alleen worden verlaten door statements binnen de iteratie die beëindiging veroorzaken, zoals return, exit, break, goto.
• Begin en end; deze sleutelwoorden dienen om een reeks statements expliciet te groeperen tot een blok. Sommige programmeertalen gebruiken hiervoor geen woorden maar haakjes, bijvoorbeeld { en }.
• Break; dient om een iteratie voortijdig te beëindigen.
• Call; aanroep van een subroutine. De uitvoering gaat verder met de subroutine. Is de subroutine voltooid, dan wordt de uitvoering hervat bij het statement na call

e  Testen

Testen is een proces gericht op het beoordelen van (tussen) producten om inzichten te verkrijgen in de kwaliteit en risico’s van het (deel)systeem. Met testen haal je fouten die tijdens het ontwerpen of programmeren zijn gemaakt eruit. Testen geeft inzicht in de duidelijkheid, begrijpelijkheid en werkbaarheid van het product. En de argumenten waarom voor bepaalde oplossingsrichtingen is gekozen.  Testen is daarmee een belangrijk onderdeel binnen systeemontwikkeling. Testen vindt op meerdere momenten plaats. Ook hier is het V-model een handig instrument om de verschillen soorten testen te duiden. Bij de unit- c.q. applicatietest worden de stukken codes afzonderlijk (unittest) en in samenhang (applicatietest) getest. Indien er geen blokkerende bevindingen zijn vindt er een ketentest plaats. De software wordt dan getest in samenhang met de raakvlaksystemen (interfaces). Als ook deze test met succes wordt doorlopen vindt de acceptatietest plaats. Hier wordt vastgesteld of het bedrijfsproces functioneert zoals het bedoeld is. Dit wordt getest door het systeem in samenhang met organisatorische aspecten, zoals werkinstructies en opleidingen samen te laten werken. Daarom wordt deze test ook wel de gebruikersacceptatietest genoemd. Het testproces kent 4 stappen:

1. Opstellen Mastertestplan; bepalen van de testopdracht, de testaspecten en het testkader. In het Mastertestplan wordt ook de teststrategie vastgesteld. De teststrategie beschrijft welk product wordt getoetst, op welke aspecten er wordt getoetst en wanneer en hoe zwaar er wordt getest. En door wie en met welke technieken er wordt getest.
2. Testvoorbereiding; op basis van het Mastertestplan wordt er (voor de verschillende testfasen) een Testplan opgesteld. Op basis van de teststrategie worden concrete testgevallen geformuleerd. Waarbij meestal een onderscheid wordt gemaakt in testen in relatie tot productrisico’s en procesrisico’s.
3. Uitvoeren testen; op basis van het Testplan en de daarbij behorende testgevallen wordt het product getest. Bevindingen worden vastgelegd en gecategoriseerd. 
4. Opstellen testrapport; tenslotte moet er een rapportage worden opgesteld over de uitgevoerde testwerkzaamheden in relatie tot het Testplan. De testrapportage geeft inzicht in de kwaliteit en risico’s van het op te leveren (deel)systeem.

f  Accepteren

Is de laatste fase in het V-model. Doel van de acceptatietest is om tijdig te weten te komen of het systeem voor de gebruiker, management en beheer, acceptabel is. Veelal verleent de opdrachtgever na acceptatie decharge aan de opdrachtnemer. Bij de acceptatietest wordt nagegaan of er problemen zijn te verwachten in het gebruik die bij eerdere testen nog niet gevonden zijn. De acceptatietest kan onder meer de volgende testsoorten omvatten:

• Real life test (of straattest); alle normale handelingen worden hierbij doorlopen, van eerste tot en met de laatste stap. De nadruk ligt dus op klant tot klant processen: leidt de handeling van de klant tot een gewenst eindresultaat? Voorbeeld: een klant vraagt via Internet een huurtoeslag aan. De gebruiker verwacht een juiste en snelle beschikking op de mat, per email of op een site. Hij heeft geen interesse in de werking van het systeem en de raakvlakken. Elke verstoring in het proces, zoals verloren informatie, een vertraging of een foute beschikking maakt hier inbreuk op. 
• Gebruikersvriendelijkheidstest; De nadruk ligt op look-and-feel van het systeem: Is de site makkelijk te vinden? Is deze logisch opgebouwd? Wat is de fouttolerantie? Is gedacht aan kleurenblinden en doven? Is de beschikking prettig leesbaar? Wanneer de resultaten van een usability (gebruiksvriendelijkheids)test goed gebruikt worden voor aanpassingen van het systeem zal dat veel bijdragen aan het succes van een product of dienst.
• Performancetest; de nadruk ligt op tijdgedrag van het product: is de verwerkingstijd aanvaardbaar? Hoe is dat voor 1 aangevraagde toeslag? En voor 5.000 tegelijkertijd aangevraagde toeslagen? Welke invloed heeft dat op het gebruik van resources van het systeem van onder andere de CPU en het RAM geheugen?
• Stresstest; de nadruk ligt op extreem gebruik van het systeem: hoe gedraagt het zich bij piekbelasting? Wat is het breekpunt van het systeem, m.a.w. hoeveel gebruikers zijn er nodig, om het systeem onbehandelbaar langzaam te maken.
• Monkeytest; de nadruk ligt op misbruik van het product, het creëren van onvoorziene en niet vooraf gespecificeerde omstandigheden. Een monkeytest wordt soms toegepast om te kunnen bepalen of een systeem voldoende stabiel is om met het eigenlijke testen te beginnen. De vraag is of het systeem foolproof is.