dinsdag 4 september 2012

Wij zijn verhuisd! We bloggen verder met onze collega's van de afdeling I&M: http://im2punt0.wordpress.com/

woensdag 13 april 2011

prezi

Vast niet nieuw voor sommige van jullie, maar ik was onder de indruk: prezi.com.

Een alternatief voor powerpoint, je kunt er prachtige dingen mee maken. Je werkt natuurlijk online, dus geen applicatie op je pc nodig, en het levert een presentatie op, die je online kan afspelen, maar ook als flash object kan downloaden.

Mjin probeersel staat hier: https://prezi.com/secure/5d82d263bf9ac957fdaab8dfa273f72e245bb97f/

Account is gratis, en als 'educational' user kun je nog gratis upgraden naar een account met wat meer mogelijkheden.

woensdag 2 maart 2011

Voor u gelezen

Mastering the Requirements Process (Second Edition)
Suzanne Robertson, James Robertson
Addison-Wesley Professional, 2006
ISBN: 978-0-321-41949-1
592 pagina's

In de loop van een project blijkt vaak dat nog niet helemaal duidelijk is wat nou precies de eisen zijn voor het eindproduct. We willen een systeem voor X, maar waar moet dat systeem precies aan voldoen? Wie moet het gebruiken? Wat moeten ze er mee kunnen doen? Wat zijn de randvoorwaarden?
Daarmee loop je het risico dat het eindproduct toch niet is wat de opdrachtgever er van verwachtte. Of dat de gebruikers er niet beter of sneller mee kunnen werken dan met wat er al was.

Uiteraard zijn er methodes ontwikkeld om die eisen (oftewel de requirements) vooraf zo goed mogelijk boven tafel te krijgen.
Eén zo'n methode wordt beschreven in het onderhavige boek.

In 15 hoofdstukken, plus 4 uitgebreide appendices, komen het hele proces aan de orde; van de "project blastoff" tot en met het moment dat de requirements voldoende compleet zijn om aan de ontwikkelaars te geven.

Een korte samenvatting:

Hoofdstuk 1. What are requirements?
Inleiding en het een en ander over het "Volere Requirements Process" (waar dit boek op gebaseerd is)

Hoofdstuk 2. The requirements process
Een overzicht van het proces.
Daarbij worden drie soorten projecten onderscheiden, gebaseerd op de mate van formaliteit.


Hoofdstuk 3. Project blastoff
Aan het begin van het project wil je een ruw beeld hebben van wat het eindproduct moet gaan doen en wie de "stakeholders" zijn.
Daarbij is het ook van belang te weten wat er wel en niet bij hoort. Bijvoorbeeld:
als je eindproduct gebruik gaat maken van een bestaand systeem, vallen eventuele wijzigingen of uitbreidingen van dat systeem ook bij je project?
Overigens kan dit ook in de voorfase van het project al gebeuren, als je eerst wil weten of een project wel uitvoerbaar is.

Hoofdstuk 4. Event-driven use cases
Hierin wordt het schrijven van use cases behandeld. "Event driven" wil zeggen: er komt een signaal bij je product
(dat kan een handeling van een gebruiker zijn of een automatisch signaal) en je product reageert daarop.

Hoofdstuk 5. Trawling for requirements
Het is lang niet altijd voldoende om mensen alleen te vragen wat ze willen.
Je mist dan bijvoorbeeld dingen die zij vanzelfsprekend vinden, maar anderen niet.
Daarom worden in dit hoofdstuk diverse technieken besproken om requirements te ontdekken.

Hoofdstuk 6. Scenarios and requirements
Scenarios zijn ook een methode om requirements te ontdekken. Het zijn gedetailleerde uitwerkingen van use cases: wat moet er precies gebeuren? Wat zijn de voorwaarden vooraf? Wat is het eindresultaat van deze use case? Daarbij kan ook naar boven komen dat een use case bestaat uit een stukje "te maken product" en een stukje "bestaat al".
Lang niet alles wat in zo'n scenario staat hoeft dus terug te komen in je eindproduct.

Hoofdstuk 7. Functional requirements
In de "functional requirements" beschrijf je wat je product moet doen om een scenario uit te voeren. Deze requirements kun je vastleggen in data- of domeinmodellen.
NB: in deze fase kijk je nog niet naar de techniek. Je modellen zullen dus niet één-op-één vertaald kunnen worden naar een programmeertaal.

