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".
  • Werkgroep | Welkom op ITpedia
    De projectorganisatie stuurgroep projectgroep werkgroep De fase Informatie Analyse aan het begin van een project is de belangrijkste fase Veel gebruikers beseffen dit echter niet omdat de opleverdatum nog ver weg is en er slechts enkele personen met de Informatie Analyse bezig zijn die voornamelijk lastige vragen stellen Tenslotte komen van deze personen allerlei fraaie documenten over zaken die de gebruiker gezegd zou hebben en een ruwe schets van een systeem dat wel Science Fiction lijkt waarvan nauwelijks is voor te stellen dat het ooit zal werken Begrijpelijk dat men slechts een paar aanvullende vragen stelt en het verder wel goed vindt Deze fout moet men dus vooral niet maken In de Informatie Analyse worden namelijk zeer belangrijke beslissingen genomen die bepalend zijn voor het welslagen van het project en de levensduur van het informatiesysteem beslissingen die alleen met zeer veel moeite en kosten zijn terug te draaien In deze fase worden de verwachtingen van de gebruiker omgezet in eisen Aan het einde van deze fase mogen er geen onbeschreven vanzelfspreken de behoeften meer zijn Het is daarom van het grootste belang om de rapporten van de Informatie Analyse kritisch te beoordelen Instelling projectorganisatie De kans van slagen van een project is in hoge mate afhankelijk van de acceptatie van het uiteindelijke informatiesysteem Dit is één van de belangrijkste risicofactoren die bij automatiseringsprojecten spelen Dit risico is te vermijden door de gebruikers belangrijke taken in het project te laten vervullen Hierdoor komt een groot deel van de kijk en de beleving van de gebruiker in het informatiesysteem terecht terwijl er geen afstand bestaat tussen gebruiker en ontwikkelaar De gebruiker is medeplichtig aan het eindpro duct en weet waarom bepaalde wensen niet in het systeem zijn opgenomen Om dit te benadrukken wordt in veel gevallen een gebruiker als projectleider aangesteld Bij de start van het project is sprake van een groep materiedeskundige gebruikers die weinig van automatisering weten en een groep automatiseerders die weinig materieken nis heeft Het is de taak van de projectleider dat deze groepen elkaars taal gaan spreken en samen een hecht team gaan vormen Om deze communicatie in goede banen te leiden bestaan beproefde organisatievormen Elke ontwikkelfase begint met activiteiten die een rapport opleveren genaamd Uit gangspunten Plan van aanpak In dit rapport beschrijft de projectleider van die fase hoe hij de komende fase denkt te realiseren Per fase worden een planning en een begroting gemaakt zodat de stuurgroep de voortgang en de kosten van de fase kan bewaken Hiervoor bepaalt de projectleider met welke producten deze fase moet opleveren welke middelen hij daarvoor nodig heeft en welke functionarissen hij daarvoor wil inzetten Als dit bekend is kan de organisatie per fase worden vastge steld Bij de checklisten is de activiteit bepaal uitgangspunten en maak plan van aanpak altijd als eerste bij een fase opgenomen Bij een keuze voor deze activiteit kan een checklist worden gekozen die betrekking heeft op de organisatie Binnen een project kunnen de meest uitgebreide checklisten voor de organisatie worden gevonden bij Informatie

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


  • Het plan van aanpak, een hele klus | Welkom op ITpedia
    In zo n geval zal de ICT afdeling om een opdracht vragen aan de systeemeigenaar Aanpassingen kunnen feitelijk nooit zonder opdracht worden doorgevoerd Om betrokkenen meer bewust te maken van het project wordt in veel gevallen vooraf een workshop georganiseerd Afdelingen die applicaties gebruiken die gekoppeld zijn aan het te veranderen systeem zijn zelf verantwoordelijk voor het aan brengen van de noodzakelijke modificaties Aangezien het slagen van het project vaak afhangt van de juiste werking van deze koppelingen dient de voortgang en rapportage integraal bij dit project mee te lopen De voortgang wordt wel binnen het project bewaakt Een en andere vindt zijn uitwerking in de aan te leveren mijlpaalproducten en de planning De ICT afdeling is verantwoordelijk voor de hardware infrastructuur en de besturingssoftware waaronder het netwerk de verantwoordelijkheid voor de embedded systemen kan overal in de organisatie liggen b v bij de huishoudelijke dienst Queries die niet onder het beheer van een onderhoudsteam vallen zijn de verantwoordelijkheid van de eigenaar applicatiebeheerder Voor de verschillende objecten zal in dit plan van aanpak worden vastgesteld welke mijlpaalproducten moeten worden opgeleverd in het kader van dit project De projectleider is verantwoordelijk voor de voortgangsregistratie en rapportage en het melden van geconstateerde afhankelijkheden 1 5 Einddatum project Hier de deadline en de hardheid daarvan beschreven eventueel onderbouwd met externe factoren zoals de ingangsdatum van nieuwe regelgeving Het project is niet eerder afgerond tot dat alle mijlpaalproducten gereed zijn of zijn ondergebracht in een vervolg project Pas dan kan het projectteam worden ontbonden 2 Projectorganisatie 2 1 Schema In een schema wordt weergegeven hoe het project georganiseerd is Wie rapporteert aan wie en wie zit in welke werkgroep namens welke afdeling Opdrachtgever Projectmanager Projectleider Werkgroepen Deelnemers Ondersteuning 2 2 Rapportage en overleg Van onderstaande rapportages dienen frequentie plaats en tijdstip genoteerd te worden De projectleider rapporteert periodiek aan de opdrachtgever De werkgroepscoördinatoren stemmen periodiek af met de projectleider over de voortgang te verwachten knelpunten en planning Overleg tussen coördinatoren en werkgroepen Overleg tussen projectgroep en eindgebruikers Overleg met de accountantsdienst betreffende de impact van het project Overleg met de beveiligingsfunctionaris betreffende de impact van het project De lijst met geïnventariseerde en geanalyseerde objecten wordt ter verificatie aan de beheerders aangeboden Reviews op de mijlpaalproducten binnen de kaders van dit project zullen door aan te wijzen medewerkers 2 3 Procedures Voor het verdere verloop van de aan te brengen aanpassingen kan veelal gebruik worden gemaakt van de geldende procedures De organisatie kent vaak al een Change Management procedure Naar de toe te passen procedures dient te worden verwezen Tevens dient duidelijk gemaakt te worden op welke locatie de projectorganisatie gevestigd is 2 4 Kwaliteitsbewaking Voor de bewaking van de kwaliteit van de mijlpaalproducten worden een aantal mechanismen onderkend Dit kunnen zijn a Inspecties b Acceptatietesten c Reviews en d Audits Niet al deze mechanismen zullen voor ieder onderdeel worden toegepast De toepassing is sterk afhankelijk van de omvang het platform en de aard van het onderdeel De acceptatietest is echter een vast onderdeel van

    Original URL path: http://www.itpedia.nl/2011/02/02/het-plan-van-aanpak-een-hele-klus/ (2014-12-07)
    Open archived version from archive

  • Planning | Welkom op ITpedia
    die manier ervaringscijfers verzameld waardoor men later in staat is om betere planningen te maken Als een externe leverancier de opdracht krijgt en daarbij verantwoordelijk voor het eindresultaat zal hij er op aandringen om zijn eigen methodiek toe te passen De kans van slagen is dan voor hem het grootst In zo n geval moet er op worden gelet dat voor rapportage en dossiervorming vergelijkbare mijlpaalproducten worden opgeleverd en of die het minimum aan gewenste informatie verschaffen 1 4 Verantwoordelijkheid Veel organisaties kennen een gedecentraliseerde verantwoordelijkheid d w z dat afdelingen zelf verantwoordelijk zijn voor hun maatwerksystemen en onder eigen verantwoordelijkheid aangeschafte systemen Het afdelingshoofd is dan systeemeigenaar opdrachtgever De ICT afdeling speelt in bepaalde projecten soms een sterk initiërende rol vooral als het project technisch gedreven is Daarbij moet worden gedacht aan conversies en migraties naar andere platvormen In zo n geval zal de ICT afdeling om een opdracht vragen aan de systeemeigenaar Aanpassingen kunnen feitelijk nooit zonder opdracht worden doorgevoerd Om betrokkenen meer bewust te maken van het project wordt in veel gevallen vooraf een workshop georganiseerd Afdelingen die applicaties gebruiken die gekoppeld zijn aan het te veranderen systeem zijn zelf verantwoordelijk voor het aan brengen van de noodzakelijke modificaties Aangezien het slagen van het project vaak afhangt van de juiste werking van deze koppelingen dient de voortgang en rapportage integraal bij dit project mee te lopen De voortgang wordt wel binnen het project bewaakt Een en andere vindt zijn uitwerking in de aan te leveren mijlpaalproducten en de planning De ICT afdeling is verantwoordelijk voor de hardware infrastructuur en de besturingssoftware waaronder het netwerk de verantwoordelijkheid voor de embedded systemen kan overal in de organisatie liggen b v bij de huishoudelijke dienst Queries die niet onder het beheer van een onderhoudsteam vallen zijn de verantwoordelijkheid van de eigenaar applicatiebeheerder Voor de verschillende objecten zal in dit plan van aanpak worden vastgesteld welke mijlpaalproducten moeten worden opgeleverd in het kader van dit project De projectleider is verantwoordelijk voor de voortgangsregistratie en rapportage en het melden van geconstateerde afhankelijkheden 1 5 Einddatum project Hier de deadline en de hardheid daarvan beschreven eventueel onderbouwd met externe factoren zoals de ingangsdatum van nieuwe regelgeving Het project is niet eerder afgerond tot dat alle mijlpaalproducten gereed zijn of zijn ondergebracht in een vervolg project Pas dan kan het projectteam worden ontbonden 2 Projectorganisatie 2 1 Schema In een schema wordt weergegeven hoe het project georganiseerd is Wie rapporteert aan wie en wie zit in welke werkgroep namens welke afdeling Opdrachtgever Projectmanager Projectleider Werkgroepen Deelnemers Ondersteuning 2 2 Rapportage en overleg Van onderstaande rapportages dienen frequentie plaats en tijdstip genoteerd te worden De projectleider rapporteert periodiek aan de opdrachtgever De werkgroepscoördinatoren stemmen periodiek af met de projectleider over de voortgang te verwachten knelpunten en planning Overleg tussen coördinatoren en werkgroepen Overleg tussen projectgroep en eindgebruikers Overleg met de accountantsdienst betreffende de impact van het project Overleg met de beveiligingsfunctionaris betreffende de impact van het project De lijst met geïnventariseerde en geanalyseerde objecten wordt

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

  • Wat is een audit, wat is een review? | Welkom op ITpedia
    functiescheiding controle totalen en toegang 4 Operationeel systeem audit Als een informatiesysteem reeds geruime tijd in werking is zal het onderhoud op het systeem toenemen De vraag die dan moet worden beant woord is Is het verantwoord om verder te gaan met het onderhoud of moet een nieuwbouw project worden overwogen In dit type audit worden met name de risico s en de kosten van de verschillende alternatieven tegen elkaar afgewogen zodat een verantwoorde keuze kan worden gemaakt 5 Projectaudit Een projectaudit geeft een oordeel over het verloop van een project Er wordt gekeken naar het volgen van kwaliteitshandboeken procedures en projectplan nen Tussentijdse audit kunnen worden gebruikt om het risico te bepalen en het project bij te sturen Daarbij wordt bekeken of het project voldoende wordt beheerst door de projectma nager en of de diepgang en kwaliteit van de mijlpaalproducten voldoende is Bij een eindaudit het project is het niet meer mogelijk om het project bij te sturen de uitkom sten van de audit kunnen echter worden gebruikt om de projectin richting van volgende projecten te verbeteren 6 Kwaliteitsaudit In voorkomende gevallen kan een klant wensen dat bij een leveran cier een audit wordt uitgevoerd waaruit blijkt hoe de kwaliteit van het maakproces van de producten is De uitkomsten van de audit dienen dan als uitgangspunt voor het vertrouwen in de leverancier Moment van audit Het moment waarop een audit plaatsvindt dient altijd te worden ingepland en is afhanke lijk van het object waarover een audit moet plaatsvinden Het object waarover de audit wordt uitgevoerd moet namelijk gereed zijn Daarnaast kennen we twee type audits te weten de eenmalige en de regelmatige audit De eenmalige audit vind meestal na afronding van een projectmijlpaal plaats De terugkerende audit is anders van aard en dient meestal om een bepaalde situatie te handhaven of tekortkomingen in een kwali teitssysteem te lokaliseren Hierbij moet worden gedacht aan het verlengen van bijvoorbeeld ISO 9000 certificaten waarvoor telkens opnieuw via een audit wordt bepaald of de organisa tie nog aan de voorwaarden voldoet De ISO 9000 audits worden alleen door een certificerende instantie uitgevoerd Auditopdracht en plan De auditopdracht dient duidelijk te maken om wat voor soort audit het gaat en wat het bereik van de audit is Het is belangrijk om het bereik goed in de opdracht af te bakenen en duidelijk aan te geven welke aard van aanbevelingen gewenst zijn Tevens dient te worden aangegeven binnen welk tijdsbestek de audit moet worden uitgevoerd Aan de hand van de opdracht en enkele informerende gesprekken zal het bureau een offerte maken Na gunning van de opdracht kan de eigenlijke audit worden uitgevoerd aan de hand van een auditplan Volgens de ISO 10011 norm worden in dit plan de volgende aspecten nader uitgewerkt Het doel en bereik van de audit nadere uitwerking van de opdracht Identificatie van personen die verantwoordelijkheden hebben met betrekking tot het doel en het bereik Identificatie van de documentatie Identificatie van het auditteam Het tijdstip duur en de lokatie van de audit

    Original URL path: http://www.itpedia.nl/2011/01/23/wat-is-een-audit-wat-is-een-review/ (2014-12-07)
    Open archived version from archive

  • Audittype | Welkom op ITpedia
    doelmatig werkt en voldoende door de hulpmiddelen wordt ondersteund 2 Technische systeemaudit Direct na de ingebruikname van een informatiesysteem kan het systeem technisch worden doorgelicht door een onafhankelijke organisatie De specialisten die op dit type audit worden ingezet moeten zeer bekend zijn het automati seringplatform waarop het informatiesysteem gebaseerd is Het rapport van deze audit zal niet alleen iets over de systeemopzet zoals programmatuur netwerk en database zeggen maar ook ingaan op de onderhoudbaarheid en de kwaliteit van de documenta tie De adviezen uit deze audit kunnen leiden tot groter verbeteringen van de performance en het systeembeheer 3 Functionele systeemaudit De functionele systeemaudit wordt voornamelijk ingegeven vanuit een controle oogpunt en dient vragen te beantwoorden als Is het systeem controleerbaar Is het systeem te beheersen en Levert het systeem voldoende managementinformatie op Er wordt ondermeer gekeken naar functiescheiding controle totalen en toegang 4 Operationeel systeem audit Als een informatiesysteem reeds geruime tijd in werking is zal het onderhoud op het systeem toenemen De vraag die dan moet worden beant woord is Is het verantwoord om verder te gaan met het onderhoud of moet een nieuwbouw project worden overwogen In dit type audit worden met name de risico s en de kosten van de verschillende alternatieven tegen elkaar afgewogen zodat een verantwoorde keuze kan worden gemaakt 5 Projectaudit Een projectaudit geeft een oordeel over het verloop van een project Er wordt gekeken naar het volgen van kwaliteitshandboeken procedures en projectplan nen Tussentijdse audit kunnen worden gebruikt om het risico te bepalen en het project bij te sturen Daarbij wordt bekeken of het project voldoende wordt beheerst door de projectma nager en of de diepgang en kwaliteit van de mijlpaalproducten voldoende is Bij een eindaudit het project is het niet meer mogelijk om het project bij te sturen de uitkom sten van de audit kunnen echter worden gebruikt om de projectin richting van volgende projecten te verbeteren 6 Kwaliteitsaudit In voorkomende gevallen kan een klant wensen dat bij een leveran cier een audit wordt uitgevoerd waaruit blijkt hoe de kwaliteit van het maakproces van de producten is De uitkomsten van de audit dienen dan als uitgangspunt voor het vertrouwen in de leverancier Moment van audit Het moment waarop een audit plaatsvindt dient altijd te worden ingepland en is afhanke lijk van het object waarover een audit moet plaatsvinden Het object waarover de audit wordt uitgevoerd moet namelijk gereed zijn Daarnaast kennen we twee type audits te weten de eenmalige en de regelmatige audit De eenmalige audit vind meestal na afronding van een projectmijlpaal plaats De terugkerende audit is anders van aard en dient meestal om een bepaalde situatie te handhaven of tekortkomingen in een kwali teitssysteem te lokaliseren Hierbij moet worden gedacht aan het verlengen van bijvoorbeeld ISO 9000 certificaten waarvoor telkens opnieuw via een audit wordt bepaald of de organisa tie nog aan de voorwaarden voldoet De ISO 9000 audits worden alleen door een certificerende instantie uitgevoerd Auditopdracht en plan De auditopdracht dient duidelijk te maken om wat voor soort audit

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

  • Mapping IT-procedures over projectfasering | Welkom op ITpedia
    Een project start in de regel met een Informatie Analyse waarin de informatiebehoeften van de gebruikers in kaart worden gebracht Er wordt dan een keuze gemaakt voor het vervolgtraject maatwerk of standaardpakket en voor de te volgen fasering wordt een plan gemaakt Gedurende de levensduur van een applicatie kunnen zich een aantal gebeurtenissen voordoen die een samenhang hebben met de beschreven projectfasering Veel van deze gebeurtenissen zijn gevat in een procedure Deze procedures hebben geen ander doel dan de communicatie over de gebeurtenissen en hun gevolgen te stroomlijnen en de afwikkeling vast te leggen Door een eenduidige vastlegging wordt het mogelijk om de gang van zaken te herleiden en verantwoording te geven over de afwikkeling van de gebeurtenissen Betrokkenen Organisatie Binnen de organisatie dient een duidelijke functiescheiding van IT taken en een verdeling van verantwoordelijkheden te worden gemaakt Globaal zijn 3 groepen te onderscheiden Functioneel beheer vaak onderdeel van de gebruikersorganisatie Technisch applicatiebeheer Ontwikkel Organisatie intern of extern Technisch systeembeheer Verwerkingsorganisatie rekencentrum intern of extern Accenten Vanuit het verleden werden deze groepen herkend aan hun specifieke taken De Functioneelbeheerder hield zich veel bezig met het bijhouden van stambestanden het aanbieden van batchjobs en de controle op de verwerkingen Tegenwoordig ligt het accent meer bij het vertalen van gebruikerswensen naar systeemeisen het bewaken van de aansluiting tussen de verschillende applicaties en het leiden van projecten en releases Het beeld dat in het verleden bij het technisch applicatiebeheer werd opgeroepen was toch vooral die van programmeur die lange tijd bezig was om een programma te maken In deze functie is een duidelijke accentverschuiving geweest in de richting van Informatie analyse en het beheer van de ontwikkelomgeving standaard Doordat ontwikkeltools nu een groot deel van de code genereren is de ontwikkelaar meer gericht op de gebruiker en zijn wensen Er is meer interactie en afstemming Het technisch systeembeheer tenslotte heeft ook een verandering doorgemaakt De helpdeskmedewerker die naar je toe komt om je PC te fiksen of de operator die uren bezig met het wisselen van tapes is verleden tijd Het accent van het bewaken op de juiste verwerking van systemen is verlegd naar de inrichting van de juiste omgeving met de juiste componenten met als insteek om verstoringen zo veel mogelijk pro actief te voorkomen Rollen Iedere fase eist van de betrokkenen vaak een andere rol Daarnaast kan deze rol per project verschillen Zo treedt men de ene keer op als opdrachtgever en een andere keer als klankbord tester of reviewer De ene keer treedt men op als ontwikkelaar van een systeem en de andere keer analyseert men de aansluiting van een standaard pakket op het datamodel In het ene project geeft men advies over de infrastructuur in het andere heeft men de lead bij een migratie De rollen zijn divers en worden meestal op een natuurlijke wijze opgepakt Soms leiden ze echter tot verwarring Daarom is het noodzakelijk dat de rol goed in het Plan Van Aanpak van een project fase wordt omschreven Een standaard werkwijze wordt in dit artikel uitgewerkt

    Original URL path: http://www.itpedia.nl/2011/01/14/mapping-it-procedures-over-projectfasering/ (2014-12-07)
    Open archived version from archive

  • Minimale taakverdeling bij Automatiseringsprojecten is essentieel. | Welkom op ITpedia
    Docker 5 december 2014 Exchange Server patch alsnog onderdeel Patch Tuesday 5 december 2014 Google project Loon blijkt hoogvlieger 5 december 2014 Sinterklaas koopt veel meer online 5 december 2014 Sonylek gegevens 47 000 werknemers les voor elk bedrijf 5 december 2014 Toegang Inloggen RSS Feed Aanvullingen RSS Minimale taakverdeling bij Automatiseringsprojecten is essentieel Doel van de taakverdeling Verantwoordelijkheden daar beleggen waar ze thuishoren Het bevorderen van de kwaliteit van de ontwikkel afdeling als interne dienstverlener Optimaliseren van de inzet van middelen Bevorderen doeltreffende communicatie naar alle betrokkenen Bevorderen van een planmatige aanpak en voorspelbare projecten Achtergrond Automatiseringsprojecten wijken niet af van andere project Specifiek is wel dat deze zich afspelen op een snijvlak van complexe techniek wisselende prioriteiten en formele procedures De ervaring leert dat het vele malen effectiever is om in een vroeg stadium duidelijkheid te hebben op basis waarvan alle partijen zich kunnen binden dan om dit te doen nadat er al veel is geïnvesteerd in een project Dit artikel betreft met name de interactie tussen de ontwikkel afdeling en de gebruikersorganisatie Er is een duidelijke scheiding aan te geven in taken en verantwoordelijkheden Dit neemt niet weg dat projecten beter verlopen op basis van een constructieve samenwerking en wederzijds overleg Als leidraad voor een goede werkwijze dient te worden gewerkt met richtlijnen die zijn gebaseerd op formele normen Door de taken duidelijk te scheiden zijn ook duidelijke mijlpalen te benoemen Een minimale taakverdeling van 2 hoofdtaken is minimaal noodzakelijk Werkwijze Bij ontwikkeling worden twee hoofdfasen onderscheiden het bouwen herbouwen aanpassen van de applicatie en vervolgens het accepteren van de gerealiseerde functionaliteit door de gebruikersorganisatie Bij elke fase zijn er minimale voorwaarden die vóór het begin moeten zijn voldaan Bouwen Ontwikkeling kan alleen plaats vinden op basis van een goedgekeurd en functioneel ontwerp FO Dit FO heeft een formele status als mijlpaal binnen het project Het FO leidt tot een systeem ontwerp SO Het FO wordt aangeleverd door de gebruikorganisatie of wordt in opdracht van de gebruikersorganisatie gemaakt Een FO bevat minimaal de volgende onderdelen met voldoende detail als basis voor een voorspelbaar verloop van het bouwen van de applicatie Beschrijving van de functionaliteit Validatie van de vast te leggen gegevens Toegang autorisatie en beveiliging van de applicatie Samenhang met eventuele externe systemen Gewenste vormgeving en workflow van de applicatie Schaal en prioriteit van de gewenste applicatie Op basis van een compleet FO wordt de planning voor het systeem gemaakt Als er tijdens de bouw van de functionaliteit aanpassingen plaats vinden aan het FO wordt dat na overleg met OO formeel vastgelegd De bouw dient conform de ontwerpen plaats te vinden Accepteren Voor wat betreft het technische aspect van het opleveren wordt de bekende formele werkwijze gehanteerd tussen VO GO en OO Het doel van een oplevering is om te komen tot een naar specificatie werkende applicatie op basis van een compleet testrapport Acceptatie kan alleen plaats vinden op basis van een goedgekeurd testplan Een testplan kan gezien worden als een definitief FO vertaald naar concrete testgevallen

    Original URL path: http://www.itpedia.nl/2011/01/07/minimale-taakverdeling-bij-automatiseringsprojecten-is-essentieel/ (2014-12-07)
    Open archived version from archive

  • Taakverdeling | Welkom op ITpedia
    kleine krachtige RFID tag 5 december 2014 IBM hokt nu ook met Docker 5 december 2014 Exchange Server patch alsnog onderdeel Patch Tuesday 5 december 2014 Google project Loon blijkt hoogvlieger 5 december 2014 Sinterklaas koopt veel meer online 5 december 2014 Sonylek gegevens 47 000 werknemers les voor elk bedrijf 5 december 2014 Toegang Inloggen RSS Feed Aanvullingen RSS taakverdeling Gebruik de 521 IT checklisten van ITpedia met in totaal 22022 vragen Zoek in de omschrijvingen Omschrijving Aantal vragen IT projectfasering Bestaat uit meerdere checklisten Application Services Library ASL Bestaat uit meerdere checklisten Continuïteit Bestaat uit meerdere checklisten Kwaliteitsattributen Bestaat uit meerdere checklisten Functies in de automatisering Bestaat uit meerdere checklisten Webdesign Bestaat uit meerdere checklisten Of zoek naar een woord Fulltekst Laatst gebruikt Exploitatie en auditing op 2014 12 06 17 57 Checklist Toezenden van eerdere beoordelingen per e mail E mailadres applicatiebeheer ASL beheer beveiliging BiSL checklisten copyright formulier Het Nieuwe Werken HNW internet kosten kwaliteit Management methodologie outsoursing project projectfasering projectmanagement SEO Sociale software social media uitbesteden web 2 0 websites WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better Minimale taakverdeling bij Automatiseringsprojecten is essentieel Doel van de taakverdeling Verantwoordelijkheden daar beleggen waar ze thuishoren Het bevorderen van de kwaliteit van de ontwikkel afdeling als interne dienstverlener Optimaliseren van de inzet van middelen Bevorderen doeltreffende communicatie naar alle betrokkenen Bevorderen van een planmatige aanpak en voorspelbare projecten Achtergrond Automatiseringsprojecten wijken niet af van andere project Specifiek is wel dat deze zich afspelen op een snijvlak van complexe techniek wisselende prioriteiten en formele procedures De ervaring leert dat het vele malen effectiever is om in een vroeg stadium duidelijkheid te hebben op basis waarvan alle partijen zich kunnen binden dan om dit te doen nadat er al veel is geïnvesteerd in een project Dit artikel betreft met name de interactie tussen de ontwikkel afdeling en de gebruikersorganisatie Er is een duidelijke scheiding aan te geven in taken en verantwoordelijkheden Dit neemt niet weg dat projecten beter verlopen op basis van een constructieve samenwerking en wederzijds overleg Als leidraad voor een goede werkwijze dient te worden gewerkt met richtlijnen die zijn gebaseerd op formele normen Door de taken duidelijk te scheiden zijn ook duidelijke mijlpalen te benoemen Een minimale taakverdeling van 2 hoofdtaken is minimaal noodzakelijk Werkwijze Bij ontwikkeling worden twee hoofdfasen onderscheiden het bouwen herbouwen aanpassen van de applicatie en vervolgens het accepteren van de gerealiseerde functionaliteit door de gebruikersorganisatie Bij elke fase zijn er minimale voorwaarden die vóór het begin moeten zijn voldaan Bouwen Ontwikkeling kan alleen plaats vinden op basis van een goedgekeurd en functioneel ontwerp FO Dit FO heeft een formele status als mijlpaal binnen het project Het FO leidt tot een systeem ontwerp SO Het FO wordt aangeleverd door de gebruikorganisatie of wordt in opdracht van de gebruikersorganisatie gemaakt Een FO bevat minimaal de volgende onderdelen met voldoende detail als basis voor een voorspelbaar verloop van het bouwen van de applicatie Beschrijving van de functionaliteit Validatie van

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