OOAA. Object Oriented Analysis Advanced. Arie Bubberman 12/10/2009

Maat: px
Weergave met pagina beginnen:

Download "OOAA. Object Oriented Analysis Advanced. Arie Bubberman 12/10/2009"

Transcriptie

1 OOAA Object Oriented Analysis Advanced Arie Bubberman 12/10/2009

2 Contents 1 Analyse...3 Kiezen van een ontwikkelproces...3 Agile Methoden...3 Deelprocessen in het OO-ontwikkelproces...Fout! Bladwijzer niet gedefinieerd. De plaats van analyse in het ontwikkelproces...5 Agile methods Statisch modelleren...8 Bepalen van Analysis Classes...8 Opstellen van een initieel Domeinmodel...9 Uml diagrammen Statisch Modelleren Detailleringen Associaties en Attributes Toepassen van Inheritance Uitbreiding Use Case Notatie Dynamisch modelleren Objecten en Klassen Interactie tussen domeinobjecten Interactiediagrammen Toestanden en gedrag van objecten Modelmanagement Analysis Packages Case Tools Quality Assurance

3 1 Analyse Kiezen van een ontwikkelproces Voor het ontwikkelen van software is een standaard aanpak noodzakelijk. Een software - ontwikkelingsmethode biedt 2 vormen van ondersteuning: 1) Een proces(stappenplan) dat men kan volgen, gebaseerd op het maken van modellen 2) Een aantal gestandaardiseerde notaties om de modellen in neer te schrijven. Watervalmethode/traditioneel ontwikkelen In deze aanpak vinden alle stappen sequentieel plaats. Voordat er aan een volgende fase begonnen kan worden, moet de vorige fase dus volledig voltooid zijn. Het waterval proces wordt ook wel cascade genoemd. Erg geliefde methode bij projectleiders, door duidelijk afgelijnde milestones. Requirements Analysis Design Program Testing Nadelen van de watervalmethode: 1) Het systeem houdt geen rekening met de evolutie van vereisten(requirements) 2) Testen kan pas helemaal aan het einde van het volledige proces 3) Er zijn hoge kosten voor aanpassingen op het moment dat het systeem niet voldoet aan de wensen van de klant Agile Methoden Om aan de tekortkomingen van het waterval proces te beantwoorden is er een werkwijze ontwikkeld die een incrementele en iteratieve aanpak vooropstelt 1) Incrementeel: functionaliteiten deelsgewijs ontwikkeld en toegevoegd aan een continu groeiende applicatie. 2) De verschillende fases van het ontwikkelingsproces worden meerdere keren herhaald. Agile manifesto Dit is de definitie van een doeltreffende en moderne software- ontwikkelmethodologie. Het bestaat uit 4 punten: 1) Medewerkers en onderlinge interactie primeren over processen en tools 2) Werkende software is belangrijker dan uitgebreide documentatie 3) Goede samenwerking met de klant primeert over contractonderhandeling 4) Proactief inspelen op veranderingen is belangrijker dan het volgen van een planning. Iteratieve ontwikkeling Agile staat veelal bekent door de iteratieve aanpak. Enkele voordelen hiervan zijn: 1) Het gebruik van korte iteraties werkt motiverend voor medewerkers 2) Als er ergens iets fout gaat binnen een iteratie, en de klant is niet tevreden met het resultaat, dan verliest men maximaal 2 tot 6 weken in plaats van maanden of zelfs een jaar. 3) Deze aanpak houdt rekening met de werkelijkheid. In het begin van het project is het namelijk onmogelijk om de vereisten van de klant nauwkeurig te beschrijven. In de iteraties worden de eisen en wensen verder verfijnt. Relatie met OO Doordat er kleine componenten (stukken functionaliteit) worden opgeleverd, worden hier wel zwaardere en specifieke eisen aan gesteld. E moeten gemakkelijk aanpasbaar en onderhoudbaar zijn. Daarnaast moeten componenten duidelijk beschreven interfaces hebben zodat ze onderling kunnen samen werken. Hiervoor is een objectgeoriënteerde taal eigenlijk onontbeerlijk. Unified Process Unified Proces, ofwel UP is een volledig ingevulde methode en bied werkwijzen, technieken, richtlijnen, standaarden en afbeeldingwijzen. Het is ontstaan uit de behoefte naar een goed 3

