Kennisdeling op het gebied van softwarearchitectuur

Maat: px
Weergave met pagina beginnen:

Download "Kennisdeling op het gebied van softwarearchitectuur"

Transcriptie

1 architectuur t Kennis delingsproblematiek bij Océ Kennisdeling op het gebied van architectuur In ontwikkeling is vaak sprake van een spanning tussen een top-down, door architectuur gedreven aanpak en een bottomup aanpak waarin de ontwikkeling van nieuwe producten onder druk van de markt prevaleert. De documentatie is minimaal, maar een zekere hoeveelheid is toch nodig om mensen effectief aan te sturen: de juiste kennis moet op het juiste moment wel bij de juiste mensen aanwezig zijn. Binnen Océ Technologies wordt onderzoek gedaan naar deze problematiek rond kennisdeling. Sybren Deelstra, John Kesseler, Antony Tang en Hans van Vliet Architecten moeten veel kennis delen, met elkaar, maar ook met ontwikkelaars, testers, configuratiemanagers en dergelijke. Deze mensen echter willen eigenlijk een architectuur maken en ontwikkelen en testen en zijn niet snel bereid hun kennis vast te leggen. Veel van die kennis blijft daardoor impliciet. Dit geldt temeer in agile omgevingen. Daar treedt een inherente spanning op tussen top-down sturing via voorschriften en architectuurspecificaties en bottom-up oplevering van nieuwe features. Met name in een multi-siteomgeving kan het gebrek aan expliciete documentatie gemakkelijk tot misverstanden leiden. In dit artikel wordt beschreven hoe binnen Océ Technologies wordt omgegaan met de problematiek rond kennisdeling op het gebied van architectuur. Spanning tussen top-down en bottom-up aanpak In de meer klassieke ontwikkelaanpakken wordt architectuur als heel belangrijk gezien. In pure agile benaderingen worden architectuur en dikke documenten als overbodige ballast gezien, want alles zal uiteindelijk toch anders worden. Zoals zo vaak ligt de waarheid ergens in het midden en dus ontstaan er pogingen deze twee ogenschijnlijke tegenpolen met elkaar te verenigen (IEEE Software, 2010). Ook binnen Océ speelt deze problematiek. Ook hier is de druk van de markt erg aanwezig en is er de neiging om nieuwe producten te ontwikkelen via aanpassing van een reeds bestaand product. Océ opereert in een sterk door technologie gedomineerde markt, waar ingenieurs gedreven zijn om steeds nieuwe technische snufjes aan te bieden. Ontwikkelaars zullen dan moeite hebben een architectuurgedreven masterplan te volgen. Dit wordt nog eens versterkt door de gehanteerde agile ontwikkelmethode (Scrum), waarin kwaliteits- en ontwikkeldoelen voor de korte termijn het denken domineren. Er ontstaat dan een spanning tussen een nette top-down, door architectuur gedreven aanpak en een bottom-up benadering waarin de ontwikkeling van nieuwe producten onder druk van de 48

