archive-nl.com » NL » I » ITPEDIA.NL

Total: 523

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Plan Van Aanpak | Welkom op ITpedia
    wil je direct inzetbare mensen hebben Bij offshore is dat niet relevant Alle modern ontwikkelde omgevingen lijken sterk op elkaar men is veel sneller dan de gemiddelde Nederlandse programmeur in staat zich snel in te werken in een andere technologie Bovendien heeft men genoeg tijd over tussen maken van functionele specificaties en start van programmeren om zich een ontwikkelomgeving voldoende eigen te maken Domein ervaring U moet juist bedrijfsspecifieke domein ervaring inbrengen uw offshore partner technische kennis Domein kennis bij uw offshore partner is alleen relevant als u niet alleen de IT ontwikkeling maar het hele Business Process overbrengt Risico s in het betrokken land Alle offshore landen zijn risicovol hoe risicovol is niet te voorspellen De manier om risico s te vermijden is meerdere offshore bedrijven te selecteren verspreid over verschillende continenten Verkoopkantoor betrokken land In de praktijk doet een verkoopkantoor alleen verkoop en kan weinig doen voor het bijsturen van het operationele proces Men heeft niet de kennis onvoldoende macht binnen de eigen organisatie Het offshore bedrijf zit in een leuk land waar het prettig toeven is Wij werken als u slaapt argument Offshore bedrijven in India en China zijn zich goed bewust van het nadeel van de tijdverschillen Dus verpakken zij dit nadeel in 24 uurs ontwikkeling argumenten Maar hoe je het ook verpakt het nadeel van het tijdverschil blijft en niemand kan langere tijd meer dan 8 uur per dag effectief werken Actieve steun van de Nederlandse ambassade of consulaat In alle landen worden Nederlanders actief gesteund door de ambassade of consulaat Offshore contract bij offshoring software systeemontwikkeling Een offshore contract afsluiten met een offshore bedrijf over offshoring software systeemontwikkeing in een niet westers land is tijdverspilling Alleen met westerse bedrijven is het zinvol een juridisch sluitend contract af te sluiten deze contracten kunnen worden wel worden afgedwongen Maar dan in de praktijk ook alleen maar als het Westerse bedrijf het offshore bedrijf controleert Als je niet in de luxe verkeert met een controlerend westers bedrijf een contract af te sluiten is de enige mogelijkheid om in begrijpelijke taal te communiceren wat men precies verlangt Maak makkelijk leesbare afspraken en spreek die rechtstreeks punt voor punt door met de manager offshore Deze krijgt dan tegelijk een goed idee over de cultuur van de klant waar men de nadruk op legt en wat men minder belangrijk vindt Invulling van offshore contract en tips offshoring Fixed price afspraken offshore contract een aanrader De offshore knip leent zich uitstekend voor fixed price ontwikkeling Dit heeft bijkomende voordelen van hogere kwaliteit lagere prijs en minder meerwerk achteraf Zowel opdrachtgever als offshore bedrijf worden gedwongen voordat iets wordt ontwikkeld eerst specificaties te maken Geen offshore contract op basis van nacalculatie bij offshoring Ga nooit akkoord met een offshore bedrijf dat capaciteit beschikbaar wil stellen voor een aantrekkelijk uurtarief en projecten primair op nacalculatie wil uitvoeren Door de ruime vraag en geringe aanbod proberen de laatste tijd sommige offshore bedrijven de klant hiertoe te verleiden Met behulp van prachtige termen als dedicated offshore centre manage their work as if it are your own employees wordt dit commercieel verkocht Houd er rekening mee dat men soms veel meer uren op kantoor aanwezig is dan in Nederland maar dat dit niet altijd productief is Programmeurs kunnen nu eenmaal gedurende langere tijd niet meer dan 40 uur per week effectief werken Maar er is ook een harde financiële reden dat u nooit akkoord moet gaan Nee het grote lek zit er niet in dat er met een vork wordt geschreven Dat is iets dat men offshore niet snel zal doen en dat hoeft men ook helemaal niet te doen Het grote lek is dat men bij nacalculatie de langzaamste programmeurs op uw projecten inzetten En de betere programmeurs worden ingezet voor andere klanten die wel zo slim waren om alleen fixed price te willen werken Service Level Agreement deels vergoeden Voor ondersteuning na oplevering kan een Service Level Agreement SLA worden afgesloten Zie ook ICT processen uitbesteden vereist een Demand Organisatie In een dergelijke Agreement wordt geregeld wat de reactie tijd op ondersteuning en gewenste wijzigingen is en hoeveel mensen in principe beschikbaar moeten zijn om deze ondersteuning uit te voeren Deze kunnen als er geen werk is andere taken uitvoeren dus u moet nooit de volledige kosten vergoeden van de beschikbare capaciteit Een kostenvergoeding is echter noodzakelijk want als er een probleem is of u wilt een wijziging uitvoeren dan moet u wel prioriteit voeren En ook hier geldt nooit wijzigingen op nacalculatie laten uitvoeren maar altijd op basis van vooraf opgegeven vaste prijs Duidelijke opzegmogelijkheid van contract De loonkosten van offshore bedrijven stijgen jaarlijks met een behoorlijk percentage Het offshore bedrijf zal dan ook geregeld zijn prijzen moeten verhogen Neem in het contract op dat u dan het contract kunt opzeggen Intellectueel eigendom goed vastleggen Regel natuurlijk het intellectueel eigendom Dat hoort bij de opdrachtgever en moet geregeld worden overgedragen Sluit om deze reden contracten af volgens het Nederlands Recht dan weet u waar u aan toe bent Toestemming en Escrow regeling bij inzet van derden Als in een project componenten van derden worden ingezet wat extra licentie kosten tot gevolg heeft moet het offshore bedrijf vooraf toestemming vragen Als het essentieel is regel dan via een Escrow regeling de toegang tot de sources van de componenten De kosten van Escrow worden dan altijd door de opdrachtgever gedragen Leesbare werkafspraken voor offshore personeel De medewerkers offshore en vaak ook het eigen personeel kunnen juridische documenten niet lezen en gaan ervan uit dat het niet op hen slaat Zorg daarom altijd voor leesbare werkafspraken voor offshore personeel en eigen personeel Deze moeten niet te lang zijn want niemand kan alle regels van een 50 pagina s lang document operationeel in zijn hoofd houden Wees duidelijke en beknopt en beschrijf alleen de hoofdlijnen In de werkafspraken moet een evenwicht worden gevonden tussen vertrouwen en controle Functionele specificaties inshore en offshore eisen Eerst is het nuttig twee misverstanden te noemen rondom functionele specificaties inshore en offshore

    Original URL path: http://www.itpedia.nl/tag/plan-van-aanpak/ (2014-12-07)
    Open archived version from archive


  • Software Ontwikkeling | Welkom op ITpedia
    we gezien hebben dat dit bij software projecten tot problemen leidt wordt deze strikte manier van werken hier niet gevolgd De definitiefase wordt hier gebruikt om een onderzoek naar de eisen en wensen te laten plaatsvinden zodat het project zo goed mogelijk richting krijgt Ook wordt er beschreven wat er allemaal niet gemaakt wordt Dit om de verwachtingen tussen klant en makers helder te krijgen Mocht door het voortschrijdende inzicht in de cyclische fases blijken dat bepaalde eisen en wensen anders ingevuld moeten worden dan is dat bij deze werkwijze mogelijk uiteraard in overleg en goed gedocumenteerd Ontwerpfase Met de eisen en wensenlijst uit de definitiefase kan het projectteam keuzes maken over hoe de software eruit moet komen te zien De ontwerpfase van ICT projecten heeft een ontwerpdocument als resultaat In het ontwerpdocument wordt het concept nader uitgewerkt en in grote lijnen wordt er een technisch ontwerp uitgewerkt Doel is om te onderzoeken hoe de software er zowel technisch als functioneel uit zou kunnen zien een voorbeeld van een functioneel ontwerpdocument is te vinden op iv In dit kader is het handig om in de ontwerpfase te werken met dummy s die voorgelegd worden aan de opdrachtgevers en of klanten en eindgebruikers Een dummy is een snel in elkaar gezet niet werkende of slechts deels werkend stuk software dat vooral dient om het ontwerp te evalueren Dummy s hebben het voordeel boven schema s op papier dat ze er uitzien als het beoogde eindproduct Bij de watervalmethode is het na de goedkeuring van de ontwerpdocumenten door de klant in principe niet meer mogelijk op ontwerpbeslissingen terug te komen Bij de DANS werkwijze kan dat wel De ontwerpdocumenten dienen als eerste uitgangspunt voor de bouwers maar mocht door voortschrijdend inzicht blijken dat er wijzigingen nodig zijn dan kunnen die doorgevoerd worden Als in de cyclische fasen besloten wordt het ontwerp aan te passen dan moet die wijziging niet alleen geprogrammeerd worden maar ook bijgewerkt worden in een zogenaamd projectlog Als naar mening van het projectteam het ontwerp voldoende is uitgewerkt start de cyclische fase Activiteiten ontwerpfase Ontwerpdocumenten opstellen Mock ups dummies maken en evalueren met klant rapportage gekozen ontwerp rapportage van de GOKIT factoren tot nu toe gerealiseerd nieuwe prognose van de globale GOKIT factoren voor de rest van het project prognose van de concrete GOKIT factoren voor de cyclische fase Resultaat ontwerpfase goedgekeurd ontwerpdocument goedgekeurde GOKIT rapportage en prognoses Uitvoering projectleider designers programmeurs eventueel eindgebruikers voor evaluatie ontwerpen Beslissingen Goedkeuring projectleider opdrachtgever eventueel klant Hulpmiddelen zie i voor een handleiding voor het maken van een ontwerp document zie de bijlage 10 voor een model van een projectplan Cyclische fase De werkwijze in de cyclische fase is ontleend aan XP In deze fase wordt een aantal cycli na elkaar uitgevoerd Een cyclus duurt maximaal een tot twee weken In elke cyclus vinden de volgende activiteiten plaats plannen onderzoeken van functionaliteiten ontwerpen van functionaliteiten realiseren van functionaliteiten testen van functionaliteiten opleveren van functionaliteiten Plannen Aan het einde van de ontwerpfase is een inschatting gemaakt van het aantal cycli dat nodig is voor het bereiken van het projectdoel Dit gebeurt op basis van het functionele en technische ontwerp Een cyclus duurt nooit lang ergens tussen de twee en vier weken In een cyclus komen altijd de activiteiten plannen onderzoeken ontwerpen realiseren testen en opleveren voor Per cyclus wordt dus maar gewerkt aan enkele functionaliteiten soms maar aan één De spelregels voor het plannen zijn als volgt De gewenste functionaliteiten worden door de projectleider samen met de klant op zogenaamde storycards opgeschreven Begonnen wordt met de functionaliteiten die bepaald zijn in de definitie en ontwerpfase op storycards te schrijven Op basis van die storycards maken de programmeurs een takenlijst een lijst van dingen die zij moeten doen om die functionaliteit te realiseren Die taken mogen in de regel niet langer duren dan een paar uur Als een taak langer duurt moet hij gesplitst worden in verschillende subtaken of moet de storycard gesplitst worden in meerdere storycards Als een storycard te veel werk is om in één cyclus plaats te vinden moet hij worden teruggegeven aan de klant De klant moet de wensen dan opsplitsen en verdelen over meer storycards Per taak geeft de programmeur aan hoeveel tijd hij er voor nodig denkt te hebben Zo ontstaat een ureninschatting per storycard Op basis van de ureninschattingen van de storycards kan de klant nu samen met de projectleider aangeven welke van de functionaliteiten ze als eerste gerealiseerd willen zien in de eerstvolgende cyclus Hoe lang duurt het om een website te maken en deze te vullen met 50 pagina s tekst en een aantal foto s Een snel antwoord van de ontwerper dat het ongeveer twee weken duurt is veel te grof Het zou best wel eens veel langer kunnen duren Wordt deze taak uitgesplitst dan blijkt dat er een CSS gemaakt moet worden overleggen met de opdrachtgever over het ontwerp het ontwerp programmeren in xhtml de teksten inkorten voor het internet de pagina s vullen met de teksten de foto s geschikt maken voor het internet de foto s plaatsen controle door de klant en de laatste foutjes eruit halen Door het werk uit te splitsen in kleinere delen blijkt het veel meer werk dan aanvankelijk gedacht Ook realiseert de opdrachtgever zich dat hij ook een aantal dingen moet doen Als nu per taak ingeschat wordt hoeveel uur werk het is zal het een veel betere totaalschatting opleveren en zal blijken dat het niet in twee weken kan Als de programmeurs aan de slag gaan houden ze hun uren bij die ze nodig hebben voor het uitvoeren van een taak Vaak blijkt dat ze meer uren nodig hebben dan ze aanvankelijk zelf geschat hadden Doordat ze een terugkoppeling krijgen op hun eigen inschattingen leren de programmeurs steeds betere schattingen te maken Uit de praktijk blijkt dat naarmate een project een tijdje loopt er een redelijk constante factor verschil is tussen de schattingen van de programmeurs en de werkelijk benodigde aantallen uren Deze factor wordt de

    Original URL path: http://www.itpedia.nl/tag/software-ontwikkeling/ (2014-12-07)
    Open archived version from archive

  • Managed ICT services | Welkom op ITpedia
    dit soort problemen op te lossen maar slagen daar maar mondjesmaat in Miscommunicatie is aan de orde van de dag en dit heeft een nadelige invloed op het projectverloop Projectleider optimisme en onbetrouwbare planning Projectleider optimisme is een chronische kwaal waarvoor het juiste medicijn nog niet gevonden is De omvang en complexiteit van het werk wordt door zowel opdrachtgevers projectmanagers als ICT specialisten vrijwel altijd chronisch onderschat Geen wonder dat projecten altijd uitlopen Dit probleem wordt nog eens versterkt doordat men meestal niet beschikt over ervaringscijfers weinig ervaring heeft met vergelijkbare referentie projecten en niet beschikt over goede planningsmethoden Daarbij geldt dat formele planningsmethoden alleen goed werken bij het plannen van mechanische herhaald uit te voeren stappen Zoals u hierna verder kunt lezen ontbreken deze mechanisch uit te voeren stappen bij de meeste ICT projecten Het gevolg daarvan is dat veel planningen onbetrouwbaar zijn Productieproces softwareontwikkeling is dienst verlening Het productieproces bestaat grofweg uit drie belangrijke stappen In de eerste stap analyse wordt bepaald welk product gemaakt moet worden Dit kan een kantoorpand informatiesysteem of auto zijn In de tweede stap wordt het product ontworpen rekening houdend met de voorhanden zijnde technieken en componenten In feite wordt in deze stap ook het productieproces ontworpen De derde stap is het maken van het product volgens het ontwerp Soms één keer kantoorpand informatiesysteem soms vaker auto Het onderscheid tussen de ontwerpproces en productiefase is niet altijd eenvoudig te maken Het belangrijkste onderscheid is dat het denkwerk in de ontwerpfase gebeurt terwijl in de productiefase slechts een min of meer mechanische uitvoering plaatsvindt namelijk het bouwen van het ontworpen product gebruikmakend van standaard componenten Bij de meeste ICT projecten is er sprake van softwareontwikkeling Het kan gaan om het ontwikkelen van een compleet nieuw informatiesysteem het uitbreiden van een standaard softwarepakket met maatwerkfuncties of het integreren van verschillende ICT systemen Bij softwareontwikkeling is het onderscheid tussen de tweede stap ontwerp en derde stap bouw echter nauwelijks aanwezig Weliswaar worden programmeren en testen vaak als bouw aangemerkt maar bij nader inzien is dit een voortzetting van het ontwerp met andere middelen Tijdens het programmeren worden nog steeds beslissingen genomen over het ontwerp Het uiteindelijke product is het eerst werkende exemplaar van het ontworpen systeem Dat moet vervolgens grondig getest worden en aan de hand van de testresultaten wordt daarna het ontwerp weer aangepast Van serieproductie is bij systeemontwikkeling nauwelijks sprake of het moet gaan om basale kant en klare standaard applicaties zoals Word of Excel Softwareontwikkeling is vrijwel altijd de analyse en het ontwerp van een eenmalig product Er zitten geen eenvoudige mechanische stappen in die ook nog eens eenvoudig te plannen zijn Het produceren van ICT systemen op basis van herbruikbare standaard componenten Component Based Development en open source wint na een langzame start wel snel terrein maar is nog lang niet gemeengoed Met andere woorden softwareontwikkeling is in veel gevallen een ontwerpproces en geen productieproces en daardoor moeilijk te plannen en te beheersen Complexiteit door veelvoud ICT systemen Door de jaren heen is er bij veel organisaties een complexe situatie ontstaan van tientallen tot soms wel honderden ICT systemen waarvan onduidelijk is hoe ze exact werken en op welke manier deze systemen aan elkaar gekoppeld zijn Voor ieder aandachtsgebied marketing verkoop productie service financiën voor ieder nieuw product verzekering zorgdienst tijdschrift telefoonabonnement voor iedere processtap informeren offreren contracteren service en voor ieder contactkanaal website email telefoon balie automaat is steeds weer een nieuw systeem gebouwd De invoering van de vele geïntegreerde Enterprise Resource Planning ERP systemen heeft dit probleem maar ten dele opgelost Al deze ICT systemen zijn door verschillende leveranciers en softwareontwikkelaars op verschillende manieren gebouwd waarbij steeds weer andere hulpmiddelen gebruikt zijn Vaak ontbreken systeemdocumentatie en gebruikershandleidingen en worden deze legacy systemen voortdurend aangepast aan veranderende eisen waardoor de onderhoudbaarheid afneemt Deze situatie wordt nog complexer doordat steeds meer ICT systemen aan elkaar gekoppeld moeten worden Denk aan de invoering van E Business frontoffice backoffice CRM frontoffice backoffice kanalen of de ontwikkeling van nieuwe producten diensten en serviceconcepten Senso Beertender pakketverzekeringen woonzorgdiensten reisarrangementen Het eindresultaat is een ondoorzichtige brei van ICT systemen waardoor de impact en duur van aanpassingen en uitbreidingen vooraf moeilijk in te schatten is Softwareontwikkeling is vakmanschap Het uitvoeren van projecten en het ontwikkelen van ICT systemen lijken nog steeds ambachtelijke bezigheden Het wordt wel eens vergeleken met de bouwwereld aan het begin van de vorige eeuw Dit is een van de belangrijkste oorzaken van de onberekenbaarheid van projecten Het gebruik van hulpmiddelen zoals projectsimulatie scenarioanalyse risicomanagement computerondersteund ontwerpen programmageneratoren en computerondersteund testen staat nog in de kinderschoenen Projecten en softwareontwikkeling zijn daarom sterk afhankelijk van het vakmanschap de ervaring en het inzicht van individuele projectmanagers en technisch specialisten Gebrek aan ervaring bij ICT diensten Iedere ICT dienst en bijbehorend project lijkt wel uniek Nieuwe context opdracht doel resultaat nieuwe aanpak en werkwijze nieuwe projectmedewerkers nieuwe methoden en technieken nieuwe hulpmiddelen nieuwe technische infrastructuur nieuwe onervaren projectleider etc Ervaring en routine zijn maar moeilijk op te bouwen en effectief aan te wenden Van herhaalbaarheid en voorspelbaarheid is slechts sporadisch sprake Het plannen van projecten blijft daardoor een crime Iedere keer wordt het wiel opnieuw uitgevonden door nieuwe uitvinders Organisaties letten onvoldoende op of er genoeg ervaring aanwezig is in het project en of men voldoende gebruikt maakt van proven technology Kwaliteitszorg en kwaliteitssysteem bij ICT projecten Kwaliteitszorg is bij veel organisaties een onbekend fenomeen Standaards en richtlijnen ontbreken of worden sporadisch gevolgd Organisaties beschikken niet over een kwaliteitssysteem en kwaliteitscontroles worden niet uitgevoerd Het kwaliteitsdenken is niet ingebed in de organisatie en onafhankelijke kwaliteitsfunctionarissen zijn zeldzaam De kwaliteit van projecten is dus vooral afhankelijk van de kwaliteit van individuele projectmedewerkers Het resultaat laat zich raden want kwaliteit is nu eenmaal dun gezaaid Onervaren ICT projectmanager Onderzoek heeft uitgewezen dat veel van de problemen waarmee ICT projecten kampen veroorzaakt worden door de wijze waarop de projectmanager functioneert en dan vooral door diens gebrek aan ervaring Deze onervarenheid kan zich op vele terreinen uiten te weinig gezag te veel

    Original URL path: http://www.itpedia.nl/2011/07/21/managed-ict-services/ (2014-12-07)
    Open archived version from archive

  • Managed ICT Services | Welkom op ITpedia
    de fout om gebruikers en andere belangenpartijen niet onvoldoende of veel te laat in het project te betrekken Een ander probleem is dat gebruikerseisen onduidelijk en aan veranderingen onderhevig zijn De wereld draait door dus u kunt wachten op aanpassingen door voortschrijdend inzicht Ook wil men tijdens het project vaak meer dan oorspronkelijk de bedoeling en gepland was Strakke projectbeheersing ontbreekt maar al te vaak op dit punt En als het goed geregeld is met Request for Proposals RFQ s dan zijn er vaak 3 organisatielagen die moeten beslissen over een wijziging waardoor de mensen op de werkvloer maanden moeten wachten op voorgestelde wijzigingen Verder zijn de huidige methoden en technieken onvoldoende geschikt om gebruikerseisen eenduidig en voor alle partijen op begrijpelijke wijze vast te leggen ICT leveranciers proberen met pilots simulaties prototyping workbenches en speciale ontwerpmethodieken dit soort problemen op te lossen maar slagen daar maar mondjesmaat in Miscommunicatie is aan de orde van de dag en dit heeft een nadelige invloed op het projectverloop Projectleider optimisme en onbetrouwbare planning Projectleider optimisme is een chronische kwaal waarvoor het juiste medicijn nog niet gevonden is De omvang en complexiteit van het werk wordt door zowel opdrachtgevers projectmanagers als ICT specialisten vrijwel altijd chronisch onderschat Geen wonder dat projecten altijd uitlopen Dit probleem wordt nog eens versterkt doordat men meestal niet beschikt over ervaringscijfers weinig ervaring heeft met vergelijkbare referentie projecten en niet beschikt over goede planningsmethoden Daarbij geldt dat formele planningsmethoden alleen goed werken bij het plannen van mechanische herhaald uit te voeren stappen Zoals u hierna verder kunt lezen ontbreken deze mechanisch uit te voeren stappen bij de meeste ICT projecten Het gevolg daarvan is dat veel planningen onbetrouwbaar zijn Productieproces softwareontwikkeling is dienst verlening Het productieproces bestaat grofweg uit drie belangrijke stappen In de eerste stap analyse wordt bepaald welk product gemaakt moet worden Dit kan een kantoorpand informatiesysteem of auto zijn In de tweede stap wordt het product ontworpen rekening houdend met de voorhanden zijnde technieken en componenten In feite wordt in deze stap ook het productieproces ontworpen De derde stap is het maken van het product volgens het ontwerp Soms één keer kantoorpand informatiesysteem soms vaker auto Het onderscheid tussen de ontwerpproces en productiefase is niet altijd eenvoudig te maken Het belangrijkste onderscheid is dat het denkwerk in de ontwerpfase gebeurt terwijl in de productiefase slechts een min of meer mechanische uitvoering plaatsvindt namelijk het bouwen van het ontworpen product gebruikmakend van standaard componenten Bij de meeste ICT projecten is er sprake van softwareontwikkeling Het kan gaan om het ontwikkelen van een compleet nieuw informatiesysteem het uitbreiden van een standaard softwarepakket met maatwerkfuncties of het integreren van verschillende ICT systemen Bij softwareontwikkeling is het onderscheid tussen de tweede stap ontwerp en derde stap bouw echter nauwelijks aanwezig Weliswaar worden programmeren en testen vaak als bouw aangemerkt maar bij nader inzien is dit een voortzetting van het ontwerp met andere middelen Tijdens het programmeren worden nog steeds beslissingen genomen over het ontwerp Het uiteindelijke product is het eerst werkende exemplaar van het ontworpen systeem Dat moet vervolgens grondig getest worden en aan de hand van de testresultaten wordt daarna het ontwerp weer aangepast Van serieproductie is bij systeemontwikkeling nauwelijks sprake of het moet gaan om basale kant en klare standaard applicaties zoals Word of Excel Softwareontwikkeling is vrijwel altijd de analyse en het ontwerp van een eenmalig product Er zitten geen eenvoudige mechanische stappen in die ook nog eens eenvoudig te plannen zijn Het produceren van ICT systemen op basis van herbruikbare standaard componenten Component Based Development en open source wint na een langzame start wel snel terrein maar is nog lang niet gemeengoed Met andere woorden softwareontwikkeling is in veel gevallen een ontwerpproces en geen productieproces en daardoor moeilijk te plannen en te beheersen Complexiteit door veelvoud ICT systemen Door de jaren heen is er bij veel organisaties een complexe situatie ontstaan van tientallen tot soms wel honderden ICT systemen waarvan onduidelijk is hoe ze exact werken en op welke manier deze systemen aan elkaar gekoppeld zijn Voor ieder aandachtsgebied marketing verkoop productie service financiën voor ieder nieuw product verzekering zorgdienst tijdschrift telefoonabonnement voor iedere processtap informeren offreren contracteren service en voor ieder contactkanaal website email telefoon balie automaat is steeds weer een nieuw systeem gebouwd De invoering van de vele geïntegreerde Enterprise Resource Planning ERP systemen heeft dit probleem maar ten dele opgelost Al deze ICT systemen zijn door verschillende leveranciers en softwareontwikkelaars op verschillende manieren gebouwd waarbij steeds weer andere hulpmiddelen gebruikt zijn Vaak ontbreken systeemdocumentatie en gebruikershandleidingen en worden deze legacy systemen voortdurend aangepast aan veranderende eisen waardoor de onderhoudbaarheid afneemt Deze situatie wordt nog complexer doordat steeds meer ICT systemen aan elkaar gekoppeld moeten worden Denk aan de invoering van E Business frontoffice backoffice CRM frontoffice backoffice kanalen of de ontwikkeling van nieuwe producten diensten en serviceconcepten Senso Beertender pakketverzekeringen woonzorgdiensten reisarrangementen Het eindresultaat is een ondoorzichtige brei van ICT systemen waardoor de impact en duur van aanpassingen en uitbreidingen vooraf moeilijk in te schatten is Softwareontwikkeling is vakmanschap Het uitvoeren van projecten en het ontwikkelen van ICT systemen lijken nog steeds ambachtelijke bezigheden Het wordt wel eens vergeleken met de bouwwereld aan het begin van de vorige eeuw Dit is een van de belangrijkste oorzaken van de onberekenbaarheid van projecten Het gebruik van hulpmiddelen zoals projectsimulatie scenarioanalyse risicomanagement computerondersteund ontwerpen programmageneratoren en computerondersteund testen staat nog in de kinderschoenen Projecten en softwareontwikkeling zijn daarom sterk afhankelijk van het vakmanschap de ervaring en het inzicht van individuele projectmanagers en technisch specialisten Gebrek aan ervaring bij ICT diensten Iedere ICT dienst en bijbehorend project lijkt wel uniek Nieuwe context opdracht doel resultaat nieuwe aanpak en werkwijze nieuwe projectmedewerkers nieuwe methoden en technieken nieuwe hulpmiddelen nieuwe technische infrastructuur nieuwe onervaren projectleider etc Ervaring en routine zijn maar moeilijk op te bouwen en effectief aan te wenden Van herhaalbaarheid en voorspelbaarheid is slechts sporadisch sprake Het plannen van projecten blijft daardoor een crime Iedere keer wordt het wiel opnieuw uitgevonden door nieuwe uitvinders Organisaties letten

    Original URL path: http://www.itpedia.nl/tag/managed-ict-services/ (2014-12-07)
    Open archived version from archive

  • Kickoff | Welkom op ITpedia
    project Uw eerste project bijeenkomst is een gelegenheid om je plan te delen om het project tot een goed einde te brengen U dient gebruik te maken van deze eenmalige kans om de groep positief te energizen de juiste verwachtingen te stellen en richting te geven die u zult helpen het project te voltooien op tijd en binnen budget Als je je niet voorbereidt op deze bijeenkomst zul je het project in gevaar brengen vanaf het begin Wanneer u de kickoff meeting verlaat moet iedereen aan het project team op dezelfde verwachtingen werken Uw voorbereiding vooraf zal bepalen of uw kickoff meeting het grootste voordeel zal bieden aan uw teamleden Vergadering voorbereiding Stap 1 Ontwikkeling van de doelstellingen van het project en de te leveren producten Vaststelling van deze elementen zullen de beslissingen die je moet nemen bepalen voor met name de personele bezetting van het project en de ontwikkeling van het projectplan Schrijf ze op en bevestig uw definities met het project eigenaars de gerechtvaardigden en initiatiefnemers van het project Stap 2 Identificeer de leden van het projectteam en hun verantwoordelijkheden Resource behoeften variëren afhankelijk van de grootte de complexiteit en aard van het project De middelen bestaan uit vier belangrijke groepen vanuit uw organisatie om uw project goed te ondersteunen Operationeel Corporate Support Management Technische deskundigheid Het ontwikkelen van een projectteam lijst met contactpersonen die de naam verantwoordelijkheid afdeling fysieke locatie telefoonnummer faxnummer en e mail adres voor elk lid omvat Deze distibueer je aan je team Stap 3 Ontwikkelen van een project aannames lijst Het is belangrijk voor leden van het projectteam op de hoogte van belangrijke aannames die gelden voor het project Bijvoorbeeld de veronderstelling dat elk teamlid is geselecteerd en ter beschikking gesteld aan het project door hun manager om het succes ervan te waarborgen Wanneer de teamleden aan het project zijn toegewezen moeten ze zich ook committeren aan de taken die ze toegewezen krijgen Alleen dan kan het project slagen Stap 4 Ontwikkelen van het voorlopige projectplan U kunt veel tijd besparen door alvast vooraf de taken verantwoordelijkheden en tijdschema s van het projectplan uit te zetten Het doorlopen van deze uitwerking zal u helpen te valideren of u de juiste middelen hebt helpt bij het opsporen van risico s en het bepalen van de geschikte tijdslijnen voor taken en mijlpalen Gebruik welke middelen je nodig hebt om je te helpen met het projectplan Het punt wat je wil bereiken is dat je een concept plan klaar hebt liggen waarmee je de kick off ingaat Hiermee bespaar je tijd en krijgt het project een snellere start Realiseer je dat het plan niet is uitgewerkt tot in elk detail Eigenlijk zou het dat nooit moeten worden Tot in de kickoff meeting is het een goed kennisdocument Als je in de kick off het team hebt samengesteld en de verantwoordelijkheden hebt toegewezen zou je de teamleden moeten vragen de gevraagde verantwoordelijkheden te valideren Het plan zal vastgesteld worden op het eerste project status overleg Stap 5

    Original URL path: http://www.itpedia.nl/tag/kickoff/ (2014-12-07)
    Open archived version from archive

  • Meeting | Welkom op ITpedia
    project Uw eerste project bijeenkomst is een gelegenheid om je plan te delen om het project tot een goed einde te brengen U dient gebruik te maken van deze eenmalige kans om de groep positief te energizen de juiste verwachtingen te stellen en richting te geven die u zult helpen het project te voltooien op tijd en binnen budget Als je je niet voorbereidt op deze bijeenkomst zul je het project in gevaar brengen vanaf het begin Wanneer u de kickoff meeting verlaat moet iedereen aan het project team op dezelfde verwachtingen werken Uw voorbereiding vooraf zal bepalen of uw kickoff meeting het grootste voordeel zal bieden aan uw teamleden Vergadering voorbereiding Stap 1 Ontwikkeling van de doelstellingen van het project en de te leveren producten Vaststelling van deze elementen zullen de beslissingen die je moet nemen bepalen voor met name de personele bezetting van het project en de ontwikkeling van het projectplan Schrijf ze op en bevestig uw definities met het project eigenaars de gerechtvaardigden en initiatiefnemers van het project Stap 2 Identificeer de leden van het projectteam en hun verantwoordelijkheden Resource behoeften variëren afhankelijk van de grootte de complexiteit en aard van het project De middelen bestaan uit vier belangrijke groepen vanuit uw organisatie om uw project goed te ondersteunen Operationeel Corporate Support Management Technische deskundigheid Het ontwikkelen van een projectteam lijst met contactpersonen die de naam verantwoordelijkheid afdeling fysieke locatie telefoonnummer faxnummer en e mail adres voor elk lid omvat Deze distibueer je aan je team Stap 3 Ontwikkelen van een project aannames lijst Het is belangrijk voor leden van het projectteam op de hoogte van belangrijke aannames die gelden voor het project Bijvoorbeeld de veronderstelling dat elk teamlid is geselecteerd en ter beschikking gesteld aan het project door hun manager om het succes ervan te waarborgen Wanneer de teamleden aan het project zijn toegewezen moeten ze zich ook committeren aan de taken die ze toegewezen krijgen Alleen dan kan het project slagen Stap 4 Ontwikkelen van het voorlopige projectplan U kunt veel tijd besparen door alvast vooraf de taken verantwoordelijkheden en tijdschema s van het projectplan uit te zetten Het doorlopen van deze uitwerking zal u helpen te valideren of u de juiste middelen hebt helpt bij het opsporen van risico s en het bepalen van de geschikte tijdslijnen voor taken en mijlpalen Gebruik welke middelen je nodig hebt om je te helpen met het projectplan Het punt wat je wil bereiken is dat je een concept plan klaar hebt liggen waarmee je de kick off ingaat Hiermee bespaar je tijd en krijgt het project een snellere start Realiseer je dat het plan niet is uitgewerkt tot in elk detail Eigenlijk zou het dat nooit moeten worden Tot in de kickoff meeting is het een goed kennisdocument Als je in de kick off het team hebt samengesteld en de verantwoordelijkheden hebt toegewezen zou je de teamleden moeten vragen de gevraagde verantwoordelijkheden te valideren Het plan zal vastgesteld worden op het eerste project status overleg Stap 5

    Original URL path: http://www.itpedia.nl/tag/meeting/ (2014-12-07)
    Open archived version from archive

  • 10 tips om usability te borgen in agile projecten | Welkom op ITpedia
    agile Scrum projecten is er een stap die altijd voor de iteratieve sprints komt het definiëren van het productbacklog Het productbacklog is de masterlijst van alle gewenste functionaliteiten in het product Bij de start van een agile project wordt niet verwacht dat er al een uitputtende lijst gemaakt kan worden Agile gaat immers uit van voortschrijdend inzicht Er wordt dan ook niet heel veel tijd in gestoken Meestal worden de meest voor de hand liggende dingen opgeschreven wat vaak al meer dan genoeg is voor de eerste sprint Dat neemt niet weg dat het maken van het productbacklog een fase op zich is waar veel aandacht aan besteed moet worden Dit is een ideaal moment om wat user research te doen en businessdoelen vast te stellen Probeer ook een globaal beeld te vormen van de interactie die jij bij het product en de gebruikers vindt passen Gebruik dit vervolgens allemaal bij het schrijven van de gebruikerscenario s user stories Denk ook alvast na hoe je in de rest van het project om wilt gaan met user usability research 4 Hak je ontwerpwerk in brokken maar voorkom dat ontwerptijd in het gedrang komt Dit kun je doen door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties Voor contentgedreven websites is dit een stuk lastiger dan voor de meeste applicaties In applicaties zijn functionaliteiten vaak te relateren aan specifieke acties knoppen menu items en daardoor goed te isoleren Bij veel websites dragen vaak veel pagina s direct of indirect bij aan de conversie Een gemiddelde contentpagina is een puzzelstukje in meerdere scenario s Hoe hak je dus het interactieontwerp van een website op in brokken Een aanpak die ik zelf onlangs gebruikt heb is beginnen met de basisbouwstenen van een site structuur navigatie en generieke functionaliteiten en daarna pas één voor één onderdelen als home nieuws en project uitwerken Risico hierbij blijft natuurlijk dat je eilandjes ontwerpt in plaats van een coherente user experience zoals ik in mijn eerste artikel al aangaf Patton adviseert organiseer de user stories in een schema beperk je niet tot alleen prioriteren Een schema helpt het grote plaatje te blijven zien 5 Werk parallel aan de huidige iteratie vooruit aan de volgende en evalueer test de vorige Bron Case Study of Customer Input For a Successful Product Lynn Miller Bovenstaande afbeelding vat het mooi samen in iteratie X test iteratie X 1 ontwerp iteratie X 1 en doe alvast user research voor iteratie X 2 6 Maak prototypes simpeler low fidelity naarmate de samenwerking met ontwikkelaars intensiveert Eigen ervaring als je samenwerkt met een nieuwe outsourcing partij ergens in India of Jordanië dan moet het functioneel ontwerp exact laten zien en beschrijven wat er gebouwd moet worden Wat er staat wordt letterlijk genomen en wat er niet staat wordt niet opgepakt Omgekeerd is het wellicht overbodig om in detail te modelleren en beschrijven hoe een bepaald component zich moet gedragen als je naast de developer zit en continu overlegt over features 7 Gebruik prototypes wireframes voor discussie

    Original URL path: http://www.itpedia.nl/2012/03/27/10-tips-om-usability-te-borgen-in-agile-projecten/ (2014-12-07)
    Open archived version from archive

  • Agile | Welkom op ITpedia
    de rol die de User Experience professional inneemt in het project Jeff Patton adviseert Als UX professional neem je in de rol van product owner verantwoordelijkheid voor business goals Product owners werken in het verleden het heden en de toekomst Ontwikkelteams werken enkel aan de huidige iteratie en zijn daarnaast hooguit bezig de vorige release te repareren De product owner vervult veel rollen Advocaat van de business begrijpt de behoefte van de opdrachtgever en selecteert een mix van features die zijn doelen helpt bereiken Advocaat van de klant begrijpt de behoefte van de organisatie die het product koopt en selecteert een mix van features die waardevol voor hem zijn Advocaat van de gebruiker kan vanuit de gebruiker uitleggen waarom het product wel of niet voor hem werkt en aangeven hoe hij het product wel wil kunnen gebruiken Materiedeskundige beantwoordt technische vragen over het domein o a gebruik gebruiker organisatie markt aan degenen die het product maken Ontwerper voegt business klant en gebruikersbehoeften samen in een productontwerp dat voor iedereen bevredigend is Bewaakt coherentie terwijl het product wordt gemaakt en uitgebreid Communicator is in staat om de visie achter en de bedoeling van het product te communiceren daarmee helpen feature en ontwerpbeslissingen te nemen Besluitnemer neemt bij conflicterende doelen belangen en of meningen moeilijke productbeslissingen 2 Word een ontwerpfacilitator Design isn t something that designers produce design is a process that designers facilitate Leah Buley Adaptive Path Idealiter denkt iedereen in je agile team mee over ontwerp Faciliteer het team daarin Gebruik bijvoorbeeld workshops om informatie te verzamelen en te analyseren ontwerpideeën te vormen anderen te betrekken in het ontwerpproces onderzoek en kennis te delen Design by community is not design by committee Leisa Reichelt Disambiguity Samenwerken in ontwerp betekent niet dat dat jij niet meer verantwoordelijk bent voor het ontwerp Gebruik je team klanten en gebruikers om informatie en inzichten te verzamelen en te betrekken in besluitvorming Sommige beslissingen neem je als team andere neem jij als ontwerper en product owner 3 Onderzoek modelleer en ontwerp vooraf maar niet teveel Ook in agile Scrum projecten is er een stap die altijd voor de iteratieve sprints komt het definiëren van het productbacklog Het productbacklog is de masterlijst van alle gewenste functionaliteiten in het product Bij de start van een agile project wordt niet verwacht dat er al een uitputtende lijst gemaakt kan worden Agile gaat immers uit van voortschrijdend inzicht Er wordt dan ook niet heel veel tijd in gestoken Meestal worden de meest voor de hand liggende dingen opgeschreven wat vaak al meer dan genoeg is voor de eerste sprint Dat neemt niet weg dat het maken van het productbacklog een fase op zich is waar veel aandacht aan besteed moet worden Dit is een ideaal moment om wat user research te doen en businessdoelen vast te stellen Probeer ook een globaal beeld te vormen van de interactie die jij bij het product en de gebruikers vindt passen Gebruik dit vervolgens allemaal bij het schrijven van de gebruikerscenario s user

    Original URL path: http://www.itpedia.nl/tag/agile/ (2014-12-07)
    Open archived version from archive



  •