Hoofdstuk 8. Nonfunctional requirements
De "niet-funtionele" requirements beschrijven niet wat je product moet doen, maar hoe goed. Denk aan dingen als: het moet er begrijpelijk uitzien; het moet snel zijn; het moet werken op een standaard computer binnen deze organisatie.

Hoofdstuk 9: Fit criteria
Je hebt nu een heel stel eisen, maar die zijn lang niet altijd SMART geformuleerd. Zie het voorbeeld hierboven: het moet er begrijpelijk uitzien, maar hoe meet je dat?
De belangrijkste les uit dit hoofdstuk is: elk requirement is meetbaar te maken. Zo kun je voor "er begrijpelijk uitzien" stellen "bij een gebruikersonderzoek geeft 90% van de gebruikers aan dat het er begrijpelijk uit ziet".
Vergeet ook niet om hierbij collega's te betrekken die ervaring hebben met testen en gebruikersonderzoeken.

Hoofdstuk 10. Writing the requirements
Hoe schrijf je je requirements zodanig op dat je er ook echt wat aan hebt?
De stakeholders moeten het er mee eens zijn, de ontwikkelaars moeten ze begrijpen en je wilt ook graag een manier om straks bij te houden hoe het staat met de implementatie.
In bijlage B van het boek staat een "requirements specification template" om je op weg te helpen.

Hoofdstuk 11. The quality gateway
Het is een goed idee om de requirements nog eens kritisch te laten bekijken voordat je verder gaat. De kwaliteitscontroleur kijkt naar dingen als "zijn de requirements compleet", "zijn ze onderling consistent", "is dit uitvoerbaar". Ook is het belangrijk om te controleren dat het echt requirements zijn en niet al oplossingen. Een requirement mag wel zijn "het moet werken op mobiele apparaten", maar niet "we gaan een iPhone app maken".
En de kwaliteitscontroleur kijkt of er geen requirements zijn ingeslopen die buiten de scope vallen van wat er in het begin van het project is afgesproken.

Hoofdstuk 12. Prototyping the requirements
Je maakt een prototype op basis van de requirements die je hebt en laat stakeholders daar naar kijken. De kans is groot dat je daarmee nog meer requirements ontdekt. Bijvoorbeeld "je moet hier ook kunnen zoeken" of "je doet hier alsof X altijd voor Y komt, maar in praktijk komt Y ook vaak voor X".
Het moge duidelijk zijn dat dat weer leidt tot aanpassingen van je requirements documenten.

Hoofdstuk 13. Reusing requirements
Veel requirements komen steeds weer terug en zijn dus herbruikbaar. Als je bijvoorbeeld vaak back-office systemen maakt, dan weet je al voor wat voor welke gebruikers het is en wat de technische grenzen zijn ("moet kunnen werken op onze bestaande computers").

Hoofdstuk 14. Reviewing the specification
Op een gegeven moment heb je een stel requirements waar je wat mee kunt. De kwaliteitscontroleur heeft ze goedgekeurd en de ontwikkelaars willen er mee aan de gang. Dat is het moment om prioriteiten te gaan stellen. Welke requirements moeten
als eerste geïmplementeerd worden? Zijn er geen requirements die elkaar in de weg gaan zitten?
De projectleider zal ook willen weten hoeveel tijd en geld het zal gaan kosten om het product te maken en wat ongeveer de planning zal worden.
Bij sommige requirements zul je risico's ontdekt hebben. De stakeholders willen iets heel graag, maar het is nog niet duidelijk of het mogelijk is. Ook die wil de projectleider dan graag weten.
De risico's, kosten en urenschatting kunnen weer aanleiding zijn om de requirements nog aan te passen.
En in het uiterste geval kan op dit punt nog worden besloten om het project toch maar niet voort te zetten, omdat het niet mogelijk zal zijn om iets te maken wat aan de eisen voldoet.

Hoofdstuk 15. Whither requirements
De auteurs beseffen dat het opstellen van goede requirements niet een kwestie is van simpelweg alle stappen uitvoeren die in de voorgaande hoofdstukken zijn beschreven. In dit laatste hoofdstuk geven ze tips over hoe je het proces kunt aanpassen aan je eigen project, wat voor tools je kunt gebruiken en hoe je om kunt gaan met de onvermijdelijk veranderingen in de requirements.

