|
Tags: Applicatieontwikkeling | Java
| ||
| ||
Organisaties verliezen te veel tijd en geld met softwareontwikkelingDoor Jan Buelens van Info SupportSoftwareontwikkeling is een complex proces. Er zijn veel zijwegen en alternatieve routes mogelijk om tot een nieuw stuk software te komen. Tijdens het proces dienen steeds opnieuw keuzes gemaakt te worden, bijvoorbeeld over aanpak, functionaliteit, technologie en architectuur. Hoe vaak komt het niet voor dat softwareontwikkelprojecten ondoorgrondelijk zijn geworden? Dat niemand meer precies weet wat de status is van het project en niemand de kwaliteit ervan kan garanderen? Organisaties verliezen geld en tijd doordat ze niet de juiste ervaring en/of kennis in huis hebben. Nog moeilijker is het om in te schatten hoeveel tijd en geld er voorzien moet worden voor de ontwikkeling van een stuk software. Hoe krijg je als organisaties grip op het softwareontwikkelproces?Info Support heeft in de loop der jaren in de praktijk ondervonden dat organisaties nodeloos veel geld en tijd uitgeven aan softwareontwikkeling. Ook kunnen organisaties nauwelijks inschatten hoeveel tijd en geld ze ervoor moeten voorzien. Met die vaststelling zijn we naar onze klanten gestapt. Welke problemen ondervonden zij tijdens de ontwikkeling van software? De volgende antwoorden kwamen steeds terug:
Bijvoorbeeld:
Ontwikkeltijd en -kosten voorspellenBij de opstart van een ontwikkelproject bekijken we met de klant de complexiteit van de toepassing die we zullen ontwikkelen.Om niets aan het toeval over te laten, gebeurt een expertschatting door verschillende medewerkers, van wie we de resultaten naast elkaar leggen. Eventuele verschillen worden besproken en geëvalueerd. Met die twee methodes kunnen we vooraf al een eerste raming maken van de te investeren tijd en het budget. Maar we gaan nog een stap verder. Via onze financiële modellen kunnen we ook de winst berekenen van wie met Endeavour werkt. Zo gaan we na hoeveel tijd men normaal gezien nodig heeft om van conceptnaar test- en productiefase te gaan. Met Endeavour kunnen we de productiviteit significant verhogen. Door het aantal functiepunten en het aantal beschikbare mensen in te geven in ons financieel model, rekenen we snel uit hoeveel tijd de klant met Endeavour kan besparen op jaarbasis. Univé is een van onze klanten op wie we dit financieel model toepassen. De berekening van de winst die zij realiseren door te ontwikkelen via Endeavour, komt altijd uit. Iedereen betrekken bij het ontwikkelprocesIn plaats van te focussen op het eindproduct, helpt Endeavour de projectleden bij het hele ontwikkelproces om tot een geslaagde toepassing te komen. Een concept plannen, ontwerpen, bouwen, testen, implementeren: het zit er allemaal in vervat en Endeavour loodst de gebruiker stapsgewijs doorheen alle ontwikkelfases. Daartoe hebben we de “Digital Coach” ontwikkelt, die alle betrokkenen van bij het begin tot het eind begeleidt bij het ontwikkelproces. De informatie die de Digital Coach geeft, is zeer divers: van projectstrategie tot checklist en van literatuur tot softwaremodules.De Digital Coach houdt rekening met verschillende rollen: een architect krijgt andere informatie van het platform dan een ontwerper, projectleider of ontwikkelaar. Als je bijvoorbeeld ontwikkelt in Java heb je de keuze tussen verschillende producten, wat het er natuurlijk niet altijd eenvoudiger op maakt. Welke application server kies ik? Welk webframework en welke database? Hoe configureer ik mijn IDE of ontwikkelomgeving? Endeavour begeleidt de programmeurs in hun keuze, zodat de organisatie geen kostbare tijd hoeft te spenderen aan een vergelijkend onderzoek. Minstens even belangrijk is dat iedereen betrokken wordt bij het hele proces: de ontwikkelaar, uiteraard, maar ook het Management en de Eindgebruiker die met de nieuwe toepassing zal werken. Om de samenwerking te bevorderen, biedt Endeavour een projectportal waar elke betrokkene toegang toe heeft en waar men de status van het project permanent kan opvolgen. Je hoeft geen IT-specialist te zijn om de rapporten te interpreteren: eenvoudige grafieken geven een helder globaal overzicht van de stand van zaken. Zo vermijd je een stressvolle en arbeidsintensieve eindfase die kenmerkend is voor de meeste ontwikkelprojecten. De projectportal biedt dagelijkse rapportage over de status van het project. Je kan er onder andere zien hoeveel issues er openstaan, of de code die de ontwikkelaar de dag voordien heeft ingecheckt werkt, hoeveel en welke toepassingen er al ontwikkeld zijn, enzovoort. Het rapport laat toe om verder door te klikken op elk specifiek onderdeel. Daar kan je op detailniveau zien hoeveel unittesten gelukt of mislukt zijn, hoeveel open work items er zijn, hoeveel remaining work items en ga zo maar door. Softwareontwikkeling is een continu leerproces. Als je drie weken nodig gehad hebt voor één functie, kan je ook terugkijken en nagaan hoe dat komt, door de historische gegevens te raadplegen. Dat levert nuttige informatie op voor de toekomst. Optimale kwaliteitHet is belangrijk om op basis van objectieve parameters te kunnen bepalen wanneer een softwareontwikkelingtraject goed verloopt. Meten is immers weten en door te weten, leer je bij. Alleen zo kan je garanderen dat de kwaliteit van de ontwikkelde toepassing optimaal is.
Maar waarin zit die kwaliteit nu? Als
een ontwikkelaar aan code heeft
gewerkt,
checkt hij dat ’s avonds in
en elke nacht
of op geprogrammeerde tijdstippen
wordt de hele broncode gebuild en
getest.
Als de build niet compileert, komt
het project in het rood in het
rapport.
Zo ziet iedereen onmiddellijk dat er
iets
niet klopt, kan men opzoeken waar het
wringt en tijdig ingrijpen. Je ontdekt
niet pas na drie weken dat er iets
fout
is, zodat je ook niet helemaal van
vooraf
aan moet beginnen. De duidelijke
rapportering
mist haar effect niet: hoe
vroeger in het proces een fout
gevonden
wordt, hoe minder duur het is om die
op te lossen. Ook voor de
ontwikkelaars
maakt het een verschil. Niemand wil er
de schuldige van zijn dat een project
in
het rood staat. Ontwikkelaars zullen
hun
code dus pas inchecken als ze er zeker
van zijn dat het werkt. Dat levert
vanzelf
kwalitatieve eindproducten op. En
unittesten,
tests voor een klein stukje software
zoals één
functie in een bepaalde
toepassing, worden regelmatig
herhaald.
Immers, als er bepaalde aspecten
veranderen
in de boven- of onderliggende
technologie, moet men er zeker van
zijn
of alles wat daarmee samenhangt wel
nog naar behoren werkt. Deze
gestructureerde
aanpak verhoogt naast de kwaliteit
ook de productiviteit. Zo stelt een
van de richtlijnen dat je eerst je
unittest
moet schrijven en je pas dan de
eigenlijke
code implementeert. Hierdoor denk
je eerst na over de functie en welke
resultaten
je verwacht terug te krijgen. Zo win
je kwaliteit en tijd.
It’s alive!Meer dan in welke sector ook, zijn er in de ICT-wereld permanente evoluties aan de gang. We volgen de markttrends dan ook op de voet en passen onze producten voortdurend aan. Zodra een nieuw product op de markt komt, kijken we hoe dat past binnen Endeavour. Onze strategie voor wat Java betreft, bestaat eruit dat we kijken wat er allemaal op de markt aanwezig is. Daar halen we de beste dingen uit om die dan weer verder uit te breiden. Daartoe werken we ook samen met Nederlandse Java-groep, waarvan we zelf actief lid zijn. Het kan gaan om een nieuwe ontwikkeltool, een nieuw webframework, een richtlijn hoe je het best JSF gebruikt, of de laatste ervaringen met EJB3. Op regelmatige tijdstippen bundelen we alle updates in een nieuwe versie van Endeavour.Bij softwareontwikkeling richt men zich te vaak alleen op het eindproduct. Minstens even belangrijk is het proces om tot dit eindproduct te komen en er overal grip op te blijven houden. Met een softwareontwikkelstraat werk je gecontroleerd en gestructureerd aan software. Je kan de status van het eindproduct op elk moment controleren en opvolgen en eventueel bijsturen. Dit beperkt zich niet tot de eerste oplevering, maar gedurende de gehele levenscyclus van een applicatie, dus ook tijdens het beheer en onderhoud. Hierdoor kunnen wij harde uitspraken doen over de kwaliteit en de projectduur. En zo houden organisaties kosten en tijd onder controle en hebben ze grip op softwareontwikkeling. Jan Buelens, consultant bij Info Support België www.infosupport.com | ||
| Lees meer over Info Support | ||
| Ga terug naar We Love IT uitgave #3 - 2008 | ||
|