4 gedocumenteerd en beschreven software- ontwikkelingstechniek. Vaak wordt er verwezen naar RUP, waarbij de R staat voor Rational. Het is samengesteld uit verschillende werkwijzen. 1) Het is een verzameling van best practices in een modern softwareproces 2) Het is een aanpasbaar kader waarin aangewezen processen voor je organisatie/probleem aangemaakt kunnen worden. UP heeft een processtructuur waarbij er twee dimensies zijn te onderkennen: De core flows. De core flows lopen over de gehele project, door de verschillende fasen van het project heen 1) Requirements: Dit is het verzamelen van de vereisten en het formuleren van de vereisten die door zowel door de teamleden als de klant kunnen worden begrepen. De vereisten worden verwerkt in use case diagrammen. Deze beelden de relatie tussen de gebruiker en de functionaliteiten uit. Een hulpmiddel om te controleren of aan alle vereisten zijn voldaan is: FURPS (Functionality, Usability, Relability, Performance en Supportability) 2) Analyse: Specificeren wat ontwikkeld moet worden. Het omvat het analyseren van het probleemdomein en het maken van een domeinmodel. Het systeem wordt van buiten af beschreven. 3) Design: Deze fase omvat het ontwerp van de architectuur van het systeem. Nadruk ligt op de interne werking van het systeem, en de uitwerking van de functionaliteit in termen van hardware en implementatiespecifieke technologie. Ook worden er beslissingen over strategieën genomen (database schema s etc.) 4) Implementatie: In deze fase wordt het systeem gebouwd. Ontwerpmodellen worden vertaald naar code. Klassendiagrammen kunnen hier het beste voor gebruikt worden 5) Test: In deze fase wordt het systeem getest. Er wordt gekeken of het systeem voldoet aan de verwachtingen, maar ook om defecten uit de software te halen De fasen. UP bestaat uit 4 fasen: 1) Inception: Dit wordt ook wel de initieele fase genoemd. Deze fase bestaat uit 1 enkele iteratie. Er wordt geen software gebouwd in deze fase. De volgende dingen worden gedaan: a. De scope van het project opstellen b. Een uitgbreide risicoanalyse uitvoeren c. Een proof of concept bouwen d. Een visie(vision) document opstellen. Aan de hand van dit document wordt bepaald of het project al dan niet doorgaat 2) Elaboration: De gewenste functionaliteit wordt verder uitgediept. De volgende dingen worden gedaan: a. Mogelijke kritieke punten in de architectuur en het ontwikkelpad worden onderzocht. b. Componenten worden gedefinieerd. Deze zijn van hoge kwaliteit en maken deel uit van de uiteindelijke applicatie. Vereisten en analyse activiteiten zijn erg belangrijk, design en implementatie worden belangrijker, vooral aan het einde van de fase. c. Het skelet van de applicatie, ook wel kernarchitectuur genoemd, maken. 3) Construction: Design en implementatie worden hier belangrijker, vereisten en analyse komt meer op de achtergrond te staan. In deze fase wordt het volgende gedaan: a. Het skelet van de applicatie uitbreiden tot een volledig systeem b. Aan het einde van elke iteratie worden de afzonderlijke componenten uitvoerig getest en gelinkt. Deze releases kunnen in een testomgeving geplaatst worden. 4) Transition: In deze fase wordt er langzaam overgegaan naar de nieuwe situatie. De volgende dingen worden gedaan: 4

5 a. Opstarten piloot project waarbij de bètasoftware op een aantal pc s geïnstalleerd wordt. b. Na feedback kleine aanpassingen in de code aanbrengen c. Productdocumentatie maken d. Eindgebruikers trainen e. Uitrollen van de final release DSDM DSDM staat voor Dynamic Systems Development Method. Het is een Rapid Application Development methode (RAD). Wordt voornamelijk gebruikt bij ontwikkeling van gecomputeriseerde informatiesystemen. Tijdens de ontwikkeling met DSDM komen steeds meer gedetailleerde specificaties boven water. Deze worden vervolgens op basis van prioriteiten ingedeeld. Timeboxes: Dit is een specifieke, afgebakende tijdsplanning. Hierin worden eerst de zaken opgeleverd die het belangrijkste zijn voor de bedrijfsbehoeften. Op deze manier kan snel resultaat behaald worden. XP XP staat voor Extreme Programming. Ook deze methode heeft een iteratieve werkwijze. Het is een erg pragmatische aanpak. De klant moet bij deze methode deel uitmaken en beschikbaar zijn voor het ontwikkelteam. Geschikt voor kleine projecten. XP promoot het gebruik van pair programming. Een medewerker richt zich volledig op de code, terwijl de andere fouten in de code of aanpak probeert te vinden. Na een tijd wisselen de medewerkers van rol FDD FFD staat voor Feature Driven Development. Dit is een aanpak waarbij het proces gedreven wordt door de features van het systeem.de onderscheidende processen binnen FFD zijn: 1) Bouwen featurelist 2) Opstellen planning per feature 3) Maken van design per feature 4) Bouwen van applicatie per feature De plaats van analyse in het ontwikkelproces Analysis- model Het doel van het analysis- model is het verfijnen en structureren van de verzamelde vereisten. Dit model is een verzameling van diagramme, waarmee de vereisten van het systeem in beeld gebracht kunnen worden. Het zorgt er voor dat het systeem makkelijker begrepen kan worden. Materiële en technische aspecten komen niet ter sprake. Use case diagrammen en het domeinmodel zijn erg belangrijk. Use case model: Een use case bepaalt een reeks interacties tussen de externe actoren en het systeem dat we willen bouwen. Actoren zijn partijen die interactie aangaan met het systeem. Dit kunnen gebruikers zijn, maar ook een ander systeem Concept: Een concept is een voorstelling van iets dat echt bestaat in het kader van het project dat men wil uitvoeren. Een concept hoeft niet per se tastbaar te zijn, tijd kan bijvoorbeeld ook een concept zijn. Een concept wordt ook wel een conceptuele klasse genoemd. 5