In de bijlagen vind je tenslotte:
Volere Requirements Process Model
Volere Requirements Specification Template (handig als checklist)
Function Point Counting (een manier om urenschattingen te maken)
Project Sociology Analysis Templates (hoe weet ik wie de stakeholders zijn?)

Na lezing van dit boek hebben we een aardig idee van hoe onze projecten nog beter kunnen worden. Het is dan wel van belang dat er in het project ook tijd gereserveerd wordt voor het ontdekken en uitwerken van de requirements.





zondag 23 januari 2011

Voor U Gelezen
Titel: Organiseer je informatie
Aan de slag met thesauri, taxonomieën, tags en topics
Auteurs: H. Magrijn, E. Sieverts, M. van der Linden, P. Becker
Geïllustreerd | gebonden | 240 bladzijden | 24 x 17 cm | 2010
Publisher: Biblion Nbd (September 2010)
http://www.nbdbiblion.nl/?pagina=22659
Language: Nederlands
ISBN: 978 90 5483 954 5




Er is bijna geen beter moment om wat vakliteratuur ter hand te nemen dan te bed met een griep. Te slap om op te staan maar te sterk om domweg niets te doen. Dit boek kreeg ik in mijn hand gedrukt door mijn collega en co-auteur Eric Sieverts en heeft de uitdagende en verleidelijke titel 'Organiseer je informatie'. Uitdagend in de zin dat dit niet alleen een gebiedende wijs is, maar ook dat in deze tijden van 'informatieoverload' het ordenen van informatie een noodzaak is. Verleidelijk ook, want is het niet een droom om al je informatie voor eens en altijd keurig op een rij te hebben na het lezen van een boek? 'Organiseer je informatie' is geclassificeerd als basisboek voor HBO- en GO-opleidingen maar ook voor informatiespecialisten,webmasters en kenniswerkers. Als snellezer heb ik mij schuldig gemaakt aan het overslaan van de ondertitel 'Aan de slag met thesauri, taxonomieën, tags en topics' en kwam daardoor in een totaal ander boek terecht dan ik had verwacht.

In de twaalf hoofdstukken wordt een ferme en brede basis gelegd hoe en met welke gereedschappen informatie georganiseerd kan worden. Met een goed gevoel voor opbouw weten de auteurs de soms subtiele verschillen tussen diverse begrippen, concepten en definities helder uiteen te zetten. De vele sprekende voorbeelden zijn daarbij een prima aanvulling. Intrigerend voorbeeld is de verwijzing naar een youtube fragment van bibliothecaris André van Duin die de boeken sorteert op kleur. Waarom ook niet?
Dit uiterst vermakelijke filmpje is niet direct te vinden op youtube met zoektermen als André van duin , blauwe boeken, bibliothecaris , uitlenen , lenen etc. Het is in werkelijkheid omschreven als 'De dik voor mekaar show - TELETHEATER - Vreemde Bibliotheek met Ron Brandsteder' en te vinden op http://www.youtube.com/watch?v=sg2KRGrkNWA Een beter voorbeeld voor de noodzaak tot organiseren is er niet lijkt mij.

Tijdens het lezen had ik meerdere malen een niet onplezierig gevoel van 'AHA'. In het dagelijkse werk lopen concepten en begrippen onbewust in elkaar over (of lijken soms samen te smelten) en de kracht van het boek is nu juist dat deze stapsgewijs en overzichtelijk beschreven worden. Met recht mag dit boek dus een basisboek heten en wat mij betreft kan het tevens als naslagwerk dienen.

Kan ik na het lezen van dit boek nu mijn informatie organiseren ? Gezien het aantal bestanden in de root van mijn schijf zou ik zeggen : Nee ! Daarbij laat ik mij graag inspireren door het plagende hoofdstuk 7.3 'Is ordening noodzakelijk?'. Verwezen wordt naar het boek 'Everything is miscellaneous: the power of digital disorder' (prachtige titel) van David Weinberger waarbij 'disorder' geen probleem is zolang die 'disorder' maar doeltreffend doorzocht kan worden. Maar....we zijn nu wel weer bij de les en weten hoe het allemaal zou moeten. Ik zou bibliotheken aanraden dit boek bij het kerstpakket te verpakken zodat niet alleen de auteurs hierbij baat hebben maar ook de lezers van het boek die dan nog beter onze informatie kunnen organiseren.

maandag 13 september 2010

Don't cut on innovation, because innovation is essential



