Hierbij de nieuwsbrief van het Vlaams Software Platform (VSP). Graag ontvangen we uw opmerkingen! Stuurt u daarvoor een e-mail naar nieuwsbrief@vsp-vzw.org.
Namens het VSP wensen we u prettige eindejaarsfeesten en een succesvol jaar 2006!
Om u af te melden ("unsubscribe"), uw adreswijziging door te geven of u aan te melden ("subscribe") volstaat het een eenvoudige e-mail te zenden naar nieuwsbrief@vsp-vzw.org. U vindt deze nieuwsbrief binnenkort ook op de VSP website.
De volgende nieuwsbrief verschijnt in februari 2006.
Dit artikel verschijnt tevens in WTCM Techniline en Agoria Online naar aanleiding van het VSP Event: ‘Omgaan met wijzigende klanteisen tijdens uw softwareontwikkeling’, dat in Gentbrugge werd gehouden op 30 november 2005.
Bedrijven die software ontwikkelen voor externe of interne klanten zullen het wel herkennen: terwijl de software nog ontwikkeld wordt, komt de klant al met aanvragen voor veranderingen. Het blijkt voor softwareontwikkelende bedrijven niet altijd evident hier goed mee om te gaan. Reden voor het Vlaams Software Platform (VSP [1]) om een studienamiddag te organiseren rond deze problematiek. Het ging door op 30 november, bij lidbedrijf Dekimo in Gentbrugge. Dit artikel geeft een overzicht van deze problematiek en enkele manieren om hiermee om te gaan.
Het blijkt vaak voor te komen dat de klant om wijzigende specificaties vraagt, als het ontwikkelteam al begonnen is met het ontwikkelen van software, uitgaande van de afgesproken specificaties. Eddy Schuurmans, gedelegeerd bestuurder bij QuESD [2] legt de problematiek uit: “Zo’n wijzigingsaanvraag kan bijvoorbeeld ontstaan doordat de klant een steeds beter beeld krijgt van het systeem dat ontwikkeld wordt, en zo de specificaties beter kan afstemmen op zijn werkelijke behoeften. Of de bedrijfssituatie bij de klant kan wijzigen, bijvoorbeeld door overnames of reorganisaties, waardoor prioriteiten bij de klant verschuiven”. Dit kunnen grote wijzigingen zijn, zoals extra softwaremodules die moeten worden gemaakt, of kleinere wijzigingen, bijvoorbeeld een extra knop op een scherm.
De impact van deze wijzigingen is niet altijd duidelijk, juist bij softwareontwikkeling. Mensen die bijvoorbeeld een huis laten bouwen, voelen van bepaalde wijzigingsaanvragen intuïtief wel aan dat ze een grote invloed hebben op planning en budget. Bijvoorbeeld, de badkamer verhuizen als het gebouw er al staat, of de kleur van de tegeltjes wijzigen als de tegeltjes al gezet zijn, kost geld en tijd. Het blijkt voor klanten veel moeilijker om in te schatten wat de impact is van wijzigingsaanvragen bij softwareontwikkeling. Een wijzigingsaanvraag als de software al bijna af is, om de software ook toegankelijk te laten zijn vanuit thuis, kan bijvoorbeeld grote architectuurwijzingen tot gevolg hebben, wat uiteraard een grote impact heeft op planning en budget. En, bijvoorbeeld, een knop bijprogrammeren op een bepaald scherm, kán grote invloed hebben op planning en budget.
Als niet goed wordt omgegaan met wijzigingsaanvragen, kan dat leiden tot ontsporingen op vlak van budget en planning. Vooral bij aanvragen voor kleine wijzigingen blijkt dit risico in de praktijk zeer vaak voor te komen.
Uit het event bleek dat deze problematiek zeker beheersbaar is. “Wijzigingsaanvragen zijn niet onvermijdelijk”, volgens Eddy Schuurmans. “Werk in je project met duidelijke fasering en heldere doelstellingen per fase, en stem veelvuldig af met de diverse partijen. Dit houdt het budget onder controle. Het is essentieel dat het requirements document, dat de klanteisen beschrijft, volledig en duidelijk is. Zelf werken we nogal eens met een model waarin het opstellen van het requirements document, door ons, volgens ‘fixed price’ gebeurt, zeker als de klant niet precies kan definiëren wat hij nodig heeft. Voor de rest van het projecten wordt dan een vork afgesproken, die gradueel wordt verfijnd.”
Het helpt ook om een mechanisme op te zetten dat met deze wijzigende klanteisen, ofwel ‘change requests’, omgaat. “Eigelijk willen we geen change requests”, aldus Ariane Spiers, Linux Project Manager bij Philips Tass [3], “maar we zijn uiteraard ook niet naïef. Daarom hebben we een aantal aandachtspunten opgesteld om hiermee om te gaan. Change requests moeten liefst zo vroeg mogelijk in het project worden geïdentificeerd. Het kan helpen om prototypes te bouwen, en die met klanten door te spreken. Change requests worden ook niet zomaar ingevoerd, deze worden besproken, samen met de gevolgen, door een change request board waar management van diverse belanghebbende partijen in zetelen. Zo’n board beslist dan over al of niet doorvoeren van een wijzigingsaanvraag”.
De ene softwareontwikkelingmethodiek blijkt meer geschikt te zijn om om te gaan met wijzigende klanteisen dan de ander. Volgens Geert Adriaenssens, CAE Product Engineer bij Scia [4], kan de Scrum-methodiek [5] hierbij een steun zijn. “We werken daarin met zogeheten ‘sprints’, die 5 weken duren. Steeds aan het begin van zo’n sprint wordt met de klant afgesproken welke functionaliteit wordt ontwikkeld. Dit laat de klant toe om tenminste voor iedere sprint precies door te spreken wat de klant wil. Ook andere mechanismen zorgen voor grote inbreng van de klant, die steeds kan bijsturen.”
Op technisch vlak kan een uitgekiende softwarearchitectuur helpen om een systeem te bouwen dat flexibel is aan te passen en uit te bouwen. Zo stelde Hans Doggen, Software Architect bij Inno.com [6]: “Investeren in een flexibele architectuur rendeert. Het is dan wel belangrijk dat de juiste technische keuzes worden gemaakt, zoals juiste ontwikkelraamwerken (‘frameworks’).
De problematiek is zeker beheersbaar. In dit artikel zijn enkele oplossingen de revue gepasseerd:
Dit artikel is tot stand gekomen in samenwerking met het Vlaams Software Platform (VSP). Het VSP wordt ondersteund door het IWT.
Contactpersoon: VSP, Eugene van Roessel
E-mail: eugene.vanroessel@vsp-vzw.org
Tel: +32 (2) 706.85.58
In dit dossier willen we enkele innovatieprojecten van VSP-leden en hun ervaringen op het vlak van Software Process Improvement (SPI) toelichten.
Embedded systems are becoming increasingly complex, more diverse, and are frequently expanded to include more features. As a consequence, the software is constantly changing: within Alcatel Bell rates of 10,000 lines of code changed per week are the norm. Unfortunately, high change rates inevitably erode a well-designed well-documented system and quickly turn it into a maintenance nightmare.
Alcatel Bell's internal development processes are certified with CMM level 3. However these processes do not contribute to the long-term evolution of software. Indeed, the addition of new features sometimes introduces unexpected bugs, breaks design decisions, and distorts documentation. Consequently, it is hard to assess which software components should be refactored and to estimate the effort required to do so. Therefore, the SERIOUS [1] project aims to develop methods, metrics and tools to maintain —even increase— the quality of the software during its evolution. The book "Object-Oriented reengineering Patterns" [2], which originated from prior collaborative research with industry, serves as a source of inspiration for this project.
In Belgium the project partners are Alcatel Bell (http://www.alcatel.be/) and the University of Antwerp, research group LORE (http://www.lore.ua.ac.be/). However, this local consortium participates in a larger ITEA context with other companies in Europe such as Philips and Nokia.
Het Interreg project, Virtueel ICT Experience Prototyping lab (VIP-lab) is in januari 2005 van start gegaan. Dit project heeft als hoofddoelstelling de voordelen van een gebruikersgerichte aanpak bij het ontwerp van een systeem aan te tonen. In de praktijk gebeurt dit door verschillende pilootprojecten uit te voeren waaraan geïnteresseerde bedrijven en organisaties kunnen deelnemen. Ieder pilootproject doorloopt een ontwerpcyclus waarin de eindgebruiker centraal staat. Om u een idee te geven van zo'n gebruikersgerichte ontwerpcyclus, wordt hieronder de stand van zaken rond het eerste pilootproject in de mediasector toegelicht.
Tijdens het aflijnen van het concept bleek al vlug dat een gebruikersgerichte aanpak nuttig kan zijn om het werk van journalisten op locatie te vergemakkelijken. Tegenwoordig zijn er immers voldoende technische hulpmiddelen voor handen om mobiel te werken. Voor een journalist echter, is het bijvoorbeeld niet altijd eenvoudig hoe hij of zij met het Internet kan connecteren alvorens een artikel naar de redactie kan worden verzonden.
Tijdens observaties van journalisten en persfotografen, is nagegaan hoe zij informatie verzamelen en verzenden op locatie. Op basis van deze observaties zijn vervolgens enkele typische gebruikersprofielen en situaties van gebruik beschreven, zogenaamde persona's en scenario's. Hieruit konden we leren dat fotografen minder problemen hebben met het verzenden van bestanden op locatie. Om die reden is beslist de doelgroep van het te ontwikkelen prototype te beperken tot de journalist.
Bovenstaande gebruikersanalyse vormt een eerste stap om tot een conceptueel ontwerp te komen. Om dit meer te detailleren, werd ook een takenanalyse uitgevoerd die schematisch voorgesteld wordt via Hiërarchische Taken Analyse en ConcurTaskTrees. Deze notaties ondersteunen de communicatie met diverse “stakeholders” van de ontwikkeling, zoals opdrachtgevers en ontwerpers.
Bij het schrijven van een artikel en het verzenden ervan, kunnen een aantal stappen duidelijk worden onderscheiden. Om de journalist tijdens deze handelingen te begeleiden, is ervoor geopteerd om de user interface in wizard stijl te ontwerpen. De eerste prototypes bestonden uit schetsen op papier, weliswaar zonder functionaliteit, maar toch een zeer bruikbaar hulpmiddel om met de betrokken partijen over de mogelijke oplossingen te kunnen discussiëren.
De huidige activiteiten van het pilootproject bestaan erin om het prototype te ontwikkelen en dat op bepaalde tijdstippen aan usability testen te onderwerpen in een mobiel usability lab. Verder zijn er veldtesten gepland voor begin 2006, waarbij het prototype zal worden getest in de werkomgeving van de journalist.
Het driejarige project wordt mogelijk gemaakt door de betrokkenheid van het Interreg programma Benelux-Middengebied, en verder financieel ondersteund door beide provincies Limburg, en de Vlaamse en Nederlandse ministeries van economische zaken. Het VIP-lab consortium wordt gevormd door vijf multidisciplinaire partners uit Vlaanderen en Nederland. Coördinator is Universiteit Hasselt (Expertisecentrum voor Digitale Media, EDM), B, en verder participeren: Hogeschool Zuyd (European Centre for Digital Communication), NL; KULeuven (Mediacentrum), B; T.U. Eindhoven (Faculteit Technologie Management), NL en het mediabedrijf De Vlijt in Antwerpen, een dochteronderneming van Concentra Groep. Het VSP is samen met andere koepelorganisaties en financiers vertegenwoordigd in de adviesraad van het project.
Voor meer informatie over of deelname aan de volgende pilootprojecten verwijzen we u naar de VIP-lab website, maar u kan uiteraard ook contact opnemen met projectleider prof. dr. Karin Coninx van het UHasselt-onderzoeksinstituut EDM (e-mail: Karin.Coninx@uhasselt.be, tel: 011/26 84 11).
Sioux Embedded Systems NV ondersteunt verschillende van haar klanten in Software Process Improvement programma's of voert process maturity assessments uit. De laatste jaren wordt daarbij de de facto standaard Capability Maturity Model for Software (SW-CMM) vervangen door haar opvolger Capability Maturity Model Integration (CMMI).
Dit laatste model is een doorontwikkeling van het oude, vertrouwde SW-CMM en bevat vele verbeteringen. Omdat de structuur veranderd is en de meeste formuleringen aangepast zijn, levert toepassing van het model behalve meer gemak ook nieuwe vragen op. Met name op gebied van interpretatie.
Een belangrijke uitbreiding van het CMMI tov het SW-CMM is de dekking van systeemontwikkeling naast software ontwikkeling. Het CMMI wordt daarom in toenemende mate in andere disciplines dan software gebruikt om ontwikkelprocessen te meten en te verbeteren. Zeker electro ontwikkeling, maar ook mechanica vinden bruikbare aanknopingspunten om projectmanagement, ontwikkelactiviteiten, en de ondersteuning daarvan te verbeteren.
Uiteraard levert dat discussie en vragen over toepassing en interpretatie op. Sioux wil graag haar ervaringen op vlak van CMMI en multi-disciplinaire proces verbetering delen en interpretaties toetsen aan de ervaringen van anderen.
De online encyclopedie Wikipedia is thans uitgegroeid tot een collectie van miljoenen artikels in tientallen talen. Het concept is eenvoudig: de encyclopedie wordt gevoed en gereviewed door een ‘community’. Om iets toe te kunnen voegen op Wikipedia, is enkel een web browser nodig, de encyclopedie maakt gebruik van een ‘Wiki’ groupware-applicatie om toevoegingen en wijzigingen te verwerken.
Voor veel mensen is Wikipedia uitgegroeid tot dé referentie bij uitstek wanneer een encyclopedie moet worden geraadpleegd. Door deze interesse werd Wikipedia eerder al verschillende malen uitgegeven op DVD. Hierbij wordt een ‘snapshot’ gemaakt van de dagelijks evoluerende Wikipedia. Binnenkort verschijnt een deel van Wikipedia ook in boekvorm.
De laatste tijd is Wikipedia enkele keren in opspraak gekomen, doordat de authenticiteit van de informatie in vraag werd gesteld. Zo werd Brian Chase berucht doordat hij de biografie van journalist John Seigenthaler had ‘vervalst’ waardoor deze laatste de geloofwaardigheid van Wikipedia in opspraak gebracht heeft. De vergissing is pas na 6 maanden opgemerkt, maar ondertussen was het kwaad al geschied.
Als gevolg van deze (en verwante) discussies over de authenticiteit van de informatie op Wikipedia, werden recent enkele maatregelen getroffen waardoor het moeilijker wordt om een bijdrage toe te voegen. Of deze maatregelen afdoende bescherming bieden, is een ander verhaal. Echter is door een wetenschappelijke studie gebleken dat de kwaliteit van Wikipedia in wezen niet moet onderdoen voor die van de gerenommeerde Encyclopædia Brittannica.
Ondertussen heeft een Wikipedia-medestichter ‘Digital Universe’ opgericht, dat een antwoord moet bieden voor de echtheidsproblematiek door de bijdragen te laten reviewen door een college van (wetenschappelijke) experts. Digital Universe voorziet ook plaats voor boeken en publicaties uit het publieke domein. Het is de oprichters bedoeld om Digital Universe, net zoals Wikipedia, reclamevrij te houden.
Computervirussen hebben hun naam vandaag niet gestolen: dankzij het Internet verspreiden ze zich zeer snel, net als bij een ‘virale’ infectie. Huidige virusbeveiligingen identificeren computervirussen a.d.h.v. een ‘signatuur’. Komt deze signatuur voor in een bestand, dan is de kans zeer groot dat dit bestand geïnfecteerd is. Deze aanpak heeft één groot nadeel: om de signatuur van een virus te bepalen, moet de antivirus-softwareleverancier dit virus hebben geïnspecteerd. Hierdoor loopt een virusscanner altijd achter op het verspreiden van een virus. Met de toegenomen connectiviteit en de hogere datadebieten van het Internet vandaag, verspreiden computervirussen zich veel te snel om oip deze manier nog afdoende te worden tegengehouden.
Verschillende ICT-bedrijven buigen zich over de problematiek. Zo heeft Microsoft een experimenteel ‘honeymonkey’ netwerk opgebouwd om malafide software te kunnen opsporen. Het principe bestaat uit een paar schijnbaar onbewaakte Windows-systemen op het Internet aan te sluiten, en automatisch naar bepaalde sites te laten navigeren. Wordt een systeem aangevallen, dan wordt het geïsoleerd en kan het worden onderzocht. Deze aanpak werd reeds in de augustus-editie van de VSP Nieuwsbrief toegelicht.
Onderzoekers uit Tel-Aviv hebben een theoretisch model gehanteerd, dat steunt op de netwerktheorie. De onderzoekers definiëren ‘honeypots’ als zijnde zelfhelende lokaasmachines die verspreid zitten op het Internet. Voor een buitenstaander lijkt deze machine op een andere, maar intern kan deze machine nagaan of een virus toeslaat, het virus analyseren en een kuur ervoor ontwikkelen. Berekeningen tonen aan dat deze (thans nog zuiver theoretische) aanpak des te doeltreffender wordt naarmate het netwerk groter wordt, waardoor in een zeer groot netwerk een zeer klein aantal van deze lokaas-systemen vereist zijn.
Nu is het nog wachten op een werkende zelfhelende computer om de theorie te valideren. Er wordt al gewerkt aan een kleine demonstrator.
Deze maand heeft de Apache Software Foundation, gekend van de Apache open-bron webserver, het project ‘Beehive 1.0’ voorgesteld. Dit project voorziet in een eenvoudig objectmodel bovenop J2EE en Struts. De basis van Beehive is JSR-175, dat enkele aspecten van declaratief programmeren toevoegt binnen Java.
Deze maand heeft het World Wide Web Consortium (W3C) een uitbreiding van SMIL (Synchronized Multimedia Integration Language) voorgesteld: SMIL 2.1. SMIL is een XML-gebaseerd mediaformaat dat gebruikt wordt in o.a. mobiele telefoons, meer bepaald voor MMS berichten op te stellen. SMIL 2.1 is een extensie op SMIL 2.0, waar aandacht is besteed aan enkele presentatie-aspecten, maar ook aan enkele ingrepen die toelaten de omvang van SMIL-documenten verder te beperken, waardoor minder bandbreedte wordt ingenomen bij transmissie.
Ondertussen werkt het Mobile Web Initiative binnen het W3C verder aan een aantal best practices voor het aanpassen van media-inhoud voor mobiele toepassingen, waarvan een eerste draft op 20 december verschenen is.
De Free Software foundation (FSF) heeft op 1 december een document vrijgegeven dat het proces beschrijft dat zal worden gevolgd bij het herzien van de 3de versie van de Gnu Public License (GPL). De GPL is de meest courante licentievorm van vrije en open source software. Aldus FSF-stichter Richard Stallman is de basisidee voor versie 3 van GPL “het garanderen van 4 ‘basisvrijheden’ de vrijheid de gebruikte software te bestuderen, te kopiëren, te wijzigen en te herverdelen”. Daarnaast wordt aandacht besteed aan de impact op het huidige licentiemodel (van GPL versie 2) van de evoluties die software engineering over de voorbije 15 jaar heeft teweeggebracht.
Een eerste draft van versie 3 wordt ter discussie voorgelegd in januari 2006.
The requirements process—literally, deciding what should be included in software—is destroying projects in ways that aren't evident until it's too late. Some CIOs are stepping in to rewrite the rules.
It seems like every development project begins with the date, and we're held responsible for “making the date”. Making the date is not a development responsibility. Here's why.
Both the Java Virtual Machine (JVM) and the Common Language Runtime (CLR) have a bad history with the dynamic language community since they are designed to support statically-typed languages. Initial implementations of languages from Scheme (Kawa) to Python (Jython), both for the JVM, have had disappointing performances and have almost always involved language sub-setting in one form or another. Even the scripting interoperability story is broken for JVM and CLR. In old COM, Microsoft provided a nice pluggable mechanism called the windows scripting host. Unfortunately, this mechanism disappeared with .NET.