Onderwerpen  |   Branches  |   Afdelingen  |   Bedrijven  |   FAQ  |   Nieuwsbrief  |   Contact
Whitepaper

Methodische softwareontwikkeling, middel of doel?

Methodische softwareontwikkeling, middel of doel?

Download Methodische softwareontwikkeling, middel of doel?

Deze whitepaper van Magic Software beschrijft de huidige trends in applicatiebouw. De auteur laat zien hoe software-ontwikkeling kan worden geoptimaliseerd met het oog op effectiviteit, aanpasbaarheid, benodigd onderhoud en Total Cost of Ownership (TCO). Op basis van een uitgebreide analyse vergelijkt hij een component-gebaseerde aanpak met een aanpak op basis van object-oriëntatie. De auteur betoogt dat ontwikkeltrajecten waarbinnen is gekozen voor een component-gebaseerde aanpak een een kortere doorlooptijd opleveren en een grotere klanttevredenheid. Dat komt onder meer omdat een relatief simpele, op de wensen van de gebruikers gerichte analyse-opzet volstaat.

Type
Whitepaper
Datum
juni 2012
Taal
NL
Bedrijf
Inhoudsopgave
  • Object-oriëntatie nader beschouwd
  • Component Based Development nader beschouwd
  • Conclusie
  • Over Magic Software Enterprises
