Waarom en hoe te beginnen? Model Driven Development Waarom en hoe te beginnen? V5 20131009

Inhoud Wat is MDD? Hoe aanpakken Redenen voor MDD Back-up slides

Wat is MDD? Op basis van een functioneel model wordt automatisch (een deel van) de applicatie gerealiseerd, of door codegeneratie of door modelinterpretatie: Functioneel model: bijvoorbeeld in UML. Klassen, use cases, activity diagrams,… Automatisch: bijvoorbeeld elke klasse wordt een tabel. Dus uit het functionele model kunnen de tabellen gegenereerd worden. Applicatie: die waar men zich op wil richten. Codegeneratie: voor elke programmeertaal mogelijk Modelinterpretatie: het functionele model wordt runtime ingelezen en uitgevoerd.

Hoe aan te pakken Atom Free IT automatiseer het automatiseren

De gemiddelde bedrijfsapplicatie Ondersteunt een administratief bedrijfsproces Waarin verschillende mensen taken moeten uitvoeren Verwerkt data die aan bedrijfsregels moet voldoen Moet secure, functioneel aanpasbaar, zo snel mogelijk klaar, altijd beschikbaar en goedkoop zijn. Heeft een webinterface Heeft een database Is gekoppeld aan andere applicaties volgens vaste protocollen (default: webservices) Wordt door een projectteam gemaakt Beheertaken worden bij voorkeur ad hoc toegewezen Pas aan en zoek een project dat hier bij past

Typische softwarekandidaten voor MDD voor een bedrijfsapplicatie Technische elementen scheiden van de functionele. Denk aan beheerschermen, zoekschermen, selectieschermen, standaard adminstratiefscherm, transacties Database creatie Database ontsluiting Web forms GUI panels Business logica afhandeling Service interfaces Workflow control Standaard functionals: autorisatie, foutafhandeling, logging, … Standaard non-functionals die in de code hun neerslag vinden: security, SIG ****, …

Het gemiddelde besturingssysteem (control system) Is een meet-en-regelsysteem Meet input en output en legt/kent daar relaties tussen Zet besturingsparameters Waar verschillende mensen verschillende views op hebben. (van onderhoudsmonteur tot marketing manager) Stuurt hardware aan: Met besturingsparameters met timingrestricties en <100% up-time Met een gedefinieerde interface Met een kostbare vervanging en hoge investering Moet data leveren aan andere (software)systemen (voor administratie, workflow management, …) Realiseert een trade-off tussen verschillende systeemkwaliteiten (al dan niet expliciet) Is gebaseerd op kennis van meerdere specialisten met eigen technische specialismen Wordt door een projectteam gemaakt (evt met subteams) Wordt beheerd door een team dat verantwoordelijk is voor meerdere systemen. Moet functioneel aanpasbaar, zo snel mogelijk klaar, altijd beschikbaar en goedkoop zijn. Pas aan en zoek een project dat hier bij past

Typische softwarekandidaten voor MDD voor een control system Hardware besturing (bv. Patronen voor aanroepen, foutafhandelingen, uitval van hardware) Dataopslag, -toegang en -export Afhandeling van meet- en regellogica Interfaces voor workflow control, onderhoud, control applications, metrics,… Standaard functionals: foutafhandeling, logging, … Standaard non-functionals die in de code hun neerslag vinden: security, functionele integriteit, robuustheid. Simulatie van al het bovenstaande. In principe al de plaatsen in de software waar vaste eigenschappen gecombineerd worden met variabele eigenschappen. (Dat is bijna overal, maar niet overal in dezelfde mate) Overal waar de dure schaarse (domein)experts impact hebben op veel code.

Randvoorwaarden MDD framework vereist commitment van betrokkenen: Sales , Requirements engineers, Informatieanalisten, Functioneel Ontwerpers, Solution & Technisch Architecten, Ontwikkelaars , Projectleiders , Testers, Delivery mgt, business mgt, SEC. Eigenaarschap op applicatieoverstijgend niveau Een MDD framework is een oplossing voor een business probleem, niet voor een technisch probleem. Ontwikkeling en beheer MDD framework scheiden van uitvoering van projecten. In projecten: MDD framework inbedding bij start (voor Agile: Sprint 0)