6 Domeinmodel: Dit is een verzameling van concepten, samen met de associaties die bestaan tussen de concepten onderling. Representational gap: Deze term slaat op het verschil ( gap ) dat bestaat tussen de concepten die verzameld worden in een domeinmodel (op basis van vereisten), en de klassendiagrammen die na grondige analyse en design worden aangemaakt. Artifacts van OO- Analyse Use case Model: Een use case bepaalt een reeks interacties tussen de externe actoren en het systeem dat we willen bouwen. Actoren zijn partijen die interactie aangaan met het systeem. Dit kunnen gebruikers zijn, maar ook een ander systeem. Er wordt onderscheid gemaakt tussen primaire en secundaire actoren: 1) Primaire actor: deze heeft bepaalde doelstellingen, en de actor gebruikt het systeem direct om deze te bereiken 2) Secundaire actor: deze heeft indirect baat bij het systeem. Het beschrijft een opeenvolging van succes en optionele faal interacties tussen actoren en het systeem, die noodzakelijk zijn om de dienst te leveren die het doel tevreden stelt. Een use case maakt gebruik van een black box aanpak. Het beschrijft dus alleen wat de functionaliteit is van het systeem, niet hoe dit technisch gerealiseerd wordt. De beschrijvingen worden geschreven in de taal van de klant. Use Case realization: Dit beschrijft de interne werking van de Use case. Voor elke Use case wordt de interne communicatie getoond door gebruik van een of meerdere diagrammen. Het toont de functionaliteit op systeemniveau. Dit is in de taal van de ontwikkelaar. Er worden twee stromingen onderscheiden tijdens de analyse: 1) Use case driven Development: Use Cases staan centraal in de UP methodologie. Alle UMLartefacten (afbeeldingen en diagrammen) worden hieruit afgeleid. 2) Responsibility driven development: Dit is het ombuigen van de gebruikelijke analyseaanpak naar een werkwijze waarbij objecten centraal staan. Een object is een voorstelling van een fysisch of logisch concept dat is afgeleid uit de vereisten van het project. Patterns: Hierin is vastgelegd welk werk een object krijgt toebedeeld. Objecten werken op een bepaalde manier samen. a. Controleur: 1 van de objecten speelt de baas b. Expert: welk object weet het antwoord op een bepaalde vraag c. Creator: wie is verantwoordelijk voor het aanmaken van nieuwe objecten d. Low Coupling: objecten moeten met een minimaal aantal andere objecten kunne praten e. High Cohesion: objecten hebben graag gerelateerde verantwoordelijken. Er zijn een aantal regels die belangrijk zijn: 1) Iedere Use case(weergeven als ellips) is gerelateerd aan minstens 1 actor, of een andere Use case 2) Iedere Use case stelt een bedrijfsproces voor, dat bestaat uit verschillende stappen 3) Iedere Use case moet een toegevoegde waarde hebben voor de organisatie. 6

7 Use case scenario: Dit is een specifiek geval van een use case, het vertegenwoordigd 1 enkele weg door de use case. Het beschrijft de opeenvolging van stappen die worden gevolgd, vanaf de start tot een van de uitkomsten. Meestal werkt met met een basisscenario, ook wel Happy path genoemd, waarna de verschillende uitzonderingen of alternatieven onder het basisscenario worden vermeld. Happy Path: Deze aanpak betekent dat de use case zonder problemen, en dus zoals verwacht wordt doorlopen. Sequence diagram: Dit diagram wordt gebruikt om de interacties te tonen tussen de actoren en het systeem. Ze worden ook wel System Sequence Diagrams genoemd (SSD). Het legt de speciale nadruk op de volgorde waarmee de interacties tussen de actors en het systeem plaatsvinden. In dit diagram worden de actoren en het systeem als objecten voorgesteld boven aan het diagram, en elk object heeft zijn eigen lifeline (levenslijn). Deze lifeline wordt voorgesteld als een verticale onderbroken lijn, en de tijd verloopt van boven naar beneden. De interacties tussen de objecten worden weergeven in de vorm van pijlen met de naam van de interactie en eventuele parameters. Dit diagram is de eerste opstap naar het realiseren van een Use case, en wordt in een taal geschreven die meer aanleunt bij de ontwikkelaar. Elke ellips uit het Use Case diagram zal leiden tot 1 Sequence diagram. Soms wordt een event meerdere malen verstuurd, en is er sprake van herhaling. In het diagram wordt dit weergeven als een grote nota, met daarin een lus(loop) conditie. Deze bepaalt hoe vaak de lus wordt uitgevoerd. Message to self : Dit is de term die gebruikt wordt als een systeem interne dingen moet doen. Dit wordt weergeven als een pijl vanaf het systeem naar zichzelf. Een bericht naar het systeem toe kan parameters bevatten, een bericht vanaf het systeem naar de gebruiker kan nooit parameters bevatten! Domain model Een domeinmodel (domain model) bevat concepten die verzameld worden op basis van een analyse van de requirements. Naast de concepten zijn er ook associaties tussen de concepten, multipliciteit en attributen. De notatie van een domeinmodel is identiek aan een klassediagram, met uitzondering van enkele punten: Methodes en pijlpunten ontbreken. Alle associaties in een domeinmodel zijn bidirectioneel. De concepten in het domeinmodel worden getekend als rechthoeken met 2 vakken. In het eerste vak staat de naam, in de 2 e staan de belangrijkste attributen. Class diagram Een klassendiagram (class diagram) is het uiteindelijke doel van de ontwikkelcyclus binnen 1 iteratie. Dit model kan worden omgebouwd naar code in een willekeurige object georiënteerde taal. Een klassendiagram is afgeleid uit een domeinmodel. De klassen in het model worden getekend als rechthoeken met 3 vakken. In het eerste vak komt de naam, in het 2 e vak komen de attributen en in het 3 e vak komen de methodes. Meestal wordt er een kopie gemaakt van het domeinmodel, waar vervolgens de methodes aan toegevoegd worden. Activity Diagram Een activity diagram speelt een interessante rol tijdens de analyse. Het diagram is geschikt om een if-then-else beslissing of workflow in te weergeven. Dit diagram wordt gebruikt om de 7