Methodische software ontwikkeling, middel of doel? Inhoud Verantwoording ...................................................................................................... 1 Introductie .............................................................................................................. 2 Object oriëntatie nader beschouwd .......................................................................... 4 Component Based Development nader beschouwd ..................................................... 7 Conclusie ............................................................................................................. 12 Over Magic Software Enterprises............................................................................ 14 Verantwoording Auteur heeft in dit stuk gekeken naar de tegenwoordige ontwikkeltrends in applicatiebouw en zich daarbij afgevraagd of applicatiebouw efficiënt en effectief plaatsvindt en of er verdere optimalisatie mogelijk is. Hierbij zijn voor de applicatiebouw en -gebruik de volgende vraagstellingen gehanteerd; Hoe effectief is het ontwikkeltraject? In welke mate blijft een oplossing / bouwproject na oplevering aanpasbaar aan veranderende omstandigheden? Wat is de onderhoudsomvang na oplevering en waar liggen de knelpunten? Wat is de levenscyclus van een oplossing en wat heeft het in zijn totaliteit gekost. (Total Cost of Ownership TCO)? Hierbij is niet gekeken naar de grote standaardoplossingen zoals toonaangevende ERP, HRM en CRM softwareoplossingen van bijvoorbeeld Oracle, SAP, IBM en Microsoft, maar meer naar lokale brancheen bedrijfsspecifieke oplossingen en deeloplossingen. Auteur is bekend met de meest gehanteerde analyse-, ontwikkel- en projectaanpak methoden en technieken en heeft trends en ontwikkelingen hierin gevolgd. 1 Introductie Sinds er softwareontwikkeling is, zoekt men naar wegen om dat op de meest efficiënte en effectieve wijze te doen. Uiteraard werden er in het begin, de jaren 60 van de vorige eeuw, de grootste stappen gemaakt. Van binair naar hexadecimaal naar iets wat men een ontwikkeltaal kan noemen uiteindelijk leidend tot platformen als COBOL, FORTRAN en later naar de op dit moment wat dichterbij liggende talen als Pascal en Basic. Inmiddels is er `een soort van' status quo met C en C++ enerzijds en .NET en Java anderzijds. Binnen de evolutie van ontwikkelomgevingen is er echter altijd gezocht naar versnelling, vereenvoudiging en structurering van de gebruikte platformen. In de tweede en derde generatie talen was dat in eerste instantie het verbeteren van het gemiddeld aantal coderegels per programmeur, later migreerde dat meer naar de definitie van frameworks en met name de communicatie tussen de samenstellende delen zoals CORBA, COM en DCOM en meer recentelijk de ontwikkelframeworks J2EE en .NET. In grote lijnen definieert men in die frameworks een communicatie protocol voor zelfstandige op zich staande generieke `procesjes', zodat men deze `procesjes' aan elkaar kan koppelen en daarmee een hoeveelheid gevraagde functionaliteit produceert. Belangrijk hierin was de opkomst van de `Unified Modelling Language' (UML) waarin 3 zaken belangrijk zijn, te weten: Het normaliseren van een proces Het verheffen in de (totale) abstractie van een dergelijk proces, de `anonieme herbetreedbaarheid' met andere woorden: de juiste vraag krijgt altijd antwoord. De `separation of concerns' ofwel het `procesje' moet iets unieks doen dat niet overlapt met andere `procesjes'. U raadt het al, die `procesjes' zoals ik ze hier noem zijn objecten in de automatiseringsvolksmond en het idee erachter is de zogenaamde Object Oriented Development Approach. Het grote idee is en blijft het ontwikkelen van een set van bouwstenen die aaneengeschakeld een bepaalde functionaliteit kunnen afhandelen, waarbij het zowel ontwikkelgemak als de ontwikkelsnelheid toenemen, naast uiteraard een vereenvoudiging en daarmee afname van de periodieke onderhoudslast. 2 In de afgelopen decennia is er erg veel gedacht en geschreven over die wijze van applicatie ontwikkeling en in feite is iedereen het ook eens met de generieke aanpak van `develop once and deploy multiple' mits hanteerbaarheid en overerfbaarheid zijn gewaarborgd. De uitdaging echter is te komen tot een dergelijke generieke blokkendoos waarmee in principe alle door gebruikersorganisaties gevraagde functionaliteit kan worden gerealiseerd. Het grootste venijn zit hem hierbij in de ontwikkeling van het object framework, dit om twee redenen; de eerste reden is het feit dan het niet eenieder is gegeven om in een abstractie te denken en te ontwikkelen die benodigd is om het volledig en conform conventies te kunnen uitvaardigen, de tweede reden is de tijd en de inspanning die het kost om een dergelijk framework te realiseren, naast het intensieve onderhoud dat het vergt. Derhalve kan een dergelijk framework alleen rendabel worden en de beoogde voordelen halen als het vele malen kan worden gebruikt, met andere woorden men moet veel applicaties bouwen om uit de kosten te kunnen komen. Nu is er voor die bezwaren in de loop der jaren wel een oplossing ontstaan waarbij bedrijven zich toelegden op de ontwikkeling van deze frameworks of libraries/widget toolsets, die door applicatiebouwers konden worden aangeschaft. Schaalvergroting maakte de aanpak rendabel. Er bestaat tegenwoordig redelijk wat activiteit in de aan- en verkoop van deze soorten van libraries. 3 Object oriëntatie nader beschouwd De bouw van functionaliteit met behulp van een dergelijk framework is doorgaans als hieronder schematisch aangegeven: De werkwijze is in grote lijnen het op basis van de gevraagde functies van het te bouwen systeem het definiëren van een datamodel en het samenstellen van een `object domain'. Een dergelijk `object domain' kan bestaan uit zelf ontwikkelde objecten al dan niet in combinatie met een of meerdere aangeschafte standaard libraries/toolsets (zie afbeelding 1). Afbeelding 1 Eerste probleem is dan dat verschillende libraries en zelfontwikkelde sets dienen te voldoen aan de eisen gesteld door het gedefinieerde object domain en dat eventuele overlappingen in objecten geneutraliseerd dienen te worden. In de daadwerkelijke bouw en de afstemming met gebruikers is het dan daarna veelal zo dat het domain niet volledig past of tekortschiet en er object sets dienen te worden bijgebouwd. Meestal is er een 70 tot 80% fit. De constatering hiervan wordt doorgaans op een laat moment gedaan (zie afbeelding 2); dit heeft veelal te maken met een niet volledige analyse (door zowel `ontvanger' als `brenger'), een gebrek aan adequate validatie en een goede omschrijving van hetgeen geleverd dient te worden. Natuurlijk zal een ieder zeggen dat dit bij hen niet zo is en goed georganiseerd is, alleen resteert dan de vraag: `Hoe komt het dat meer dan 80% van de automatiseringsprojecten mislukken?' Afbeelding 2 4 Met name aan het einde van een projectdoorlooptijd, zo tussen de 70 en 80% realisatie gaan omissies verschijnen en dient men dilemma's op te lossen als: `stellen we de opleverdatum significant uit of gaan we een best fit bouwen voor de ontbrekende functionaliteit waarbij conventies "even" worden verlaten?' Vaak wordt voor het tweede gekozen met als risico dat alleen de bij het project direct betrokkenen van alle details op de hoogte zijn, waarbij documentatie (en met name technische) vaak achter- of wegblijft, hetgeen dan achteraf gaat leiden tot een verhoogde inspanning voor aanpassingen en onderhoud. Dit wordt ook wel `Fuzzy Built' genoemd, dat uiteraard iets vriendelijker klinkt dan `afgeraffeld'. De ervaring leert dat veel projecten op deze wijze worden afgerond waarbij we dan extra bijkomende problemen als aanpassingen van het datamodel en wisseling van projectbezetting nog maar even achterwege laten. De uitdaging zal een ieder met ervaring in applicatiebouw Afbeelding 3 bekend voorkomen. Het is eigenlijk ook wel te verklaren door de boven beschreven stappen eens op een tijdlijn te plaatsen: Afbeelding 4 In afbeelding 4 wordt in een tijdlijn op hoofdlijnen het bouwproject van een applicatie weergegeven, dus na de analyse en ontwerpfase. Op deze tijdlijn (van 1 naar n) wordt aangegeven waar een datamodel en object domain zodanig gereed is dat men met de bouw van functionaliteit begint. Tijdens de bouw echter ontmoet men zaken die ingrijpen op datamodel en object domain, of die vanwege complexiteit of anderszins worden doorgeschoven naar het einde van de doorlooptijd. 5 De uitdaging is dan vaak om fundament (datamodel en object domain) en gewenste functionaliteit met elkaar gesynchroniseerd te houden. Ook als dit met moderne projectmanagementmethoden wordt uitgevoerd zoals DSDM of SCRUM dan zal dit in principe weinig afdoen aan de boven gepresenteerde tijdlijn, de tijdvakken worden iteraties of sprints en de functionaliteit waarvoor geen tijd was of problematisch bleek in die fase, wordt op zich verder doorgeschoven naar een volgende fase en uiteindelijk naar het einde van een project doorlooptijd. Natuurlijk poogt men dat in de vermeldde methoden te voorkomen en stelt men hierin een aantal wetmatigheden die dit moeten voorkomen, maar waar niet of weinig rekening mee wordt gehouden zijn meestal de belangen die buiten het project liggen zoals commerciële belangen, bezettingsproblemen, veranderende behoeften naarmate doorlooptijden langer zijn dan 8 maanden enz enz. Kijkend naar de meer abstracte fasen in een project ziet men dat er in eerste instantie een datamodel en een object domain dient te worden gerealiseerd. Veelal echter start men al met de bouw van functionaliteit voordat model en domain zijn `dichtgetimmerd' door middel van validatie en autorisatie, dit lijkt ook schier onmogelijk. Ja, iedereen weet dat het op deze wijze moet werken, en in voorkomende gevallen ook zo werkt maar er blijft de vraag: "kan het anders, kan het beter?". Laten we eens wat verder kijken. 6 Component Based Development nader beschouwd De component based aanpak is (eveneens en mede) gebaseerd op de theorie van Design Patterns ofwel de Model Based aanpak. Deze aanpak is geïntroduceerd vanuit de architectuur en dan bedoelen we de architectuur voor de bouw van huizen en panden. In deze denkwijze zou je panden op basis van standaarden of modellen moeten bouwen, dit is eenvoudig voor te stellen als je denkt aan de maatvoering van deuren en ramen, de maatvoering van leidingen en afvoeren, maar gaat verder met standaarden voor daken, voorgevels, keukens, trapopgangen enz enz. Dit lijkt voor één huis niet echt belangrijk, voor het bouwen van wijken en steden echter wel. Deze gedachte naar de IT brengend zou je kunnen denken aan componenten, bijvoorbeeld aan de entiteit `klant' en omdat deze niet zoveel afwijkt ook aan de entiteit `leverancier' daarmee dan ook aan de entiteit `relatie'. Op deze wijze kun je ook denken aan debiteur/crediteur en aan factuur (verkoopen inkoop). In wezen dus aanzienlijk grofkorreliger dan de object based approach waarin men denkt aan krediet check, betaling, ontvangst enz. Of in een andere vergelijking: De Object Oriented Approach (OO) definieert woorden (werkwoorden, zelfstandig naamwoorden enz), de Component Based Approach (CBA) definieert standaard zinnen in de zin van `wij [zullen] [ontvangen] het bedrag [overmaken] [gaarne] op rek.nr.' en geven mee of het een betaling of een ontvangst moet zijn. Het geheel vindt plaats op basis van het `parameterizeren' van de zin, in casu het component. Ook hier echter weer, de componenten moeten wel op een standaard wijze met elkaar communiceren, bijvoorbeeld zoals bij service orientation het geval is, of zoals bij de aloude anoniem herbetreedbare subroutine: "als je mij de juiste vraag stelt dan krijg je het antwoord dat ik kan geven." 7 Een schematische based voorstelling van een wordt component framework hiernaast gegeven in afbeelding 5. In deze afbeelding wordt getoond hoe een component based framework zou kunnen worden opgezet. Uiteraard is er weer een datamodel benodigd op basis van analyse en ontwerp en uiteraard de data eisen van de in te zetten componenten. Afbeelding 5 Voorts zal een functionaliteitsflow dienen te worden gemaakt waarin wordt vastgesteld wat de flow van functionaliteit over rollen en verantwoordelijkheden dient te zijn. Daarna kunnen componenten worden ingezet op basis van de benodigde functionaliteit. Uiteraard, zoals bij de object oriëntatie, zal een framework niet alle gewenste of toegezegde functionaliteit afdekken en zullen er eenzelfde soort van problemen opdoemen, echter reeds in de toepassing van een component die de gevraagde functionaliteit mist. De beslissing dient dan te worden genomen het component hierop aan te passen of een nieuw component hiervoor te vervaardigen. Hierbij is er uiteraard weer het gevaar aanwezig dat functionaliteit wordt doorgeschoven naar het einde van de doorlooptijd; anders is echter dat het besluit `aanpassen of nieuw bouwen' direct bij constatering dient te worden genomen, veelal al in de analyse/opzet fase, en dient direct te worden afgestemd met de ontvangende / afnemende partij. De ontvangende partij kan dat ook beter bepalen omdat componenten veel meer functioneel georiënteerd zijn. 8 Er bestaan echter frameworks en samengestelde frameworks die de bovenomschreven problematiek van een project team in belangrijke mate ondervangen. Een project team werkt van nature als een bulldozer die missende, complexe en niet volledig uit gedefinieerde zaken naar voren schuift waarbij dan bij de oplossing ervan niet gebruik gemaakt kan worden van de initieel gedefinieerde fundamenten, het synchronisatie probleem tussen datamodel en object domain als hiervoor beschreven. De architectuur van een dergelijk platform kan als volgt worden weergegeven (afbeelding 6): Afbeelding 6 In deze schematische voorstelling wordt de basis gelegd door een `application generator', veelal gebouwd in een 3GL taal (C of C++) met daarop (noem het maar voor het gemak) een `binding' laag die bijvoorbeeld de overerfbaarheid van eigenschappen regelt, maar ook de communicatie tussen componenten en de connectie naar data bases met daarnaast een keur aan ready made instructies voor merge, sort, link, calculate enz enz. Een dergelijk platform wordt ook wel een `Metadata Driven' platform genoemd waarbij een programma wordt `geschreven' door het geven van een set uitvoeringsinstructies aan een `Deployment Engine', een feite een vergelijkbaar met het hanteren van een afstandsbediening voor het laten rijden van een auto of het aanmeren van een boot. Een component kan hierin worden gezien als een set van vooraf gedefinieerde instructies aan de auto of de boot. Op dit geheel is een componenten set gelegd, volledig open en aanpasbaar, communicerend en reagerend zoals de applicatie generator voorschrijft. Een dergelijke componenten set kan worden vergeleken met een set van services als in een Services Oriented Architecture, dus met de separation of concerns en de herbetreedbaarheid. 9 Daarnaast kan er bij een component based aanpak een relatief simpele analyse-opzet worden aangehouden, volledig gericht op gebruikers, de informatie die ze wensen en de informatie die ze dienen op te leveren. Omdat men volledig binnen eindgebruikersfunctionaliteit werkt bij de inzet van componenten kan uitgegaan worden van het volgende analyse paradigma (afbeelding 7): Nevenstaand paradigma werkt eenvoudig maar zeer doeltreffend, voor iedere gebruiker of gebruiksdiscipline wordt vastgesteld welke input nodig is per onderdeel van het takenpakket, welke data elementen daarvoor nodig zijn en wat de output moet zijn in de zin van nieuwe input of rapporten en welke informatieverzamelingen dienen te worden bijgewerkt. Afbeelding 7 Hierbij dient uiteraard te worden vastgehouden aan de conventies waarbij de belangrijkste toch wel de separation of concerns is, het voorkomen of neutraliseren van overlap met direct gevolgd door de anonieme herbetreedbaarheid dwz: een juiste vraag krijgt altijd antwoord, ongeacht wie vraagt. De werkwijze in een component based aanpak kan ook op een andere wijze in beeld worden gebracht. Hierbij wordt de invalshoek van de gebruiker gehanteerd en ingezoomd op de onderdelen (componenten) die worden gehanteerd bij de samenstelling van de gewenste gebruikersfunctionaliteit. Dit kan als volgt worden weergegeven: 10 Afbeelding 8 In afbeelding 8 is schematisch een boekingsapplicatie weergegeven met de mogelijkheden voor het boeken van een reis, hotel en auto. Na reservering kan er worden betaald en kan de boeker in een bonussysteem worden opgenomen. Na het maken van een keuze, kan er worden geboekt, betaald en bevestigd. Deze bevestiging gaat zowel naar de boeker als naar de betrokken dienstenleveranciers op de voorgeschreven wijze. Op zich een begrijpbare applicatie, geen `rocket science' en kan relatief eenvoudig met een component based framework worden `samengesteld'. `Eenvoudig' betekent ook dat beginnende programmeurs met een relatief korte opleiding in een dergelijk framework dit kunnen. De meer ervaren programmeurs worden ingezet als begeleiding en de eventuele aanpassing/nieuwbouw van te hanteren componenten. Een efficiënte en effectieve werkwijze. In het ingezoomde deel zijn componenten volledig geparameteriseerd ingezet, waarbij men kan zoeken (incremental- en fuzzy search), categoriseren, printen, uiteraard boeken enz enz. 11 Los van het layout-deel en de extra informatie omtrent de aangeboden vakanties kan een dergelijk systeem verbazingwekkend snel worden samengesteld. Conclusie In bovenstaande verhandeling blijkt duidelijk dat auteur een voorstander is van een component based aanpak. Dit gebaseerd op een uitgebreide projectervaring van waterval naar iteratief/incrementeel en van monolithische bouw naar Object Oriented, Services Based en Component Based systemen. De projecten waaraan gerefereerd wordt speelden zich af bij de grote uitgeverijen in Nederland en België, de grote vervoersmaatschappijen in Nederland, telecom providers in Nederland en leverden oplossingen als kennissystemen, front- en back office systemen en Business Intelligence systemen. Hierbij dient te worden vermeld dat een geslaagd project door auteur wordt gezien als een project waarbij de afnemer tevreden is en de doelstellingen zijn bereikt. Met doelstellingen wordt dan bedoeld de punten aangehaald in de verantwoording aan het begin van deze verhandeling, te weten: De effectiviteit van het ontwikkeltraject. De aanpasbaarheid van de geleverde oplossing ten opzichte van veranderende markten. De onderhoudsvriendelijkheid van de oplossing. Total Cost of Ownership (TCO) Los van de gekozen project methode hadden de meeste projecten waaraan werd deelgenomen de neiging het venijn daadwerkelijk naar de staart te verschuiven, doorlooptijdverlenging op te leveren en een frustratie niveau te creëren dat een `gezonde' oplevering van het project in gevaar kon brengen. In de component based aanpak als boven omschreven bleek dit in een aanzienlijk mindere mate het geval te zijn. Een verklaring hiervoor in de metafoor als hiervoor aangegeven, het bouwen van een huis of een aantal huizen, zeg maar een wijk, is als volgt: Het aantal typen van mogelijke huizen is vooraf gedefinieerd, de casco's zijn daarop afgestemd en de elementen die de casco's hun vorm geven zijn daarvoor geprefabriceerd. De gevels en de daken zijn ook geprefabriceerd en kunnen indien gewenst in verschillende kleuren en uitvoeringen worden geleverd. Het koppelen van het geheel vereist geen daadwerkelijk vakmanschap alleen een zekere geoefendheid. 12 De aankleding van het huis, leidingen afvoeren deuren ramen enz. enz. zijn er in verschillende uitvoeringen al naar gelang de keuze van de gebruiker/bewoner. Daadwerkelijk vakmanschap is vereist als deuren niet juist sluiten, afvoeren lekken of speciale wensen dienen te worden opgevolgd. Dit wordt direct, dus `in het werk', opgelost en van de klachten/wensenlijst afgestreept, eventueel als meerwerk. Het bouwproject wordt gemeten en gecalculeerd in `bouwbare dagen' en niet beheersbare zaken als `het weer' wordt uitgesloten. Specifieke zaken per woning worden in een gebruikshandleiding opgenomen, vervanging na verloop van jaren van onderdelen is relatief eenvoudig, typenummers, uitvoeringen en maatvoeringen zijn bekend. Een dergelijk bouwproject wordt in de meeste gevallen naar tevredenheid opgeleverd. Dit in tegenstelling tot softwareprojecten. Refererend aan de titel van deze verhandeling is auteur dan ook van mening dat de Object Orientation in maatwerk- en tailormade software projecten op een lokaal niveau vaker een doel op zich is dan het middel waarmee succesvol softwarebouw projecten worden gerealiseerd. De kans op het stranden van projecten door het te lang aanhouden van de principes van de `zuivere' gedachte is veel groter bij Object Oriented aanpak dan bij de Component Based aanpak. Het bouwen van een oplossing dient nooit het doel op zich te worden maar altijd het middel te blijven waarmee door gebruik ervan de vooraf gestelde voordelen worden gerealiseerd. 13 Over Magic Software Enterprises Magic Software Enterprises (NASDAQ: MGIC) levert wereldwijd sterk intuïtieve en intelligente oplossingen aan eindgebruikers en partners voor de inrichting van bedrijfslogica en -informatie middels meerdere uitvoerkanalen. We kunnen bogen op 30 jaar ervaring, miljoenen installaties wereldwijd en strategische allianties met internationale IT-leiders, waaronder IBM, Microsoft, Oracle, Salesforce.com en SAP. Hierdoor kunnen onze klanten naadloos nieuwe technologieën implementeren en hun zakelijke kansen optimaal benutten. Magic Software Enterprises levert een Metadata Driven Framework als bij afbeelding 6 beschreven. Bezoek www.magicsoftware.com voor meer informatie. Magic is a registered trademark of Magic Software Enterprises Ltd. All other product and company names mentioned herein are for identification purposes only and are the property of, and might be trademarks of, their respective owners. Magic Software Enterprises has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. Magic Software Enterprises assumes no responsibility for errors or omissions that may occur in this document. The information in this document is subject to change without prior notice and does not represent a commitment by Magic Software Enterprises or its representatives. 14
Uitgelichte Whitepaper

Computable Onderzoek: Enterprise Mobility 2014

Computable Onderzoek: Enterprise Mobility 2014

Ongeveer de helft van de organisaties heeft Enterprise Mobility als speerpunt, zo blijkt uit dit Enterprise Mobility 2014 onderzoek uitgevoerd door Computable/Jaarbeurs. Niet verwonderlijk, want het geeft flexibiliteit, snelheid in bedrijfsprocessen en betere...

Citrix
Whitepapers nieuwsbrief

Wil je op de hoogte blijven van welke whitepapers er zijn toegevoegd aan de Computable IT Knowledgebase? Abonneer je dan op de gratis nieuwsbrief.