Aan de slag Keuze maken: Pilot: Zelf bouwen (klein beginnen, uitbouwen) Bestaande oplossing adopteren en (evt) doorontwikkelen? Tobago MDA (ADF Community, geïnitieerd door Capgemini), zie: http://www.accelerateddeliveryplatform.com/ Be-Informed, Mendix, etc. Onderzoek opties (project brief/business case)? Pilot: Scope (stereotype projecten/technologie) Lever bewijs (haalbaarheid/resultaten) Plan implementatie/vervolg

Aanpak voor pilotproject Op applicatieniveau: Pilot project selecteren Afstemmen met FO Afstemmen met testen projectprogrammeurs opleiden in MDD denken en doen (d.m.v. coaching). Herbruikbare code identificeren. Keuzes in bestaande templates/components/generators. Tbv evaluatie: projectactiviteiten die projectspecifiek zijn scheiden van niet projectspecifieke activiteiten.

Aanpak Op applicatieniveau: Pilot project FO aanpak uniformeren. Bijv. UML en extensies daarop. Beginnen met een gedeelte van FO. projectprogrammeurs opleiden in MDD denken en doen (d.m.v. coaching). Herbruikbare code identificeren. Keuzes in bestaande templates/components/generators. Op projectoverstijgend (programma of business line) niveau: MDD framework team inrichten. projectbegroting scheiden van offerte Meer details over aanpak in framework initiatief.

Aanpak: 3 parallelle sporen Business impact: Invulling marketing/business expliciet maken  gedeeld beeld over de markt (=typische klantvraag) en dus framework geschiktheid. Redenering: een framework is een business asset die geschikt is voor bepaalde soort software en ontwikkelwerkwijze Framework inhoud: Framework technologie koppelen aan businesscycle en ontwikkelproces/-organisatie Inhoudelijke consistentie en levend houden Werkwijze aanpassen: Projectwerkwijze met framework expliciet maken Mindset betrokkenen Framework is business asset Titel van .2 dekt lading niet helemaal, gaat niet (alleen) over ‘inhoud’, misschien ‘exploitatie’??

Spoor 1: business impact Marktbeeld opstellen: wat is typische business vraag? Eerst op basis van ervaring (historie) in projecten : Technisch architecten, Solution architecten, projectleiders business in de lead brengen. (techneuten moeten niet in de lead zijn mbt de typische klantvraag) Onderscheid tussen vast en variabele expliciet maken. MT eigenaar en budgetering Centraal Management moet eigenaar zijn! Welke functionaliteit (business) in de toekomst? (voor de roadmap)

Spoor 2: Framework inhoud Uit de hobbysfeer (niet afhankelijk van een bereidwillige techneut): Kernarchitect Business owner Beginnen met verzamelen (meestal bestaan er al onderdelen) Technisch architecten, programmeurs, functioneel ontwerpers Roadmap opstellen voor uitwerken framework Beginnen bij identificeren van framework elementen Deliverables definiëren: Zodat projecten framework kunnen uitwerken Zodat beschikbare mensen altijd kunnen bijdragen Aansluiten bij spoor 3

Spoor 3: werkwijze aanpassen Projectwerkwijze met framework expliciet maken. Van business analyse tot en met beheer: Acquisities: match tussen functionele scope en framework Projectstart: wat wel/niet uit framework gebruiken Projecteind: wat wel/niet naar framework brengen Beheer: frameworkbeheer scheiden van applicatie-/productbeheer (=instantiebeheer) Mindset betrokken: standaardisatie Marketing/business: Applicaties/producten die beter passen bij het framework zijn goedkoper en sneller te ontwikkelen Ontwikkelaars: Herbruikbaarheid en framework compatibiliteit Projectleiders: Herbruikbaarheid als projecteis Framework is asset op projectcalculatie en IT-begroting  Software development is niet de sluitpost en de bugfixer, maar de enabler en versneller.

Hoe aanvliegen: Business impact: Marktbeeld opstellen (=typische functionele vraag) Eerst op basis van architectenervaring in projecten business betrekken (en in de lead brengen) MT eigenaar en budgetering Framework beheer: content verzamelen Technisch architecten beginnen: Framework architect is lead Later ook FOn en PL. Project support office kan administratie doen. Werkwijze: Projectstart en projecteind aanpassen in het proces. Op centraal niveau trekken (solution architecten). Want alleen code en tools zijn technologiespecifiek.

Redenen voor MDD Atom free IT automatiseert het automatiseren