8 gedetailleerde Use case tekst aanschouwelijk te maken. Dit diagram bestaat uit een aantal Swim lanes. Deze lanes staan voor de verschillende actors. Dit zijn zowel personen als het systeem zelf. Het diagram start altijd met een zwart bolletje. Vanuit daar wordt de eerste activiteit gestart. Activiteiten worden weergeven als rechthoeken met afgeronde hoeken. Tussen de activiteiten staan pijlen waarmee de richting van het bericht wordt aangegeven. Voor plekken waar een beslissing (ja/nee) gemaakt wordt, wordt een ruit gebruikt. Test-first approach: met het diagram kan de applicatie getest worden voordat er een regel code geschreven is. State diagram Dit is een optioneel diagram en wordt ook wel State Machine genoemd. Dit diagram geeft de status van elk aspect binnen de ontwikkelcyclus weer, zoals de status van een bepaalde Use case. Meestal worden in dit diagram objecten gebruikt, omdat deze dynamisch zijn, en kunnen op basis van hun status bepaald gedrag vertonen. Een State diagram is alleen nuttig als er meerdere statussen zijn. Agile methods Analysis Patterns Een pattern is een combinatie van een veel voorkomend probleem met een bijbehorende standaardoplossing. Patterns worden niet gemaakt, eerder ontdekt. Het voordeel van een geformaliseerd pattern is het vergemakkelijken van de communicatie tussen de leden van het project team. GRASP: General Responsibility Assignment Software Patterns. Deze patterns zijn geschikt om vragen met betrekking tot de responsibility van de objecten te beantwoorden. Hieronder staan een aantal best practices: 1) Low Coupling: hier wordt getracht het aantal associaties tussen de concepten/klassen te beperken 2) High Cohesion: Hier dienen de verantwoordelijkheden binnen een klasse gerelateerd te zijn. 3) Expert: Hier wordt gekeken naar welk concept/klasse de informatie bezit om een taak uit te voeren 4) Creator: Hier wordt gekeken wie er verantwoordelijk is voor het aanmaken van een object. 5) Controller: Hier wordt gekeken naar welk concept/klasse de interface van het systeem voortsteld 6) Don t talk to Strangers: Hier mogen de objecten alleen met de directe omgeving praten 7) My creator is my savior: Hier is de object creator geschikt om het nieuwe object weg te schrijven. GOF patterns: Gang of Four. Deze patterns zijn technischer dan GRASP patterns. Deze worden later in de designfase ingezet door de designers, die het klassendiagram op stellen. GOF kent 23 patterns. 2 Statisch modelleren Statische modellen zijn erg geschikt voor het weergeven van de structuur van een systeem. Bepalen van Analysis Classes 8

9 Use Case View en Analysis View Elk teamlid heeft een ander zicht (view) op een systeem. Binnen Unified Process zijn er 6 views gedefinieerd. De dikgedrukte views zijn het belangrijkste binnen deze studie. 1) Use case view 2) Analysis view 3) Design view 4) Implementation view 5) Deployment view 6) Test view Deze views komen niet exact overeen met de views die men in een case tool zal terugvinden. Case tools zijn namelijk niet gebonden aan een enkele methodologie. Domain Modeling Noun Phrase Identification Common Concept Category List Domain Model Bouwen van een Domain Model Opstellen van een initieel Domeinmodel Glossary Analysis (conceptual) classes Bepalen van Responsibilities Operation Contract Uml diagrammen Uml class diagram Operations 9

10 Associations Attributes UML object diagram 10

11 3 Statisch Modelleren Detailleringen Associaties en Attributes Derived Attributes Multipliciteit Role Compositie Aggregatie Association Class Qualified Association Operations Toepassen van Inheritance Polymorphisme Multiple Inheritance Inheritance andanalysis Patterns Uitbreiding Use Case Notatie Include Extend Inheritance 4 Dynamisch modelleren Objecten en Klassen Interactie tussen domeinobjecten Objecten en methodes Use Case Realization Interactiediagrammen UML Interactiediagram UML Sequence Diagram UML Communicatiediagram 11