2 Samenvatting In een dynamische omgeving zoals die van Océ is kennisdeling op het gebied van architectuur zelf ook dynamisch. Welke kennis wanneer en met wie gedeeld moet worden, kan verschillen per project, per vestiging en per punt in de tijd. Om optimaal in te spelen op veranderingen is een dynamische terugkoppeling nodig van informatie over wat gedeeld wordt en welke effecten dit heeft op productiviteit en kwaliteit. markt prevaleert. De documentatie is minimaal, maar een zekere hoeveelheid is toch nodig om mensen effectief aan te sturen: de juiste kennis moet op het juiste moment wel bij de juiste mensen aanwezig zijn. In het kader van de regeling Kenniswerkers (zie onderzoekt een dertigtal medewerkers van Océ deze kennisdelingsproblematiek in samenwerking met onderzoekers van de Vrije Universiteit. In een aantal kleinere deelprojecten komt een breed scala aan onderwerpen aan de orde, zoals: Hoe te bepalen of, en wanneer, een architectuurgedreven aanpak de voorkeur geniet boven het klonen van een bestaand product? Wat moet een architect allemaal vastleggen en wat kan hij overlaten aan ontwikkelaars? Welke kennis moet er gedeeld worden tussen vestigingen in verschillende landen? Hoe te zorgen dat de informatie uit steeds veranderende eisen en architectuurdocumenten traceerbaar blijft? Hoe te zorgen dat strategische informatie bij de juiste betrokkenen bekend is? In een snel veranderende omgeving als die bij Océ ligt het niet voor de hand dat de oplossing voor dit soort vraagstukken eenduidig en statisch is. Kennis over de architectuur, fouten en hun oorzaken, kosten en baten van beslissingen dient verzameld en gedeeld te worden in een feedback loop die betrokkenen in staat stelt continu te monitoren en waar nodig bij te sturen. In het vervolg van dit artikel zullen we enkele voorbeelden van dit soort feedback loop geven. Agile ontwikkelen bij Océ Océ produceert onder meer een breed scala aan printers voor de zakelijke markt. Software speelt in deze printers een belangrijke rol. Deze zorgt voor het weergeven van beelden en stuurt de print-engine aan. Océ opereert in een zeer competitieve markt waar het tijdig leveren van nieuwe diensten een belangrijke succesfactor is. Om dit te bewerkstelligen wordt een agile ontwikkelproces gevolgd (Scrum), aangestuurd door een architectuurorgaan. Softwareontwikkelaars opereren veelal in teams van drie tot acht mensen. Aan de ontwikkeling van een nieuw product neemt een flink aantal teams deel, plus architecten, integrators en testers. Een ontwikkelcyclus duurt vrij kort. Elke acht weken is er een nieuwe versie van een product, met sprints van twee weken. Ontwikkelaars zijn zeer gemotiveerd en hebben veel domeinkennis. De documentatie is minimaal. Er heerst een op innovatie gerichte cultuur, waarbij de meest geschikte mensen aan taken worden toegewezen. Mensen rouleren regelmatig tussen projecten. Wat levert hergebruik op? De vraag hier is wanneer een door architectuur gedreven ontwikkeling van gelijksoortige producten (een zogenoemde productlijn) de aangewezen weg is en wanneer men beter snel een nieuw product kan ontwikkelen door een bestaand product aan te passen. Ter illustratie van de hier optredende spanning gebruiken we een component van de besturings van printers. De betreffende component (Printer Controller Component, PCC) beheert de printopdrachten die naar een printer zijn verstuurd. Hoewel PCC specifiek gedrag vertoont per product, moet deze component ook consistent gedrag vertonen richting de print-engine en de operator. Twee belangrijke onderdelen hierin zijn het behandelen van runtime tegenstellingen (RTC) en het behandelen van fouten zoals het vastlopen van papier. Een RTC treedt op als de printer tijdelijk stopt met printen omdat bepaalde resources op zijn. Voorbeelden hiervan zijn: een bepaalde invoerpapierlade is leeg, de uitvoerlade is vol, de nietjes zijn op. De besturings moet de RTC ontdekken en doorgeven en handelen naargelang de mogelijkheden van de betreffende printer. 49

3 architectuur t PCC-1 PCC-4 CAB specifieke kosten hergebruikkosten totale kosten Figuur 1. Relatieve kosten voor ontwikkelen met en zonder productlijnarchitectuur In de afgelopen vier jaar zijn vier versies van PCC ontwikkeld. PCC-1 is van de grond af opnieuw ontwikkeld. PCC-2 werd min of meer tegelijk met PCC-1 ontwikkeld ten behoeve van een nieuwe reeks producten en hierin werd waar mogelijk de codebase van PCC-1 hergebruikt. Hetzelfde geldt voor PCC-3. PCC-2 en PCC-3 zijn dus klonen van PCC-1. Een belangrijke reden om te kiezen voor klonen was de verwachting dat de ontwikkeling van een gemeenschappelijke architectuur voor al deze producten te veel tijd zou kosten. Vrij snel nadat het werk aan PCC-3 was begonnen, deed zich een verschuiving voor in de prioriteiten van de business. Tevens werd duidelijk dat de gehanteerde aanpak de zaak steeds complexer maakte, en minder onderhoudbaar. Daarom werd besloten via een productlijnaanpak de ontwikkeling van PCC-4 te starten. Deze beslissing werd lokaal genomen, door een enkel productteam, met steun van het management. De vraag is nu of de architectuurgedreven aanpak (PCC-4) de voorkeur moet genieten boven de door klonen gedreven manier van werken als in PCC-1, PCC-2 en PCC-3. Er kunnen verschillende redenen zijn waarom men aarzelt over te gaan op een door een productlijnarchitectuur gedreven aanpak. Maar uiteindelijk is geld natuurlijk een belangrijke factor. Het is dan ook nodig om als organisatie te weten wat de financiële voordelen zijn. In een simpel model (Clements, McGregor & Cohen, 2005) bestaan de kosten uit: Core Asset Base (CAB), de kosten voor het eenmalig ontwikkelen van de herbruikbare core assets; specifieke kosten voor het ontwikkelen van specifieke features boven op de CAB; kosten voor het hergebruiken van CAB voor elk nieuw product (extra tests die nodig zijn, eventueel lokale aanpassingen aan CAB enzovoort). Voor PCC-1 en PCC-4 zijn deze drie soorten kosten (in fictieve eenheden, waarbij de totale kosten voor PCC-1 op 100 zijn gesteld) op een rijtje gezet in figuur 1. Hieruit blijkt dat investeren in een productlijnarchitectuur de moeite waard kan zijn. In de figuur zijn twee effecten zichtbaar. De lagere (initiële) CAB-kosten voor PCC-4 ten opzichte van PCC-1 zijn voor een belangrijk deel te verklaren uit het leereffect omdat dezelfde functionaliteit voor de tweede keer werd gebouwd. Overigens is de ontwikkelinspanning van PCC-2 en PCC-3 niet geadministreerd, vandaar dat deze niet in de figuur te vinden is. Het andere effect is nog groter: de winst als gevolg van de productlijnaanpak zit vooral in de lagere hergebruikkosten, in dit geval vooral de lagere kosten voor benodigde tests. Om te kunnen bepalen of het de moeite waard is van de ene vorm van ontwikkeling over te stappen naar de andere is kennis nodig, en deze kennis moet gedeeld worden met de juiste partijen. Op technisch niveau moeten architecten en ontwikkelaars weten wat de principes van productlijnarchitectuur zijn en of die toepasbaar zijn in hun specifieke omstandigheden. Kosten en opbrengsten moeten gemeten worden om het besluitvormingsproces op zowel technisch niveau als managementniveau te ondersteunen. De terugkoppeling van deze kennis, zoals ontwikkeld in het lopende kenniswerkersproject binnen Océ, wordt geschetst in figuur 2. Het op het juiste moment delen van kennis tussen betrokkenen kan veel van de spanning tussen een wel of niet architectuurgedreven aanpak wegnemen. Dit is een iteratief proces. Eenmaal genomen beslissingen kunnen immers onder invloed van marktwerking, nieuwe technologie of andere mensen veranderen. Hoeveel moet de architect vastleggen? De specificaties die een architect maakt, kunnen verschillen qua detailleringsniveau. Waarom sommige details in de ene specificatie wel worden opgenomen en in de andere niet, is niet altijd duidelijk. Of het nodig is die details op te nemen, is eveneens niet altijd duidelijk. Het gevolg hiervan kan zijn dat ontwikkelaars beslissingen nemen die leiden tot fouten. Deze komen vervolgens als een soort boemerang terug bij de architect in de vorm van probleemrapporten waarop de architect 50

4 een reactie moet geven. Deze komen bij de architect terecht omdat de ontwikkelaar bijvoorbeeld geen eigenaarschap voelt voor een oplossing die de architect in zijn ogen vergeten is te specificeren, of omdat de oplossing voor de problematiek meerdere onderdelen van de betreft. De architect kan om verschillende redenen besluiten bepaalde beslissingen niet expliciet vast te leggen: Het kan hem niet schelen: elke oplossing voor een bepaald issue is wat hem betreft even goed. Het is (in zijn ogen) vanzelfsprekend welke optie(s) de ontwikkelaars hebben, bijvoorbeeld omdat iets soortgelijks al in een eerder product voorkomt. Hij heeft geen tijd om alle details vast te leggen. Het is de persoonlijke voorkeur van de architect. Als een architect bij herhaling werkt met hetzelfde team van ontwikkelaars, zal er na verloop van tijd een vorm van samenwerking ontstaan die goed werkt: de architect legt vast wat belangrijk is en weet wat hij veilig aan de ontwikkelaars kan overlaten. Kennisdeling treedt op waar dat nodig is en wordt achterwege gelaten waar het niet zinvol is. De situatie binnen Océ is echter niet statisch. Ontwikkelaars rouleren tussen projecten. Nieuwe producten en nieuwe technologieën vragen om nieuwe oplossingen. Wat vandaag vanzelfsprekend is, is dat morgen niet meer. Wat bij het ene project probleemloos loopt, gaat bij een ander project veel minder vlekkeloos. Ook hier ligt een feedback loop voor de hand, bijvoorbeeld door tijdens ontwerp bij te houden welke beslissingen aan de ontwikkelaars worden overgelaten en een root-cause-analyse uit te voeren op gevonden fouten tijdens ontwikkeling en na release. Zo wordt niet alleen de werkwijze verbeterd, maar leert de architect ook waar hij meer kennisdeling nodig heeft. Kennisdeling tussen vestigingen De van Océ wordt bij verschillende vestigingen ontwikkeld. De hoofdvestiging is in Venlo en daarnaast wordt een deel van de ontwikkeld in onder meer Roemenië en Frankrijk. De vestiging in Venlo is beduidend groter dan die in Roemenië en Frankrijk. De vraag is of de mate van kennisdeling tussen de hoofdvestiging in Venlo en de vestigingen in Roemenië en Frankrijk van invloed is op de kwaliteit (gemeten in termen van productiviteit, aantal gevonden fouten en dergelijke). Het onderzoek door medewerkers van de VU en Océ brengt aan het licht dat dit niet het geval is. De interviews en data-analyse laten duidelijk zien dat Océ de afstandsbarrière succesvol overbrugd heeft, via diverse wegen: Betrokkenen kennen elkaar goed. Er zijn veel persoonlijke contacten. Er is zowel gestructureerde communicatie in de vorm van regelmatige bijeenkomsten als ongestructureerde communicatie via bijvoorbeeld de telefoon. Men deelt kennis vrijelijk. De platte organisatiestructuur bevordert de communicatie tussen vestigingen. management strategy management level decisions technical and product roadmaps development methodology architectural level decisions legacy architecture product line architecture refactoring cost maintenance cost time-to-market neu quality Figuur 2. Kennisfeedback-loop bij productlijnontwikkeling neu new investment 51

5 architectuur t Wel valt op dat veel kennis in de hoofden van mensen zit. Door de veel langere historie van de vestiging in Venlo en het feit dat die vestiging veel groter is, is daar de meeste kennis, en veel van die kennis is voor de betrokkenen aldaar vanzelfsprekend. Die kennis hoeft dus niet expliciet gedeeld te worden. Zodra die kennis belangrijk wordt voor een andere vestiging, is aandacht geboden. Naarmate de tijd voortschrijdt, neemt de kennis bij de andere vestigingen toe en treden er minder issues op die te wijten zijn aan het ontbreken van deze zogenaamd vanzelfsprekende kennis. Maar dit kan ook tot gemakzucht leiden, waarbij bijvoorbeeld essentiële kennis over nieuwe technologieën niet gedeeld wordt waar dat nu juist wel van belang is. Een feedback loop om dit soort problemen te verminderen kan klein beginnen. Een concrete invulling is om resultaten van technologieonderzoeken op te nemen in het maandelijks afdelingsverslag en dit verslag ook met de andere vestigingen te delen. Andere voorbeelden zijn kennis over besluitvorming een vast onderdeel te maken van de reguliere retrospectives of planningen ook rond te sturen naar de teams waar niet direct in hetzelfde project mee wordt samengewerkt. Kennisdeling via een semantische wiki Eisen- en architectuurdocumenten kunnen gemakkelijk conflicterend en inconsistent zijn of dat in de loop der tijd worden. Hiervoor zijn ten minste drie redenen te noemen. Ten eerste is kennis verspreid. Er zijn veel belanghebbenden betrokken bij systeemontwikkeling en elk van die belanghebbenden weet slechts een deel. Marketingmensen weten wellicht wat ze willen, maar niet hoe dat gerealiseerd kan worden. En voor architecten geldt vaak het omgekeerde. Er zijn nogal wat mensen betrokken bij het specificeren van de eisen: marketingmensen, businessmanagers, technologiespecialisten enzovoort. De architectuur wordt bepaald door onder anderen architecten, netwerkspecialisten en securityspecialisten. Een dreigend gevaar hiervan is dat de specificaties die door beide groepen mensen worden opgesteld, conflicterend en inconsistent kunnen zijn. Ten tweede is de informatie niet volledig. Niet alle informatie wordt expliciet vastgelegd en is vindbaar. Sommige kennis blijft alleen in de hoofden van direct betrokkenen. Conflicten tussen eisen en architectuur kunnen zo lang verborgen blijven. Ten derde zullen eisen en architectuur vaak tegelijkertijd evolueren. Door onderhandelingen, beslissingen en het zoeken naar oplossingen evolueren de eisen en ook het inzicht in hoe deze kunnen worden gerealiseerd. Businessmanagers bijvoorbeeld kunnen prestatie-eisen formuleren waarvan pas na analyse door een architect blijkt dat ze niet haalbaar zijn. Het gevolg is dat ze moeten worden aangepast. Als gevolg van dit alles zullen de ontwikkeling van eisendocumenten en de ontwikkeling van architectuurdocumenten elkaar in tijd overlappen. Om belanghebbenden in staat te stellen te communiceren over relaties en conflicten tussen deze twee typen documenten, is het dus nodig dat eisen en de bijbehorende architectuuronderdelen wederzijds traceerbaar zijn. Hier zijn al de nodige oplossingen voor bedacht, maar die leveren steeds statische verbindingen tussen eisen en architectuur. Dat leidt natuurlijk tot problemen als beide typen documenten blijven veranderen. Bij Océ experimenteren we daarom met een semantische wiki om traceerbaarheid tussen veranderende eisen- en architectuurdocumenten te ondersteunen. We gaan hierbij uit van een algemeen metamodel dat vijf sleutelconcepten kent: identificatie van een document gebruikmakend van de Dublin Core-standaard (Powell e.a., 2007); eisen, zowel functioneel als niet-functioneel; belanghebbenden, klassen van mensen die (mede) de eisen bepalen; beslissingen die genomen zijn met betrekking tot de realisatie van eisen; architectuur, zijnde de resultaten van genomen beslissingen. Met behulp van dit model kunnen eisen- en architectuurdocumenten worden geïndexeerd en geannoteerd. Architecten en analisten kunnen met behulp hiervan deze documenten bevragen. Verdere details zijn te vinden in Tang e.a. (2011). Wie vertel ik over roadmaps? De architectuur wordt beïnvloed door toekomstige eisen en technologieën. Deze worden vastgelegd 52

6 in zogenoemde roadmaps. Een roadmap beschrijft voorziene ontwikkelingen op een bepaald terrein, bijvoorbeeld verwachte nieuwe technologiestandaarden of productfeatures die de markt verwacht. Op elk moment in de tijd zijn er binnen Océ Technologies zo n vijftien of meer roadmaps die relevant zijn voor de ontwikkeling van nieuwe producten. Zij komen voort uit verschillende afdelingen van het bedrijf. Enerzijds dient een flink aantal mensen, zoals architecten, integratietesters en managers op verschillende niveaus, op de hoogte te zijn van bepaalde roadmaps om hun werk naar behoren te kunnen doen. Anderzijds dient verspreiding van deze roadmaps zo veel mogelijk beperkt te worden. Ze bevatten immers strategische informatie, die van cruciaal belang kan zijn voor de concurrentiepositie van het bedrijf. Wij hebben onderzocht hoeveel kennis verschillende betrokkenen hebben van de aanwezige roadmaps en hoeveel ze eigenlijk zouden moeten weten. Het blijkt dat geen van de betrokkenen alle roadmaps kent en dat veel betrokkenen minder roadmaps kennen dan ze zouden moeten kennen. Dit leidt tot enkele interessante vragen die momenteel onderzocht worden: Hoe kunnen we een kennisterugkoppelingsmechanisme introduceren dat ervoor zorgt dat de juiste mensen op de hoogte worden gesteld van updates in de roadmaps die hun werk beïnvloeden? Wat is de juiste granulariteit voor dit soort informatie, zodat eenieder genoeg informatie heeft om zijn werk te doen, maar tegelijkertijd om veiligheidsredenen strategische informatie wordt onthouden aan hen die de informatie niet echt nodig hebben. Conclusie Kennisdeling op het gebied van architectuur beslaat een breed terrein. In een dynamische omgeving als die binnen Océ Technologies is kennisdeling zelf ook dynamisch. Welke kennis wanneer en met wie precies gedeeld moet worden, kan per project, per vestiging en per punt in de tijd verschillen. Een dynamische terugkoppeling van informatie over wat gedeeld wordt en welke effecten dit heeft op productiviteit en kwaliteit, is dan ook nodig om optimaal op veranderingen in te spelen. Reviewer Paul Teeuwen Literatuur Clements, P.C., J.D. McGregor & S.G. Cohen (2005). The structured intuitive model for product line economics (SIMPLE). CMU/SEI-2005-TR-003. IEEE Software 27.2 (2010). Special issue on Agility and Architecture. Powell, A. e.a. (2007). Dublin Core Metadata Initiative abstract model, Tang, A. e.a. (2011). Supporting Co-evolving Architectural Requirements and Design through Traceability and Reasoning. In P. Avgeriou e.a. (red.), Relating Software Requirements and Architectures. Springer Verlag. Link Sybren Deelstra is project manager bij Océ. oce.com. John Kesseler is hoofd R&D Software Engineering bij Océ. john. Antony Tang is senior onderzoeker aan de Vrije Universiteit. Hans van Vliet is hoogleraar engineering aan de Vrije Universiteit. dynamische terugkoppeling van informatie over wat gedeeld wordt en welke effecten dit heeft op productiviteit en kwaliteit, is nodig om optimaal op veranderingen in te spelen«53

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling Agile Methodiek en Technologie Zest Application Professionals Hoe is de aansluiting op ontwikkelmethoden voor Legacy-systemen? Out of the Box

Nadere informatie

DevOps Waarom moeilijk doen 31 oktober 2013. als het samen kan

DevOps Waarom moeilijk doen 31 oktober 2013. als het samen kan DEVOPS?! INLEIDING Wat gaan we doen? 18:00 Introductie 19:00 Uitleg open space 19:30 Koffie + start open space 20:30 Wrap-up INLEIDING Even vooraf Samen Duurzaam Innoveren INLEIDING Ik ben Jan Buurman

Nadere informatie

Agile bij grote administratieve systemen. Omgaan met requirements

Agile bij grote administratieve systemen. Omgaan met requirements Agile bij grote administratieve systemen Omgaan met requirements 1 Agenda Wat is een groot systeem? Aanpak van een groot systeem Agile alignment Agile en requirements (en architectuur) Agile en governance

Nadere informatie

Dragon1 EA Tool. Business case webbased EA tool. Een webbased EA tool geschikt voor elke architectuurmethode!

Dragon1 EA Tool. Business case webbased EA tool. Een webbased EA tool geschikt voor elke architectuurmethode! Dragon1 EA Tool Business case webbased EA tool Een webbased EA tool geschikt voor elke architectuurmethode! uw organisatie, datum, versie #.#, documentstatus eigenaar/budgetverantwoordelijke: Kies op deze

Nadere informatie

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 2

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 2 Ontwikkelmethoden en technieken 1 Vandaag Een kleine geschiedenis (vervolg) Klein stukje XP Afbakening verwachtingen 2 Werkwijze theorie Lesstof Presentaties Boek Aantekeningen Introductie/overzicht Week

Nadere informatie

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

Nadere informatie

Systems Engineering en de Modelgebaseerde aanpak. Eric Burgers

Systems Engineering en de Modelgebaseerde aanpak. Eric Burgers Systems Engineering en de Modelgebaseerde aanpak Eric Burgers 2 Context: Toepassing MBSE in tunnelprojecten Modelprecisie / formaliteit LST 1.2 LST 1.1 Nijverdal (2011) SysML Statisch model Dynamisch model

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

De juiste requirements juist

De juiste requirements juist De juiste requirements juist Een voorwaarde voor succesvolle applicatie ontwikkeling Arno van Herk Managing partner Synergio B.V. a.van.herk@synergio.nl 2011 Een brug naar onze presentatie Uniface is Compuware's

Nadere informatie

Wat drijft het werkveld?

Wat drijft het werkveld? Wat drijft het werkveld? Presentatie uitkomsten survey Jacob Brunekreef, Fontys ICT Jacob Brunekreef Meer dan 25 jaar werkzaam in de IT Nu: Projectleider EQuA project, Fontys ICT Adviseur / trainer bij

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

5 Programmastructuur

5 Programmastructuur 5 Programmastructuur Om het informatieplan en de daarin beschreven componenten is het aan te raden een programma- en projectenorganisatie in te richten. Volgend schema geeft de verschillende actoren en

Nadere informatie

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

To cloud or not to cloud Afgewogen keuzes maken met DYA Software

To cloud or not to cloud Afgewogen keuzes maken met DYA Software To cloud or not to cloud Afgewogen keuzes maken met DYA Software Robert Deckers Engineering World 2011 v1 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar

Nadere informatie

Architectuurredeneermodel Afgewogen keuzes maken

Architectuurredeneermodel Afgewogen keuzes maken Architectuurredeneermodel Afgewogen keuzes maken Robert Deckers SASG okt 2012 v3 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar ergens leiden Bewuste

Nadere informatie

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer Tmap Dag 2015 Ik test, jij test, wij testen Testen binnen een Wendbare Belastingdienst 29 september 2015 Laurens Kremer Introductie Naam: Laurens Kremer, SPC, CISA Rol: Agile coach Informatie Management

Nadere informatie

DEMCON Gestructureerde aanpak van mechatronische projecten

DEMCON Gestructureerde aanpak van mechatronische projecten DEMCON Gestructureerde aanpak van mechatronische projecten Ruud Jeurissen Ruud.Jeurissen@demcon.nl 22 september 2011 Inhoud Probleemstelling Oplossing Resultaten 2 Inhoud Uitdaging Aanpak Voorbeeld 3 Inhoud

Nadere informatie

13. De ideale product owner

13. De ideale product owner WHITEPAPER IN 5 MINUTEN D E C E M B E R 2 0 1 4 13. De ideale product owner In onze whitepaper over scrum (http://www.oberon.nl/whitepaper/11_scrum/) beschreven we kort de scrum methodiek zoals we die

Nadere informatie

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt

Nadere informatie

Overdracht van project naar beheer. Beheer is ook Agile!

Overdracht van project naar beheer. Beheer is ook Agile! Overdracht van project naar beheer. Beheer is ook Agile! Belangrijkste doelen Project: Binnen tijd en geld een nieuw of aangepast product of dienst aan de klant leveren. Beheer: Het garanderen van continuïteit

Nadere informatie

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Een introductie voor leden van de expertgroep Informatiemodellen Harmen Mantel, Ordina ICT Management & Consultancy, werkzaam voor KING DOELSTELLING PRESENTATIE GEMEENSCHAPPELIJKE

Nadere informatie

CMM 3: levert het wat op?

CMM 3: levert het wat op? CMM 3: levert het wat op? Philips Analytical De noodzaak en voordelen van Software Process Improvement Wie is Philips Analytical? Waarom is voor ons software proces verbetering zo essentieel? Hoe hebben

Nadere informatie

4 Enterprise-architectuur in de hoogste versnelling

4 Enterprise-architectuur in de hoogste versnelling 4 Enterprise-architectuur in de hoogste versnelling Danny Greefhorst Architectuur kan een bijdrage leveren bij het gericht veranderen van organisaties. In de praktijk sluit architectuur echter te vaak

Nadere informatie

WHITE PAPER. Agile/Scrum

WHITE PAPER. Agile/Scrum WHITE PAPER Agile/Scrum Belangrijkste kenmerk van Scrum is de ontwikkeling via een serie van korte - iteraties, in Scrum terminologie sprints genoemd. Introductie Heel in het kort gezegd is Scrum een Agile

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Testers helpen ontwikkelaars of andersom? TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Improve Quality Services B.V. 2 Agenda Hoe veilig is een muur? Past Scrum ook

Nadere informatie

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 Functional Model Driven Development MDA in de praktijk Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 FMDD agenda FMDD Waarom FMMD De praktijk Wat is FMDD Ervaringen en lessons learned Ervaringen

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

Key success actors. De rol van middenmanagement bij strategische veranderingen. Onderzoek door Turner en de Rotterdam School of Management

Key success actors. De rol van middenmanagement bij strategische veranderingen. Onderzoek door Turner en de Rotterdam School of Management Key success actors De rol van middenmanagement bij strategische veranderingen Onderzoek door Turner en de Rotterdam School of Management 1 Key success actors De rol van middenmanagement bij strategische

Nadere informatie

Functioneel meten en vakmanschap www.divosa.nl

Functioneel meten en vakmanschap www.divosa.nl De sociale dienst als lerende organisatie Functioneel meten en vakmanschap www.divosa.nl De sociale dienst als lerende organisatie Functioneel meten en vakmanschap Prof. dr. Roland Blonk, Chris Goosen

Nadere informatie

Agile Testen in de praktijk

Agile Testen in de praktijk 1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile

Nadere informatie

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.

Nadere informatie

INNOVATION BY MAKING LEARNING BY DOING

INNOVATION BY MAKING LEARNING BY DOING INNOVATION BY MAKING LEARNING BY DOING 1 INNOVATION BY MAKING, LEARNING BY DOING Bij alles wat we doen, hanteren we deze twee principes. Innovation happens by making. The only way to learn innovation is

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten Het W-model: de groei naar voren Jan Jaap Cannegieter Adjunct Directeur SYSQA B.V. Praktijk van ICT-projecten Req Ontwerp Realisatie Testen Testen Testen 44% van de projecten overschrijdt budget of tijd

Nadere informatie

Hoe ver moet je gaan?

Hoe ver moet je gaan? Hoe ver moet je gaan? Requirements verzamelen in agile John Copier; Marcel Steur 8 oktober 2015 Introductie Marcel + Qquest Informatica TU Delft Bedrijfskunde HSA + VU IT combineren met bedrijfskunde Qquest

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

ABN AMRO Verzekeringen Project: Documentbeheer Verzekeringen

ABN AMRO Verzekeringen Project: Documentbeheer Verzekeringen Opdrachtformulering Het in kaart brengen van de structuur achter verzekeringsdocumenten met het doel deze op een efficiënte manier productief te maken in een daarvoor te realiseren tool. De applicatie

Nadere informatie

TESTAUTOMATISERING IN EEN ETL-OMGEVING

TESTAUTOMATISERING IN EEN ETL-OMGEVING Pagina 21 TESTAUTOMATISERING IN EEN ETL-OMGEVING Door John Kronenberg John.Kronenberg@bartosz.nl @johnkronenberg Edward Crain Edward.crain@divetro.nl Welke groeifasen werden doorlopen in testautomatisering

Nadere informatie

EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation Voorbeeldexamen EXIN Agile Scrum Foundation Editie april 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007 Offshoring & Testing Verander een uitdaging in een kans Door Ernst Labruyère re Consultant ps_testware 20 september 2007 Ernst Labruyere- Offshoring en Testing: : Verander een uitdaging in een kans - 1

Nadere informatie

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

Nadere informatie

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient 9 Samenvatting Software heeft vooruitgang in veel vakgebieden mogelijk gemaakt en heeft een toenemend invloed op ons leven en de samenleving in zijn geheel. Software wordt gebruikt in computers, communicatienetwerken,

Nadere informatie

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014 Werkgroep ISO29119 TestNet thema-avond 9 oktober 2014 Is dit n gezonde maaltijd? Ja toch!! Om jezelf een oordeel te kunnen vormen heb je informatie nodig!! Vandaag brengen we kennis en informatie bij elkaar

Nadere informatie

Big Data en Testen samen in een veranderend speelveld. Testnet 10 april 2014 Paul Rakké

Big Data en Testen samen in een veranderend speelveld. Testnet 10 april 2014 Paul Rakké Big Data en Testen samen in een veranderend speelveld Testnet 10 april 2014 Paul Rakké Kernvraag Is het testen van Big Data omgevingen, applicaties en de data anders dan het testen van meer traditionele

Nadere informatie

BUSINESS INNOVATION. BE TOMORROW, CHALLENGE TODAY > Waarom innoveren? > Innovation drivers > Succes- en faalfactoren

BUSINESS INNOVATION. BE TOMORROW, CHALLENGE TODAY > Waarom innoveren? > Innovation drivers > Succes- en faalfactoren BUSINESS INNOVATION BE TOMORROW, CHALLENGE TODAY > Waarom innoveren? > Innovation drivers > Succes- en faalfactoren EEN MASTERCLASS VAN MASTERCLASS INSTITUTE IN SAMENWERKING MET: BUSINESS INNOVATION Be

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

Effectief testen in complexe omgeving 20-8-2012

Effectief testen in complexe omgeving 20-8-2012 Effectief testen in complexe omgeving 20-8-2012 How it came to be 20-8-2012 2 Indeling Wie ben ik? Wat doet TASS? Beschrijving ontwikkelgroepen Voor SCRUM Implementatie SCRUM Gerealiseerde verbeteringen

Nadere informatie

Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker

Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Wim Tindemans Manager Business Applications Business and Automation Solutions Egemin NV Agenda Probleemstelling Tegenstelling tussen

Nadere informatie

AgileBeheer. Optimale balans in continuïteit & verandering. @daveherpen

AgileBeheer. Optimale balans in continuïteit & verandering. @daveherpen AgileBeheer Optimale balans in continuïteit & verandering @daveherpen Agile 2 Agile: reality 3 Agile: goal 4 AgileBeheer: referentiekader Business TTM -- Qual Time To Market omlaag Quality lifecycle 6.

Nadere informatie

Zest Application Professionals Training &Workshops

Zest Application Professionals Training &Workshops De requirements trainingen van Zest Application Professionals geven u de handvatten die nodig zijn om uw requirementsproces te verbeteren. U doet hands-on ervaring op en leert omgaan met lastige praktijksituaties.

Nadere informatie

occurro Vertrouwt u uw gegevens? BI wordt volwassen Kasper de Graaf 31 maart 2009 De kracht van BI en Architectuur in de praktijk - Centraal Boekhuis

occurro Vertrouwt u uw gegevens? BI wordt volwassen Kasper de Graaf 31 maart 2009 De kracht van BI en Architectuur in de praktijk - Centraal Boekhuis Vertrouwt u uw gegevens? BI wordt volwassen Kasper de Graaf 31 maart 2009 De kracht van BI en Architectuur in de praktijk - Centraal Boekhuis BI & Data Warehousing Business Intelligence: Het proces dat

Nadere informatie

Procesgerichte IT BPM de link tussen bedrijf en IT

Procesgerichte IT BPM de link tussen bedrijf en IT 24 november 2010 Procesgerichte IT BPM de link tussen bedrijf en IT ir. Martin R. Meijer senior BPM/EAI consultant Agenda Business Process Management, een historisch overzicht BPM als bindmiddel geschikte

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Praktijkplein Titel: Toepassing: Koppeling met het Operational Excellence Framework: Implementatiemethodieken: ontwerpen en ontwikkelen.

Praktijkplein Titel: Toepassing: Koppeling met het Operational Excellence Framework: Implementatiemethodieken: ontwerpen en ontwikkelen. Praktijkplein Titel: Implementatiemethodieken: ontwerpen en ontwikkelen. Toepassing: Beknopte samenvatting van twee implementatiemethodieken en hun toepassing bij het implementeren van een operational

Nadere informatie

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. XP Extreme Programming Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING...3 2. EXTREME PROGRAMMING...4 3. FASERING...5

Nadere informatie

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie

Nadere informatie

Satisfy the real (and changing) customer expectation

Satisfy the real (and changing) customer expectation Han Duisterwinkel Test & Quality competence RUP competence LogicaCMG Nederland B.V. Eemsgolaan 1 P.O. Box 70237 9704 AE Groningen The Netherlands www.logicacmg.com @logicacmg.com

Nadere informatie

De Agile Analist. Henk Jan Huizer

De Agile Analist. Henk Jan Huizer De Agile Analist Henk Jan Huizer Software Ontwikkeling Dat is Software Ontwikkeling is Voor veel organisaties van steeds grote belang! Agile Software ontwikkeling Is een aanpak die past bij het type werk

Nadere informatie

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com Use-Case 2.0 Requirements Kenniscentrum 15 November 2012 Eric Lopes Cardozo elcardozo@ivarjacobson.com Agenda Use cases: Een korte geschiedenis Waarom nog steeds use cases gebruiken? Waarom Use-Case 2.0?

Nadere informatie

Agile werken: zó doen we dat

Agile werken: zó doen we dat Agile werken: zó doen we dat Bij Freshheads werken we graag volgens de Agile aanpak. De voordelen? Verhoogde efficiëntie en flexibiliteit, snellere resultaten en grotere betrokkenheid. Maar hoe gaat het

Nadere informatie

Typo3 Usergroep bijeenkomst Skillsontwikkeling in Typo3 community. - Luuk Roovers - www.vicus.nl info@vicus.nl

Typo3 Usergroep bijeenkomst Skillsontwikkeling in Typo3 community. - Luuk Roovers - www.vicus.nl info@vicus.nl Typo3 Usergroep bijeenkomst Skillsontwikkeling in Typo3 community - Luuk Roovers - www.vicus.nl info@vicus.nl Agenda Even voorstellen Vicus ebusiness Solutions Geluiden uit de markt Belangrijke verschillen

Nadere informatie

De overstap naar Agile De overstap naar Agile

De overstap naar Agile De overstap naar Agile De overstap naar Agile De overstap naar Agile Wat als niet alleen de requirements veranderen, maar alles verandert? Inleiding Start project met waterval aanpak Overstap naar agile Hoe hebben we het gedaan?

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

doel bereikt zelfsturing inrichten veiligheid fundament Behoeftepiramide van een "Social Business"

doel bereikt zelfsturing inrichten veiligheid fundament Behoeftepiramide van een Social Business Behoeftepiramide van een "" (Naar analogie piramide van Maslow) Maslow rangschikte de volgens hem universele behoeften van de mens in een hiërarchie. Volgens zijn theorie zou de mens pas streven naar bevrediging

Nadere informatie

Opleidingsaanbod: testopleidingen.com

Opleidingsaanbod: testopleidingen.com (Business, (IT) Projectmanagement, Quality Management, etc.) TMap NEXT Test Engineer(NL/ENG) Examentraining TMap NEXT Test Engineer E-learning TMap NEXT Test Engineer Certificering TMap NEXT Test Engineer

Nadere informatie

Het ontwikkelproces naar Inkjet Modules

Het ontwikkelproces naar Inkjet Modules Het ontwikkelproces naar Inkjet Modules ML13.027 2013-01-31 FHI Future Technology Today 2013 1 Waar staan wij voor? intelligente elektronica voor meet- en regeltechniek fysica in hard en software tot uiting

Nadere informatie

Business Process Management

Business Process Management Business Process Management Prof. dr. Manu De Backer Universiteit Antwerpen Katholieke Universiteit Leuven Hogeschool Gent Wat is een bedrijfsproces? Een verzameling van (logisch) gerelateerde taken die

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK VAN REQUIREMENTS HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...

Nadere informatie

Wim Ottenhoff, Jan Verbeek, 4 december 2012. PLM in de keten Overzicht en status project

Wim Ottenhoff, Jan Verbeek, 4 december 2012. PLM in de keten Overzicht en status project Wim Ottenhoff, Jan Verbeek, 4 december 2012 PLM in de keten Overzicht en status project Agenda 1. Achtergrond 2. Problematiek 3. Het project 4. Aanpak 5. De pilots 6. Conclusies 7. Actuele status 8. Vragen

Nadere informatie

KENSINGTON Business Intelligence

KENSINGTON Business Intelligence KENSINGTON Kensington levert geen toolkits, geen software voor analyse, rapportage, scorecards, K.P.I.'s of dashboards. Kensington levert u. De beste software ter wereld iets beters is er niet. Alle leveranciers

Nadere informatie

Product Quality Management, onze toekomst René Tuinhout

Product Quality Management, onze toekomst René Tuinhout Product Quality Management, onze toekomst René Tuinhout Agenda No. 2 1 Tijdsindeling Binnen TestNet is gesproken over Product Kwaliteit (in 2011 en tijdens de Summerschool 2012). Een TestNet-werkgroep

Nadere informatie

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4 V1.1 / 01 september 2015 MCTL v1.1 4. : taken, bevoegdheden en verantwoordelijkheden... 3 Rol Key-user...

Nadere informatie

SCRUM VERDUBBELAAR. dubbel zo goed door je persoonlijke backlog. Een leerprogramma dat zorgt voor verdieping. in de ontwikkeling van Scrumteams

SCRUM VERDUBBELAAR. dubbel zo goed door je persoonlijke backlog. Een leerprogramma dat zorgt voor verdieping. in de ontwikkeling van Scrumteams SCRUM VERDUBBELAAR dubbel zo goed door je persoonlijke backlog Een leerprogramma dat zorgt voor verdieping in de ontwikkeling van Scrumteams IK WIST DAT HET NIET GING LUKKEN (en hield het voor me) IK HEB

Nadere informatie

Business Sprint LOOT-scholen en Zo.Leer.Ik in kader van project Leerling 2020. Door Madelief Keyser en Michael van Wetering

Business Sprint LOOT-scholen en Zo.Leer.Ik in kader van project Leerling 2020. Door Madelief Keyser en Michael van Wetering Business Sprint LOOT-scholen en Zo.Leer.Ik in kader van project Leerling 2020 Door Madelief Keyser en Michael van Wetering Aanleiding Business Sprints Inzicht krijgen in behoeftes van nieuwe onderwijsconcepten

Nadere informatie

Visie & Strategie. Aad van Schetsen. Vice President & General Manager Uniface Delft, 18 November 2009

Visie & Strategie. Aad van Schetsen. Vice President & General Manager Uniface Delft, 18 November 2009 Visie & Strategie Aad van Schetsen Vice President & General Manager Uniface Delft, 18 November 2009 Agenda Visie Strategie Technologie Kennis Marketing Organisatie Uniface in de Crisis Investeringen worden

Nadere informatie

5 Opstellen businesscase

5 Opstellen businesscase 5 Opstellen In de voorgaande stappen is een duidelijk beeld verkregen van het beoogde project en de te realiseren baten. De batenboom geeft de beoogde baten in samenhang weer en laat in één oogopslag zien

Nadere informatie

Medical device software

Medical device software Medical device software Medical device software Software ontwikkeling voor de medische wereld Nspyre Herculesplein 24 3584 AA Utrecht T 088-827 50 00 F 088-827 50 99 www.nspyre.nl Medical devices zijn

Nadere informatie

Het verschíl maken vanuit Inzicht & Systemisch overzicht!

Het verschíl maken vanuit Inzicht & Systemisch overzicht! Thales HR-dag 24 september 2015 Het verschíl maken vanuit Inzicht & Systemisch overzicht! De oplossing vind je nooit op het niveau van het probleem zelf Waar of Niet Waar? De kracht van systemische (organisatie)

Nadere informatie

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test

Nadere informatie

PLANET AGILE 17E BPUG SEMINAR

PLANET AGILE 17E BPUG SEMINAR PLANET AGILE 17E BPUG SEMINAR. Uw sprekers: Bert Hedeman: managing director Hedeman Consulting Peter Coesmans: verandermanager/interim manager p2 Managers Ingeborg Bovee-Oudenhoven: senior nutritional

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

Sitecore Author Experience

Sitecore Author Experience Sitecore Author Experience In 3 stappen naar blijere CMS-gebruikers bij CZ Sitecore User Group Nederland, 8 december 2015 10-12-2015 Bas Evers (@everbass) Agenda Over (digitaal) CZ Contentstrategie bij

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V.

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V. Kwaliteitskosten onderzoek Aanpak Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 KWALITEITSKOSTEN...

Nadere informatie

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture Software architecture IM0203 TERUGKOPPELING PROEFTENTAMEN Vraag 1 Vraag 1a Veel van de in het werkboek besproken patterns kunnen ingezet worden voor het referentiesysteem. We lopen de patterns hier stuk

Nadere informatie

End-to-End testen: de laatste horde

End-to-End testen: de laatste horde End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010

Nadere informatie

TFS als perfecte tool voor Scrum

TFS als perfecte tool voor Scrum TFS als perfecte tool voor Scrum René van Osnabrugge renevo@delta-n.nl About me René van Osnabrugge Communicate @renevo renevo@delta-n.nl http://osnabrugge.wordpress.com Agenda Wat is Scrum? Wat is ALM

Nadere informatie

Service Design: een inleiding

Service Design: een inleiding Service Design: een inleiding IFMA, 10 december 2013 Joannes Vandermeulen @joannes #namahn design that works for people 1 Het bestaande verbeteren design that works for people 2 maar toch besparen? design

Nadere informatie

8 Politieke processen: omgaan met macht

8 Politieke processen: omgaan met macht 8 Politieke processen: omgaan met macht Politieke processen: omgaan met macht 3 Inleiding 3 De organisatie: formeel en feitelijk 3 De academische organisatie 5 Tactische hulpmiddelen 5 Voorbereiding 6

Nadere informatie

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

BESLUITVORMING; HET SPEL OF DE REGELS

BESLUITVORMING; HET SPEL OF DE REGELS BESLUITVORMING; HET SPEL OF DE REGELS T. S. Eliot (1888-1965) Prufrock and Other Observations (1917) Next: Steeds sneller besluiten 2 Steeds sneller besluiten Mobiel Bankieren steeds populairder Mobiel

Nadere informatie

Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis'

Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis' Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis' versie 30 augustus 2013 De beschikbaarheid van betrouwbare digitale overheidsinformatie is de basis voor het goed kunnen

Nadere informatie

BiZZdesign. Bouwen van sterke en wendbare organisaties met behulp van standaarden, methode, technieken en tools. Research & Development

BiZZdesign. Bouwen van sterke en wendbare organisaties met behulp van standaarden, methode, technieken en tools. Research & Development BiZZdesign Bouwen van sterke en wendbare organisaties met behulp van standaarden, methode, technieken en tools Research & Development 1 Profile CV Joost Niehof Name Grade Nationality Residence Role Joost

Nadere informatie

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

Projectplan MKB Roadmaps 2.0

Projectplan MKB Roadmaps 2.0 Projectplan MKB Roadmaps 2.0 In 2013 is MKB Roadmaps voor het eerst opgestart, met als doelstelling om (aspirant) ondernemers te helpen om de zakelijke kant van hun innovatie te ontwikkelen. De eerste

Nadere informatie

ITIL komt van Mars, Agile van Venus

ITIL komt van Mars, Agile van Venus ITIL komt van Mars, Agile van Venus Frederick Winslow Taylor 2 Scientific Management 3 Werknemers zijn... 4 Denkwerk overlaten aan... 5 Dus Tayloriaans = Standaardisatie van zoveel mogelijk activiteiten

Nadere informatie