Gegenereerde code is gemiddeld beter Omdat er minder mensen nodig zijn om dezelfde functionaliteit te bouwen kan meer tijd besteed worden om het handmatige werk te perfectioneren. Elk stuk code zit op dezelfde manier in elkaar: Een ontwerpfout komt dus overal voor en wordt veel eerder ontdekt en veel sneller opgelost. Het is goedkoper om iemand in te werken omdat er minder variatie in programmastructuur zit.

Minder complexe taken Een functioneel ontwerper kan zich focussen op functioneel ontwerpen in een FO-taal. Een programmeur kan zich focussen op programmeertaal en hoeft het functioneel ontwerp niet functioneel te begrijpen. Een architect kan zich focussen op de architectuur en minder op de borging ervan. De klant/business kan zich focussen op klantbehoeften en hoe het systeem dat invult en niet op de communicatie met mensen die hem toch niet begrijpen (omdat ze een heel ander jargon spreken) Alleen nog maar testen met de klant en niet meer intern: validatie ipv verificatie.

Het aantal regels code per programmeur per jaar is constant Gegeneraliseerd: het aantal beslissingen (van een bepaalde soort) dat een mens per jaar kan nemen is constant. Om applicatieproductiviteit te maximaliseren is het slim om te programmeren in een taal die dicht tegen applicatiedomein aan zit Dit is de basisgedachte achter domain specific languages. Om kwaliteit te maximaliseren en te garanderen is het zinvol om oplossingen te programmeren die zo direct mogelijk die kwaliteit bepalen. Kwaliteitseisen zijn stabieler dan functionele eisen. Dit is de basisgedachte achter “Aspect oriented design/programming” Om het maken van fouten te minimaliseren is het goed om het aantal (menselijke) beslissingen te minimaliseren. Dit is de gedachte achter “model driven development” Het combineren van het bovenstaande vraagt om een sterk conceptuele en mathematische aanpak. Het gevolg: Een paar goede abstracte denkers Een grote betrokkenheid van experts van applicatiedomein tijdens project en kwaliteitsdomein (bijvoorbeeld, performance, security) over projecten heen. Heel weinig programmeurs (factor 10 minder en om te beginnen factor 5) Richtlijn: codeer de dingen die stabiel zijn, parametriseer daarbinnen de dingen die instabiel (variabel) zijn Sogeti Nederland B.V.

NU: een lange foutgevoelige weg Een domein expert(klant) zegt: een product heeft een productnr Een reqs engineer/ info-analist schrijft op: een product heeft een productnr” Een (functioneel) ontwerper tekent een klassendiagram waarin een klasse product een productnr heeft Een programmeur programmeert een java-class product met attribuut productnr Een tester maakt een testcase om te kijken of een product een productnr heeft Een gui ontwerper tekent een productinvoerscherm met een veld productnr De databaseontwerper definieert een tabel product met kolom productnr 3 maanden later ziet de klant het resultaat en zegt: dat een productnummer ook letters kan bevatten 1 maand later is dat verwerkt

Automatiseer het ontwikkelen Mensen (ontwikkelaars): Maken fouten Hebben ambities en een agenda Vinden het vervelend om telkens hetzelfde te doen en leuk om nieuwe dingen te bedenken Werken allemaal anders en onvoorspelbaar Machines (software): Doen dingen foutloos Hebben geen ambities of goede/slechte dagen Zijn heel goed en snel in hetzelfde doen op elk gevraagd moment Hebben alleen gespecificeerde verschillen Laat Machines werken en Mensen denken

MDD: van requirement naar resultaat Een analist onderkent en modelleert samen met de klant dat een businessklasse product een eigenschap productnr heeft. De codegenerator zorgt voor: Een productscherm met een veld productnr Een producttabel met kolom productnr komt Een class voor de afhandeling van productlogica De koppeling tussen het scherm, class en tabel De klant ziet dezelfde dag nog op het scherm dat het productnr ook letters kan bevatten, hetgeen diezelfde dag nog aangepast is.

Functionaliteit vs. kosten Functionaliteit (Fp) huidig traject MDD traject

Meerdere trajecten (incl. bouwen aan engine) Kosten Functionaliteit (Fp) huidig trajecten MDD trajecten