Even een preek voor eigen parochie.
In de recente aflevering/uitzending van "This week in libraries" vanuit de OBA, breekt presentator Erik Boekestein een lans voor innovatie. Hij vreest veel bezuinigingen bij bibliotheken, maar:
"There's one thing that I do hope, that's that libraries do not cut on innovation, because innovation, I think, is essential ....".
En als je dan toch gaat kijken kun je meteen een lang interview met Bas meenemen.

Eric

Digitale universiteit laat student wel aan zijn trekken komen

Foto: Edwin Mijnsbergen

Mijn reactie op een opinie van Ewoud Sanders in een NRC weekend-bijlage van 4/5 september [NRC-archief, foto van de krant] heeft de redactionele zeef helaas niet overleefd. Daarom hier alsnog die reactie.


In de bijlage Opinie & Debat van 4 september suggereert Ewoud Sanders dat de digitale student op onze universiteiten niet aan zijn trekken komt. Het daarbij door hem geschetste beeld van zowel 'de student' als 'de universiteit' doet nogal karikaturaal aan en noopt tot enige reactie.

In zijn stuk beschrijft Sanders een wel heel specifiek soort student, met heel specifieke informatiebehoeften, die zeker niet kenmerkend is voor een meerderheid van de studenten waarmee we op universiteiten te maken hebben. Op dit detailniveau zouden we wel duizend soorten studenten met uiteenlopende wensen en behoeften kunnen onderscheiden. Zijn beeld gaat er bovendien vanuit dat studenten zo veel mogelijk van leesvoer in de vorm van hapklare brokken voorzien moeten worden. Nog afgezien van het feit dat het een praktische onmogelijkheid is om centraal die hapklare brokken voor al die verschillende soorten studenten klaar te zetten, moet je dat ook niet willen. Om studenten klaar te stomen voor de later van hen verwachte wetenschappelijke werkwijze is het juist belangrijk dat studenten zelf methoden en technieken ontwikkelen om de voor hun onderzoek relevante informatiebronnen te ontdekken en selecteren. Dat daar in de eerste jaren ondersteuning bij nodig is, behoeft geen betoog. Maar die ondersteuning wordt vanuit universiteitsbibliotheken en faculteiten ook in toenemende mate geboden.
Dat Google voor veel studenten het referentiekader voor hun informatievoorziening is ben ik uiteraard met Ewoud eens. Webzoekmachines hebben echter ook (bij ons allemaal) een verwachtingspatroon van 'instant satisfaction' doen ontstaan. Het resultaat van zoekacties op het web levert meteen de gezochte informatie in zijn volledige vorm op ons beeldscherm, zonder vertragende tussenstap van fysiek bibliotheekbezoek of (online) aanvragen van artikelen die later moeten worden toegestuurd. Sterker nog, die niet online beschikbare artikelen zal de student ook meestal helemaal niet met Google lunnen vinden, zoals Ewoud Sanders suggereert.

Het door Sanders geschetste beeld van de universiteit doet ook geen recht aan de werkelijke huidige situatie. Universiteiten en in het bijzonder universiteitsbibliotheken spelen in dit opzicht al een heel andere rol. Daarbij ter illustratie een paar voorbeelden van de situatie in Utrecht. In de eerste plaats is al heel veel wetenschappelijke informatie digitaal toegankelijk in de vorm van wetenschappelijke artikelen, proefschriften, rapporten en boeken. Voor deze informatie die in veel gevallen niet met Google te vinden is, komen steeds vaker aparte zoekmachines beschikbaar, specifiek gericht op het materiaal waarvoor de betreffende bibliotheek licenties heeft. Zo kan ook voor dit materiaal aan die verwachting van 'instant satisfaction' worden voldaan. In Utrecht is al 10 jaar ervaring met het Omega-systeem dat onder studenten en aankomende onderzoekers populair is, omdat het laagdrempelig, in een enkele Google-achtige zoekgang, directe toegang biedt tot de volledige teksten van al die bronnen.
Eerder gaf ik al aan dat bibliotheken niet ambiëren om voor alle specifieke soorten studenten kant en klare literatuurcollecties klaar te zetten. Wat wel gebeurt, is dat per studierichting verwijzingen naar de daarvoor relevante bronnen worden gegeven, niet alleen naar de door Sanders schijnbaar verfoeide bibliografische databases, maar ook naar de full-text bronnen op dat terrein. Bovendien kan elke Utrechtse student in zijn 'Personal Library' de basiscollectie voor zijn studierichting aanvullen en daarin wieden naar eigen behoefte en inzicht.