Maar waarin zit die kwaliteit nu? Als
een ontwikkelaar aan code heeft
gewerkt,
checkt hij dat ’s avonds in
en elke nacht
of op geprogrammeerde tijdstippen
wordt de hele broncode gebuild en
getest.
Als de build niet compileert, komt
het project in het rood in het
rapport.
Zo ziet iedereen onmiddellijk dat er
iets
niet klopt, kan men opzoeken waar het
wringt en tijdig ingrijpen. Je ontdekt
niet pas na drie weken dat er iets
fout
is, zodat je ook niet helemaal van
vooraf
aan moet beginnen. De duidelijke
rapportering
mist haar effect niet: hoe
vroeger in het proces een fout
gevonden
wordt, hoe minder duur het is om die
op te lossen. Ook voor de
ontwikkelaars
maakt het een verschil. Niemand wil er
de schuldige van zijn dat een project
in
het rood staat. Ontwikkelaars zullen
hun
code dus pas inchecken als ze er zeker
van zijn dat het werkt. Dat levert
vanzelf
kwalitatieve eindproducten op. En
unittesten,
tests voor een klein stukje software
zoals één
functie in een bepaalde
toepassing, worden regelmatig
herhaald.
Immers, als er bepaalde aspecten
veranderen
in de boven- of onderliggende
technologie, moet men er zeker van
zijn
of alles wat daarmee samenhangt wel
nog naar behoren werkt. Deze
gestructureerde
aanpak verhoogt naast de kwaliteit
ook de productiviteit. Zo stelt een
van de richtlijnen dat je eerst je
unittest
moet schrijven en je pas dan de
eigenlijke
code implementeert. Hierdoor denk
je eerst na over de functie en welke
resultaten
je verwacht terug te krijgen. Zo win
je kwaliteit en tijd.