Meer tijd voor de business Voordelen MDD Kwaliteit: Early feedback => minder impact door foute requirements (beating Boehm) Hergebruik van denkwerk (best practices) Domeinexpert kan in eigen taal communiceren Garanderen softwarearchitectuur door automatiseren Efficiëntie: Significant deel van het werk wordt snel en foutloos gedaan Uren per functiepunt veel minder door hergebruik Minder testen door generatie en Model Based Testen Sourcing: Programmeurs minder kennis van applicatiedomein nodig  klantkennis minder belangrijk Structuur van applicaties uniform  inleertijd veel korter Het “domme werk” wordt (foutloos) gedaan; uitdagend werk blijft. Generator code kan off-site ontwikkeld worden Minder tijd voor maken  Meer tijd voor de business

Back-up slides Atom Free IT automatiseert het automatiseren

Framework based development

Tussen Framework en applicatie

Past and future of sofware development

Voorbeeld (o.b.v. Tobago MDA) Code generator Bron: http://www.accelerateddeliveryplatform.com/

Aandachtspunten implementatie MDD raakt alle betrokkenen in hun werkwijze: Requirements Analisten/ informatie-analisten Functioneel Ontwerpers Solution & Technisch Architecten Ontwikkelaars Projectleiders Testers IT mgt Begroters Agile uitvoering/besturing van projecten. Ontwikkeling MDD framework scheiden van uitvoering van projecten.

Aanleiding Significante verbetering van productiviteit nodig Klantwaarde: werkende oplossingen die voldoen aan verwachtingen/afspraken: functionele requirements en vooral ook non-functionele requirements op gebied van security, onderhoudbaarheid (SIG) etc. Doorlooptijd staat onder druk  snelheid omhoog Marges onder druk  kosten omlaag Productiviteit = effectiviteit x efficiëntie

Hoezo MDD? Gebruik 1 bron (het functionele model) Uniformeer/automatiseer vertaalproces Stop vast gedeelte in MDD framework  Minder fouten, minder tijdrovend

Wordt geleverd door (very short list) Partner Mendix, MDD wordt toegepast in hun Sofware development en maintenance center Partner van Mendix, Tobago, MDD collaboration project with Bancaja Partner van Mendix, o.a. registratiesystemen voor ProRail Initiator van Mod4J Open source MDD engine voor Java Verschillende producten en Consultancy diensten rond MDD MDD ingebakken in hun product, “Agile Business Suite” MDD als core aanpak en toolset voor al hun ontwikkelingen.

Wordt gebruikt door…. (very short list) MDD breed toegepast MDD wordt vandaag de dag al breed toegepast bij verschillende bedrijven. (Potentiële) klanten gaan daarvoor naar leveranciers om een MDD oplossing te krijgen voor hun applicatiebehoeften RBS, Agis, Bouwfonds, Mamoet, HST, Kwik Fit, De telegraaf, We, Achmea, General Electric, Marlies Dekker, Roche, Sandd, Detail Result, Menzis, Belastingdienst, Douane, Genzyme, Arch, Sanoma Uitgevers, Lockheed Martin, General Motors, Visiro, Curalis, Career Centre, DebtorOnline, Bekaert Textile Group, Dindirect, Openbaar Ministerie, IND, Raad voor de Rechtsbijstand, Logius, Overheidsbrede zoekdienst, CAK, Ministerie van VWS (Regelhulp), Centraal Beheer Achmea, ABN AMRO , Delta Lloyd, Eureko, 2-in-1 Car Insurance, Kadaster, ProRail, Post NL, KLM/Air France, Agis, Samsung, IBM, Ordina, Unisys, Atos, Cap Gemini, Centric, Bancaja Klant van Novulo, Planning software voor vliegtuigreparaties Klant van Mendix, International claim handling, Klant van Mendix. MDD ook toegepast voor o.a. het maken van software voor automatische tram besturing. Ondersteund door IBM bij het inrichten van een MDD software straat die voor o.a. software in Opel Ampera Verschillende registratiesystemen gebruikmakend van Mendix Klant van (IBM Rational), o.a. voor het genereren van drivers voor productlijn van printers Klant van Mendix, Risc management, Billing en intercompany settlements Klant van Be Informed. Polis beheer en claimafhandeling voor verzekeringen.

Codegeneratie Code generator Systeem Test documen- Scripts tatie (MBT) Software conform architectuur Optioneel ook Systeem documen- tatie Test Scripts (MBT)