12 CRC Card UML Interaction Overview Diagram Toestanden en gedrag van objecten UML State Machine Diagram UML Timing Diagram Constraints Object Constraint Language 5 Modelmanagement Analysis Packages Architectuur UML Package diagram Opdelingscriteria Case Tools Waarom Case Tools? Code generation Reverse Engineering Round- trip Engineering Teamwork Quality Assurance Model review & peer review Model walkthrough Usage scenario testing Prototype walkthrough 12

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

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie?

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? 1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? -Use case-diagram -Use case-beschrijving -Activity diagram -Sequentie diagram 2. Welke diagrammen beschrijven de structuur van de

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

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Ontwikkelmethoden en technieken Kenmerken van ontwikkelmethoden POMT HC2 2 Vorige week 3 Rollenspel Klant is koning Communicatie en afspraken Documentatie

Nadere informatie

Object Oriëntatie Foundation (OOF.NL)

Object Oriëntatie Foundation (OOF.NL) Object Oriëntatie Foundation (OOF.NL) EXIN Hét exameninstituut voor ICT ers Janssoenborch - Hoog Catharijne Godebaldkwartier 365 3511 DT Utrecht Postbus 19147 3501 DC Utrecht Nederland T +31 30 234 48

Nadere informatie

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium Zelftest OOAD/UML Document: N0767Test.fm 30/08/2010 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is gebaseerd op de inhoud van onze cursus OO

Nadere informatie

UML is een visuele taal om processen, software en systemen te kunnen modeleren.