Ewoud Sanders suggereert verder nog dat men zich zorgen zou (horen te) maken over het feit dat studenten geen fysieke bibliotheek meer zouden bezoeken. En ook dat dat een nieuw verschijnsel zou zijn. Toen ik zelf 40 jaar geleden als natuurkundige afstudeerde, had ik zelf ook nog nooit een UB van binnen gezien. Nu iedereen toegang heeft tot de eerder geschetste digitale bibliotheek, doet zich het opmerkelijke feit voor dat studenten juist in steeds groter getale de werkplekken van de fysieke bibliotheek blijken te bevolken, ook al is dat misschien om gebruik te maken van die digitale diensten en bronnen die ze ook op hun studentenkamertje online ter beschikking hebben.


Eric Sieverts

zondag 5 september 2010

Expert PHP 5 Tools Boek bespreking

Expert PHP 5 Tools - Dirk Merkel

Voor U Gelezen in drie uur (447 pagina's )
ISBN 978-1-847198-38-9
Aanschaf op basis van 'Look inside this book' van Amazon.





Tegenvaller: het is nu gratis beschikbaar via http://www.fileserve.com/file/t8btUdR/Packtpub.Expert.PHP.5.Tools.Mar.2010.rar
Example Source code: http://www.packtpub.com/files/code/8389_Code.zip
Mijn mening: Expert Tools zijn veelal bekend bij 'PHP experts'. De bijbehorende manuals en docs van dit soort tools zijn dan de meest voor de hand liggende ingangen voor een developer. Het is dan ook een hele opgave om daar nog eens een zinvol boek over te schrijven. Echter de heldere samenvattingen en inzichten in dit boek voegen wel een zekere meerwaarde toe. Neemt niet weg dat bepaalde hoofdstukken overbodig zijn doordat deze zaken aanpakken die zich niet in enkele pagina's laten beschrijven (frameworks, UML, Unit testing). Het is wel een prima overzicht voor de groep die meer wil dan coderen alleen en de 'peripherals' wil verkennen.

Samenvatting

Hoofdstuk 1 Code style and Standards
De auteur geeft tamelijk strikte regels over hoe te coderen.
Enkele instructies:
-gebruik 'heredoc' voor lange strings (page 10)
-scheidt de instantiating (constructor) van de initialisatie bij een object (page 19)
-gebruik altijd require_once (page 22)
-Opmerkelijk is dat de auteur er op staat dat files UNIX style zijn dus geen '\r\n'maar enkel '\n'.Daarbij kan via de tool PHP_CodeSniffer de code gecontroleerd worden op afwijkingen en het is maar goed dat daar een eigen 'style' aan gekoppeld kan worden. Welnu, als iedereen op de wereld daaraan voldoet dan kan globaal code sneller geladen worden en kunnen datacenters toe met minder energie en kunnen we zo bijdragen aan het milieu.
Vlug naar het volgende hoofdstuk want dit onderwerp staat altijd garant voor fundamentalistische discussies.

Hoofdstuk 2 Documentation with phpDocumentor

Allereerst een pleidooi waarom inline documentatie behoort tot 'goede' php code en een kleine inleiding tot phpDoc. Niets nieuws onder de zon met betrekking tot de bestaande manuals van phpDoc. Wel is dit een handig en 'comprehensive' hoofdstuk omtrent phpDoc en zeker het naslaan waard. Aardig weetje is het gebruik van customtags (page 92). In een voorbeeld project schets de auteur vervolgens hoe en waar phpDoc ingepast kan worden.

Hoofdstuk 3: The Eclipse Integrated Development Environment

Specifiek over de Eclipse IDE. De auteur stelt dat Ecplipse de meest stabiele, meest gebruikte IDE tool is die ook nog eens probleemloos voor andere talen gebruikt kan worden. Voortgekomen uit IBM is de tool nu in handen van een non-profit organisatie. In een 'quick overview' komen de voordelen langs zoals highlighting, code completion, code assist, workspaces , projects , phpDoc, templates,debugging etc.
Jammer dat de auteur geen andere alternatieven aanstipt.


Hoofdstuk 4: Source Code and Version Control

Een hoofdstuk omtrent source control met focus op Subversion waarvan het online handboek te vinden is op http://svnbook.red-bean.com/
In het kort worden de diverse concepten en definities van Subversion helder neergezet. De svn command-line client wordt besproken compleet met de reference guide en een voorbeeld hoe een project onder source control te starten. Dit wel op basis van wat custom scripts ('hooks') van de auteur en dat maakt het wat minder generiek. Wel biedt dit dan de mogelijkheid om bijvoorbeeld code standards af te dwingen of notifications te verzenden. Het concept branching en merging komt aan bod inclusief een verhelderend diagram (page 181). Dit allemaal weer via de svn commandline. Nb: voor onze problemen met checkouts op Samba shares kan dit wel een goed alternatief zijn. Andere clients worden kort genoemd zoals Tortoise.
Aardig weetje is WebSVN, een mooi project van SVN om diverse zaken van 1 of meerdere repositories te bekijken. Inclusief RSS. Wellicht een handige feature om ook te installeren.
Zie ook http://www.websvn.info/
De 'best practices' noemt de veelgebruikte indeling 'trunks, tags, branches'. Weliswaar niet verplicht maar wel een indeling die wereldwijd gebruikt wordt.
Dit hoofdstuk is niet alleen waardevol als naslag maar geeft ook net wat extra informatie die ook voor reguliere SVN gebruikers handig is.

Hoofdstuk 5: Debugging 197

Alle debugopties in php.ini komen voorbij evenals enkele core php functies die handig zijn bij debuggen. Varieërend van var_dump tm get_object_vars. Vreemd genoeg ontbreekt het handige 'get_defined_vars'. Dan een uitgebreid voorbeeld van een eigen debug class.
Net iets te breed uitgesponnen temeer daar ook veel voorbeelden te vinden op http://www.phpclasses.org/ en frameworks in het algemeen deze voorzieningen al bieden 'out of the box'. Dan een specifiek stuk over Zend's XDebug. Zend (en ook Eclipse etc) maken het mogelijk om aan een proces te attachen en vervolgens door de code heen te stappen met breakpoints en dump s van vars en parameters.

Hoofdstuk 6: PHP Frameworks 251

Een lijst met frameworks gebaseerd op het MVC pattern. Genoemd worden Zend, CodeIgniter, CakePHP, YII en Symphony. Kohana (HMVC pattern) wordt niet genoemd. Vervolgens wordt dit hoofdstuk gevuld met een lang Zend example. Gezien de docs van Zend zelf een overbodig hoofdstuk.

Hoofdstuk 7: Testing 291

Verhelderend definitie overzicht van

  • unit testing
  • black or white or gray box testing
  • integrationtest
  • continuous integrationtest
  • regression test
  • system test (ketentest)
  • user acceptance test

Testmethodes op basis van het veelgebruikte PHPUnit framework worden nader toegelicht. Dit aan de hand van een codevoorbeeld met een bepaald zoek algorithme wat we willen testen. Dit laat zien dat Unit testing zeer zinvol is maar ook dat dit een leercurve kent en een behoorlijke tijdinvestering vergt.

TDD of Test driven development is het omgekeerde mechanisme. Schrijf de code welke voldoet aan de test. Het diagram op pagina 322 schetst dit iteratieve proces.

Hoofdstuk 8: Deploying Applications 329

Dit hoofdstuk bevat weinig interessante informatie. Het behelst een simpele applicatie (script met database) welke uitgerold wordt mbv. Subversion en andere tools. Het advies om zoveel mogelijk te automatiseren nemen we natuurlijk ter harte zeker waar het gaat om bijvoorbeeld DB schemas updates. Een build tool met uitgewerkt voorbeeld is 'Phing' (pagina 335)

Hoofdstuk 9: PHP Application Design with UML 363

Een overzicht van 14 UML diagrammen en een beknopte beschrijving van UML met een uitgewerkt voorbeeld. Voegt niet veel toe voor ontwikkelaars die reeds werken met UML.

Hoofdstuk 10: Continuous Integration 395

Het laatste hoofdstuk omtrent 'putting it all together'. Uit de summary: 'Continuous Integration is simply a combination of tasks that you are likely to perform anyway during the development and release of a project. The difference, however, is that with continuous integration, you do it earlier and more frequently. Decreasing the time between automated builds allows you to view the development of the project over time rather than to look at a single snapshot of the code. It allows you to keep a fnger on the pulse of your project and catch any problems early on.'