UML is een visuele taal om processen, software en systemen te kunnen modeleren. Vragen inleinding UML 1. Wat is UML? UML is een visuele taal om processen, software en systemen te kunnen modeleren. 2. Waar bestaat UML uit? Notaties(zijn symbolen, commentaar en waarden etc.) en diagrammen(grafische

Nadere informatie

Les F-02 UML. 2013, David Lans

Les F-02 UML. 2013, David Lans Les F-02 UML In deze lesbrief wordt globaal beschreven wat Unified Modeling Language (UML) inhoudt. UML is een modelleertaal. Dat wil zeggen dat je daarmee de objecten binnen een (informatie)systeem modelmatig

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering Deel II: Modelleren en software ontwikkeling Hoofdstuk 7 Software ontwikkeling - Overzicht 2005 Prof Dr. O. De Troyer, pag. 1 Naïeve benadering De vereisten voor het systeem worden geformuleerd en op basis

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Kenmerken van DLArchitect

Kenmerken van DLArchitect Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en

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

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

beschrijvingstechnieken bij systeemontwikkeling

beschrijvingstechnieken bij systeemontwikkeling 1 Bijlage 8 Alternatieve (UML) beschrijvingstechnieken bij systeemontwikkeling De in hoofdstuk 3 weergegeven beschrijvingstechnieken voor de beschrijving van de informatietechnologie is summier. Er wordt

Nadere informatie

Domeinmodellen en klassendiagrammen

Domeinmodellen en klassendiagrammen Overview Architectuur Deployment-diagram Software-architectuur 1 Architectuur Deployment-diagram Software-architectuur 2 3 Architectuur Architectuur Deployment-diagram Software-architectuur Webapplicatie

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie \ Peter Wanders De Black Box Dialog methode Voorjaarsevent Testnet: 22 juni 2009 Samenvatting Nog nooit heb ik heb een klant horen zeggen: Enorm vervelend dat het IT project

Nadere informatie

Inhoud. Introductie tot de cursus

Inhoud. Introductie tot de cursus Inhoud Introductie tot de cursus 1 Plaats en functie van de cursus 7 2 Inhoud van de cursus 8 2.1 Voorkennis 8 2.2 Leerdoelen 8 2.3 Opbouw van de cursus 8 2.4 Leermiddelen 9 3 Aanwijzingen voor het bestuderen

Nadere informatie

Inleiding ontwikkelmethoden

Inleiding ontwikkelmethoden Inleiding ontwikkelmethoden 1 Ontwikkelmethoden en Technieken POMT HC1 2 Ronald de Waal Opleiding TU Delft: industrieel ontwerpen Diverse softwarebedrijven, internet ontwerp vanaf 1994 Docent systeemontwikkeling

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Inhoud Deel een Het ontwikkeltraject 1 2 3

Inhoud Deel een Het ontwikkeltraject 1 2 3 5 Inhoud Inleiding 11 Deel een Het ontwikkeltraject 13 1 Werken binnen organisaties 15 1.1 Non-profit-organisatie 15 1.2 Profit-organisatie 16 1.3 Doelen 16 1.4 Rechtsvormen 16 Rechtspersoon 17 Persoonlijke

Nadere informatie

case: toestandsdiagrammen

case: toestandsdiagrammen Hoofdstuk 13 case: toestandsdiagrammen In dit hoofdstuk wordt het maken van de eerste versie van de toestandsdiagrammen voor het boodschappensysteem van Hans en Jacqueline uitgewerkt. 13.1 Vind klassen

Nadere informatie

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005 voorbeeldexamen Information Systems Design and Development Foundation I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005 inhoud 3 inleiding 4 voorbeeldexamen

Nadere informatie

Eigenschappen van moderne ontwikkelmodellen

Eigenschappen van moderne ontwikkelmodellen overdruk informatie september 00 Eigenschappen van moderne ontwikkelmodellen Vier modellen vergeleken Auteurs: Danny Greefhorst en Mark van Elswijk informatie overdruk1 1 Eigenschappen van moderne ontwikkelmodellen

Nadere informatie

Introductie. Hoofdstuk 1. 1.1 Over softwareontwikkeling

Introductie. Hoofdstuk 1. 1.1 Over softwareontwikkeling Hoofdstuk 1 Introductie 1.1 Over softwareontwikkeling In de meeste gevallen zijn er veel mensen betrokken bij de ontwikkeling van software: niet alleen de klant die de opdrachtgever is en de programmeurs

Nadere informatie

Inhoudstafel. UML (Unified Modeling Language)

Inhoudstafel. UML (Unified Modeling Language) UML (Unified Modeling Language) Inhoudstafel Inleiding...2 Waarvoor dient UML...2 Wat is UML... 2 Use-cases... 2 Inleiding...2 Voorbeeld...3 Eigenschappen van een goede use-case...3 Wat is een actor...4

Nadere informatie

Modeleren. Modelleren. Together UML. Waarvan maken we een model? overzicht les 14 t/m 18. ControlCenter 6.2

Modeleren. Modelleren. Together UML. Waarvan maken we een model? overzicht les 14 t/m 18. ControlCenter 6.2 Modelleren Werkelijkheid Modelleren Modeleren Waarvan maken we een model?!analyse " Maak een model van de te automatiseren werkelijkheid of van het op te lossen probleem! Domeinkennis = structuur! Functionele

Nadere informatie

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk. Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:

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

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

Capita Selecta Design Patterns voor administratieve applicaties

Capita Selecta Design Patterns voor administratieve applicaties Capita Selecta voor administratieve applicaties Bij afstudeerproject: Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder 26 augustus 2006 Inhoud 26

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

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

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

1. De watervalmethode... 2. 2. Agile softwareontwikkeling... 2. 3. Iteratief werken... 3. 4. Agile technieken voor teams... 3

1. De watervalmethode... 2. 2. Agile softwareontwikkeling... 2. 3. Iteratief werken... 3. 4. Agile technieken voor teams... 3 Naar Voren: Tijdschrift voor webwerkers» Artikel #155 Agile (web)ontwikkeling Omarm de verandering Als ICT-professional heb je het liefst dat de klant exact weet wat hij wil, dat jij exact weet hoe je

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software

Oplossingen voor het testen van objectgeoriënteerde software Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

Ontwikkelmethoden en technieken DSDM POMT HC3

Ontwikkelmethoden en technieken DSDM POMT HC3 DSDM Ontwikkelmethoden en technieken DSDM POMT HC3 HC WG rollenspel praktijktoets 1 praktijktoets 2 praktijktoets 3 Mei week 1 week 2 week 3 Week 4 vakantie Inleiding Ontwikkel methodiek DSDM Technieken

Nadere informatie

Eindtoets. Opgaven. 1 Gegeven is het domeinmodel van figuur 1. Domeinmodel voor betalingen. Eindtoets I N T R O D U C T I E.

Eindtoets. Opgaven. 1 Gegeven is het domeinmodel van figuur 1. Domeinmodel voor betalingen. Eindtoets I N T R O D U C T I E. Eindtoets I N T R O D U C T I E Deze eindtoets is bedoeld als voorbereiding op het tentamen. Het is belangrijk dat u de eindtoets pas probeert te maken op het moment dat u denkt klaar te zijn met de tentamenvoorbereiding.

Nadere informatie

Modulebeschrijving voor MOD1

Modulebeschrijving voor MOD1 Modulebeschrijving voor MOD1 Fontys Venlo Afd. informatica 12 april 2013 Samenvatting 1 Identificatie Module Modeling 1 ProgressCode MOD1 Docenten Ferd van Odenhoven Afdeling Fontys Hogeschool Techniek

Nadere informatie

Toegepaste notatiewijzen DLA software

Toegepaste notatiewijzen DLA software Toegepaste notatiewijzen DLA software Bert Dingemans info@dla-architect.nl Inleiding In de DLA Software wordt gebruik gemaakt van een aantal notatiewijzen voor het opstellen van een object- en procesmodel.

Nadere informatie

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

RUP Rational Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RUP Rational Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 14 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

HOGESCHOOL ROTTERDAM

HOGESCHOOL ROTTERDAM HOGESCHOOL ROTTERDAM IAN02 - Informatie-analyse (objectgeoriënteerde analyse) M O D U L E W I J Z E R I A N 0 2 1 V A N 1 5 Modulecode: IAN02 Modulenaam: Informatieanalyse 2 Belasting (aantal cp): 2 Bestemd

Nadere informatie

Systeem modellen. Topics covered

Systeem modellen. Topics covered Systeem modellen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1 Topics covered Context models Behavioural models Data models Object models CASE workbenches Ian Sommerville 2004

Nadere informatie

3.1 Opsomming data type

3.1 Opsomming data type Deel I Hoofdstuk 3: Klasse Model - gevorderd 2005 Prof Dr. O. De Troyer Klasse Model - gevorderd pag. 1 3.1 Opsomming data type Opsomming (enumeration) data type Data type waarvan de verzameling waarden

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

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

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

Agile ervaring Ir.ing. Erik van Daalen

Agile ervaring Ir.ing. Erik van Daalen Agile ervaring Ir.ing. Erik van Daalen Eneco Rotterdam 3 december 2013 03-12-2013 Agile Erik van Daalen 1 Hoofdsponsor Sponsors IPMA-N Jaarsponsors 03-12-2013 Agile Erik van Daalen 2 Korte introductie

Nadere informatie

Ontwikkeling informatiesysteem

Ontwikkeling informatiesysteem Ontwikkeling informatiesysteem Voorletters en naam: xxx Studentnummer: xxx Datum: 23 december 2013 Onderwijsinstelling: NCOI Opleidingsgroep Naam opleiding: Bachelor Bedrijfskundige Informatica Naam module:

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

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

Rapportage Lineage. Introductie. Methode. J. Stuiver

Rapportage Lineage. Introductie. Methode. J. Stuiver Rapportage Lineage Rapportage Lineage J. Stuiver Introductie In elk project is het essentieel om informatie over het project en haar activiteiten voor alle partijen beschikbaar te stellen. Deze informatie

Nadere informatie

Cyberpesten: social media platform mining tools

Cyberpesten: social media platform mining tools Cyberpesten: social media platform mining tools ABI team 27: Pascal Pieters, Stephaan Declerck Begeleider: dr. Rik Bos Opdrachtgever: prof. dr. ir. Remko Helms Inhoud Achtergrond Opdracht Projectaanpak

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het

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

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

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

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

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

Application interface. service. Application function / interaction

Application interface. service. Application function / interaction Les 5 Het belangrijkste structurele concept in de applicatielaag is de applicatiecomponent. Dit concept wordt gebruikt om elke structurele entiteit in de applicatielaag te modelleren: softwarecomponenten

Nadere informatie

Continuous Delivery. Sander Aernouts

Continuous Delivery. Sander Aernouts Continuous Delivery Sander Aernouts Info Support in een notendop Maatwerk softwareontwikkeling van bedrijfskritische kantoorapplicaties Business Intelligence oplossingen Managed IT Services Eigen Kenniscentrum

Nadere informatie

Projectplan. Elektronica-ICT Artesis. Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce

Projectplan. Elektronica-ICT Artesis. Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce Elektronica-ICT Artesis Projectplan Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce Projectplan ter voorbereiding van de bachelorproef en stage Academiejaar

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh.

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh. Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

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

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Een overzicht Danny Greefhorst Matthijs Maat 19 december 1997 Copyright 1997 Software Engineering Research Centre All rights reserved. Software Engineering Research Centre Stichting

Nadere informatie

Vraag 1... Vraag 2... Vraag 3...

Vraag 1... Vraag 2... Vraag 3... Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat ofwel op 1.5 ofwel op 2 punten, en elke oefening op 10 punten. Het geheel staat op 60. Vraag 1...[.../3]

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

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

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

Ontwikkelmethodiek voor software

Ontwikkelmethodiek voor software voor software Sonja Rouwhorst Instituut voor interactieve media Hogeschool van Amsterdam Datum: 28 januari 2008 Versie: 1 Status: definitief Inhoudsopgave Inleiding... 3 Het proces van software ontwikkelen...

Nadere informatie

Keteininformatiemodellering op basis van Archimate

Keteininformatiemodellering op basis van Archimate Keteininformatiemodellering op basis van Archimate Notatie en voorbeelden versie 0.1 Bert Dingemans Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 Archimate... 3 Domeininformatiemodellen... 4 Modellering...

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Vergelijking Oracle certificering voor Java en het CPP Gecertificeerd Javaprogrammeur van de Open Universiteit

Vergelijking Oracle certificering voor Java en het CPP Gecertificeerd Javaprogrammeur van de Open Universiteit Vergelijking Oracle certificering voor Java en het CPP Gecertificeerd Javaprogrammeur van de Open Universiteit Inleiding Op het gebied van scholing van de taal Java zijn er vele aanbieders op de markt.

Nadere informatie

Checklist basisontwerp SDM II

Checklist basisontwerp SDM II Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance

Nadere informatie

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

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Sinds de kredietcrisis en door opkomende technologieën staan banken

Nadere informatie

MDA experiences in een uitvoeringsorganisatie. Eelco van Mens (Architect, Mn Services) 5 juni 2008

MDA experiences in een uitvoeringsorganisatie. Eelco van Mens (Architect, Mn Services) 5 juni 2008 MDA experiences in een uitvoeringsorganisatie MDA experiences in een uitvoeringsorganisatie Eelco van Mens (Architect, Mn Services) 5 juni 2008 2 Inhoud Korte introductie Mn Services Overwegingen om met

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen

Nadere informatie

De modellen die hiervoor gebruikt zijn zijn: Class diagrams; object diagrams; use case diagrams.

De modellen die hiervoor gebruikt zijn zijn: Class diagrams; object diagrams; use case diagrams. 1 1. Uml is een manier van communiceren. Het werkt met plaatjes en laat jouw modellen maken van software. 2. UML bestaat uit Notations and diagrams. Notations zijn bv, pijltjes; connectors; notities. Diagrams

Nadere informatie

Programmeren in Java 3

Programmeren in Java 3 26 september 2007 Deze les korte herhaling vorige les Unified Modelling Language notatie van een class afleiding pointers abstracte classes polymorphisme dubieuze(?) constructies interfaces Meer over class

Nadere informatie

Agile, Scrum en Kanban in de praktijk

Agile, Scrum en Kanban in de praktijk Agile, Scrum en Kanban in de praktijk Wat is agile en wat kenmerkt agile projecten? Agile in de praktijk: rollen, teams en best practices Hoe om te gaan met requirements in agile projecten? Hoe agile projecten

Nadere informatie

GESTANDAARDISEERD MAATWERK HOEFT NIET DUUR TE ZIJN

GESTANDAARDISEERD MAATWERK HOEFT NIET DUUR TE ZIJN Innervate: Juni 200 GESTANDAARDISEERD MAATWERK HOEFT NIET DUUR TE ZIJN Ze knellen. Je krijgt er blaren van. Je eksterogen steken onophoudelijk. Als je loopt, hoort het zich aan alsof een nest met muizen

Nadere informatie

4. Schematechnieken. In dit hoofdstuk worden drie schematechnieken behandeld:

4. Schematechnieken. In dit hoofdstuk worden drie schematechnieken behandeld: 4. Schematechnieken In dit hoofdstuk worden drie schematechnieken behandeld: aktie-diagrammen, stroomschema's en Nassi-Shneidermandiagrammen. Een schema is een goed hulpmiddel om (vooral wat ingewikkeldere

Nadere informatie

Auditen van Agile projecten

Auditen van Agile projecten Auditen van Agile projecten Platform voor Informatiebeveiliging 10 december 2013 Merijn van der Zalm & Marcel Trijssenaar Agenda Belang van assurance op agile ontwikkelen Agile versus Waterval Perspectief

Nadere informatie

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER Het belang van Data Modellering Studiedag Informatiemanagement Politeia, 22 februari 2013, Gent Open data en de cloud: een revolutie in de informatiehuishouding van de overheid Training Data Modellering

Nadere informatie

Educagen. Wij zijn specialisten in Education en in Gen met een ervaring in consultancy en training van meer dan 20 jaar in de Gen-omgeving.

Educagen. Wij zijn specialisten in Education en in Gen met een ervaring in consultancy en training van meer dan 20 jaar in de Gen-omgeving. Educagen Wij zijn specialisten in Education en in Gen met een ervaring in consultancy en training van meer dan 20 jaar in de Gen-omgeving. Educagen leidt organisaties en hun medewerkers op om systemen

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

Methodiek. Versie: 16/05/2012 13:42:35

Methodiek. Versie: 16/05/2012 13:42:35 Methodiek Versie: 16/05/2012 13:42:35 Inhoudsopgave Methodiek... 2 Onze visie op het functioneel ontwerp... 2 Stappen in het ontwerpproces... 3 Methodiek Inleiding In dit deel van de encyclopedie wordt

Nadere informatie

Module 1 Programmeren

Module 1 Programmeren Module 1 Programmeren Programmeertalen 13 1.1 Inleiding 13 1.2 Programmeertalen in historisch perspectief 13 1.2.1 Machinecode 13 1.2.2 Assembleertalen (assembly) 14 1.2.3 Hogere programmeertalen 15 1.2.4

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

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

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

Chris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren

Chris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Chris de Kok 223548 TDI 3 Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Inhoud Inleiding... 3 Black box / White box... 3 XP... 3 SimpleTest... 3 Eclipse plugin... 4 GroupTest...

Nadere informatie

Tentamen in2705 Software Engineering

Tentamen in2705 Software Engineering Tentamen in2705 Software Engineering Voorbeeld (bijna tweemaal te groot) U mag meenemen naar dit tentamen: Lethbridge, afdrukken PPT slides, afdrukken handouts. 1. De TU wil een nieuw systeem ontwikkelen

Nadere informatie

Agile testen - kwaliteit onder controle

Agile testen - kwaliteit onder controle Agile testen - kwaliteit onder controle Marc Evers Piecemeal Growth Anko Tijman Ordina TestNet 16 maart 2006 www.testnet.org Agenda Wat betekent agile en agile testen Kwaliteitsborging in agile projecten

Nadere informatie

Tools voor canonieke datamodellering Bert Dingemans

Tools voor canonieke datamodellering Bert Dingemans Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze

Nadere informatie