Samenvatting Methodologieën PDF

Summary

This document is a summary of various methodologies in project management, including Agile, Waterfall, Scrum, and Prince2. It details concepts like scope, deliverables, and milestones, with a focus on different phases and approaches for software development and project execution.

Full Transcript

Samenvatting methodologieën HS 1: Introductie & algemeen overzicht.................................................................................................. 2 Kenmerken van een project............................................................................................................

Samenvatting methodologieën HS 1: Introductie & algemeen overzicht.................................................................................................. 2 Kenmerken van een project................................................................................................................ 2 Begrippen............................................................................................................................................ 2 Fasen van een project.......................................................................................................................... 3 Agile vs Waterfall................................................................................................................................. 4 Scrum................................................................................................................................................... 4 HS 2: Agile vs Waterfall............................................................................................................................ 9 Waterfall.............................................................................................................................................. 9 Prince2................................................................................................................................................. 9 Risicomanagement............................................................................................................................ 11 HS3: Testing........................................................................................................................................... 13 Introductie......................................................................................................................................... 13 Testtype............................................................................................................................................. 13 Testlevel............................................................................................................................................. 14 Rollen & verantwoordelijkheden....................................................................................................... 15 Deliverables....................................................................................................................................... 15 HS4: Maintenance................................................................................................................................. 18 Wat is ITIL?......................................................................................................................................... 18 Wat zijn de verschillen tussen CI en CD (CI/CD)?.............................................................................. 18 Service Management......................................................................................................................... 19 Service Operations............................................................................................................................ 20 Configuration Management.............................................................................................................. 23 Service Lifecycle................................................................................................................................. 23 De Conclusies..................................................................................................................................... 24 Léon Wouters | 2ITSOF1 | s143329 HS 1: Introductie & algemeen overzicht Kenmerken van een project Elk project is uniek Elk project heeft specifiek eindresultaat Elk project heeft duidelijke start- en einddatum (indien dit niet voldoet aan bovenstaande criteria -> dagelijkse werk of operations) Begrippen Scope: De gedefinieerde kenmerken en functies van een product, evenals de omvang van het werk dat nodig is om een project te voltooien, vormen samen de scope. De scope bepaalt niet alleen wat we in het project gaan realiseren, maar ook expliciet wat we niet zullen realiseren. Dit zorgt voor een duidelijke afbakening van onze doelen en biedt de klant de zekerheid over wat zij kunnen verwachten. Simpel gezegd: baken je doelen af, wat wil je wat wil je niet. Deliverable: Een deliverable is een finaal of tussentijds product dat wordt opgeleverd als resultaat van een projectactiviteit. Het opleveren van een deliverable is vaak noodzakelijk om een activiteit, fase of project af te sluiten. Simpel gezegd: je eind product Milestone: Een specifiek punt in je project waarbij gekeken wordt naar je budget, scope progress waarna eventueel kan bijgestuurd worden. Triangle of constraint: Verwijst naar de relatie tussen drie belangrijke factoren in je project. Time: Het duur van het project, wanneer het moet worden voltooid. Cost: Het budget dat beschikbaar is voor het project. Scope: Het werk dat moet worden gedaan, de kenmerken en functies van het project. De essentie van de Triangle of Constraint is dat als je bijvoorbeeld de tijd wilt verkorten (sneller afronden), de kosten waarschijnlijk zullen stijgen, of je moet mogelijk de scope verminderen (minder functies toevoegen). Resource Léon Wouters | 2ITSOF1 | s143329 Een resource is een element dat nodig is om een bepaalde activiteit te voltooien. Materieel: computers, werkplekken,.. Menselijk: teamleden, ondersteunend personeel Financieel … Kenmerken en functies Kenmerken en functies verwijzen naar specifieke eigenschappen van het project. Kenmerken: Dit zijn specifieke eigenschappen of eigenschappen van het product. Bijvoorbeeld, als het product een smartphone is, kunnen enkele kenmerken de grootte van het scherm, de resolutie van de camera, of de batterijduur zijn. Functies: Dit verwijst naar wat het product kan doen. Voor dezelfde smartphone kunnen enkele functies zijn: het maken van foto's, het afspelen van muziek, het draaien van apps, enzovoort. Fasen van een project Deze projectfases zien we terugkomen in elk project. Afhankelijk van de projectmethodologie, zijn sommige fases korter of langer en kunnen ze ook parallel lopen of zelfs in een andere volgorde. Je kiest je methodologie afhankelijk van de context, het project, het bedrijf, etc. Er is geen strikte, universele regel die bepaalt welke projectfases exact moeten worden gevolgd in elk project. Maar er is wel een akkoord over de verschillende fases (andere naam, zelfde definitie) Léon Wouters | 2ITSOF1 | s143329 Agile vs Waterfall Wat is een projectmethodologie? Een set van regels & procedures om projecten zo efficiënt en effectief mogelijk te plannen, beheren en uit te voeren. Agile & Waterfall zijn noemers waaronder verschillende projectmethodologieën vaak verdeeld worden. Scrum Scrum is een Agile-raamwerk voor projectmanagement en softwareontwikkeling dat gericht is op flexibiliteit en klantwaarde. Léon Wouters | 2ITSOF1 | s143329 Belangrijke elementen zijn: Sprints: Korte ontwikkelingscycli van twee tot vier weken. Rollen: Product Owner, Scrum Master en een zelforganiserend Development Team. Artifacts: Product Backlog, Sprint Backlog en Increment. Ceremonies: Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective. Empirisme: Transparantie, inspectie en aanpassing voor continue verbetering. Scrum bevordert iteratieve ontwikkeling, klantbetrokkenheid, zelforganisatie en een focus op werkende software. Het raamwerk is ontworpen om snel te reageren op veranderingen en waarde te leveren aan klanten. Principes in Scrum Inspecteren & aanpassen o Plan: Define the goal and decide how (process) these will be delivered o Do: Execute the work according to the plan o Check: Analyse the delivered results and compare with the initial plan o Act: Investigate the plan, results & process to look for improvement. Implement in the next cycle. Iteratief & incrementeel o Iteratief: Scrum werkt in korte, vaste tijdsblokken die “sprints” worden genoemd. Elke sprint is een iteratie en heeft een vastgestelde duur, vaak tussen 2-4 weken. Na elke sprint krijg je een werkend deel van het product, wat betekent dat er in een korte tijd tastbare resultaten zijn. o Incrementeel: Het product wordt incrementeel opgebouwd met elke opeenvolgende sprint. Elke sprint voegt een extra stuk functionaliteit toe aan het bestaande product. Team & samenwerking o Het ontwikkelingsteam is cross-functioneel, wat betekent dat het alle vaardigheden bezit die nodig zijn om het werk van begin tot einde te voltooien. Hierdoor kan het team taken efficiënter oppakken zonder afhankelijk te zijn van externe specialisten. Zelf organiserend o Het ontwikkelingsteam is zelf organiserend, wat betekent dat het team de verantwoordelijkheid heeft voor het plannen, beheren en uitvoeren van het werk binnen een sprint. o Teams nemen gezamenlijk beslissingen over hoe ze het werk aanpakken en verdelen de taken op basis van hun vaardigheden en expertise. Léon Wouters | 2ITSOF1 | s143329 Rollen in Scrum Product Owner Product visie Maximale waarde opleveren binnen tijd & budget Vertegenwoordigt de klant Beheert de product Backlog Visualiseert de product status en vooruitgang Ondersteunt het development team Scrum Master Zorgt dat de Scrum methodologie gevolgd wordt Leider en coach voor het Scrum team Zorgt ervoor dat 'blocking issues' zo snel mogelijk opgelost zijn Faciliteert het team in zelf sturen te zijn en streeft naar continue verbetering Development team Beslissen tijdens de sprintplanning hoeveel werk ze kunnen doen en hoe ze dit gaan organiseren Leveren een 'afgewerkte' producttoevoeging op aan het einde van elke sprint Zijn zelf georganiseerd om zoveel mogelijk werk te kunnen verzetten in een sprint Ondersteunen de Product Owner bij het definiëren van de product Backlog Rituelen in Scrum Sprint Planning Beslissen over hoeveel werk we opnemen (dev team) Product Owner's prioriteiten mee in rekening nemen Max 2h per week van de sprint Product owner legt prio's uit Dev team zorgt dat deze in kleine taken in de sprint worden ingepland Daily Scrum Dev team bespreekt vooruitgang van de sprint Mogelijke 'blocking issues' worden door het team aangehaald Max 15min, elke dag Sprint Review Scrum team toont a.d.h.v. een demo wat er gebouwd is tijdens de sprint Op het einde van de sprint Relevante stakeholders worden uitgenodigd (bv. klant) Feedback wordt verzameld door de Product Owner en wordt verwerkt naar nieuwe product Backlog items Léon Wouters | 2ITSOF1 | s143329 Sprint Retrospective Scrum team toont adhv een demo wat er gebouwd is tijdens de sprint Op het einde van de sprint Relevante stakeholders worden uitgenodigd (bv klant) Feedback wordt verzameld door de product owner en wordt verwerkt naar nieuwe product backlog items Scrum Artefacten Product Backlog Is dynamische lijst van alle taken, functies en technische verbeteringen die nodig zijn voor het product. Wordt beheerd & prioriteert door Product Owner. Backlog vormt basis van werk in sprints. Sprint Backlog Is subset van Product Backlog en bevat taken en doelen die dev team heeft geselecteerd om tijdens specifieke sprint uit te voeren. Wordt gecreëerd tijdens Sprint Planning en dient als leidraad. Increment Is het cumulatieve resultaat van een sprint. Het is het werkende deel van het product dat aan het einde van elke sprint wordt opgeleverd. Elk Increment bouwt voort op eerdere Increments en moet potentieel bruikbaar zijn voor de klant. Epic vs Userstories Een Epic is een grote overkoepelende taak die te groot is om in één enkele sprint te worden voltooid. Het vertegenwoordigt vaak een groot deel van de functionaliteit van het systeem en wordt opgesplitst in kleinere eenheden zoals User Stories. Een User Story is een beknopte beschrijving van een functionaliteit vanuit het perspectief van de eindgebruiker. Het is geschreven in de vorm van "Als [gebruiker], wil ik [actie], zodat [doel]". User Stories zijn specifiek, meetbaar, waardevol voor de gebruiker en schaalbaar. Voorbeeld: In een e-commerceproject is een Epic een “Betalingssysteem”. Dit wordt dan onderverdeeld in User Stories als “Creditcardbetaling implementeren” en “Paypal-integratie toevoegen”. Léon Wouters | 2ITSOF1 | s143329 Wat is Kanban? Kanban is het visualiseren van de werkprocessen. Gebruikt WIP limiet, betekent dat er maximum aantal taken is dat op elk moment in bepaalde kolom mag zijn. Helpt bij voorkomen van overbelasting & bevordert een gestage en efficiënt doorstroming van werk. Kanban werkt goed met ervaren teamleden. Kanban heeft minder deadlines dus minder stress. Kanban kan sneller van richting veranderen. Kanban werkt goed met moeilijk in te schatten projecten (legacy code). Kanban is zeer aanpasbaar (Scrumban). Léon Wouters | 2ITSOF1 | s143329 HS 2: Agile vs Waterfall Waterfall Denk aan het stappenplan om een huis te bouwen, dit is stapsgewijs en elke stap is definitief. Indien een fundering gelegd is en je begint te bouwen erop kan je hier niet op terug gaan. Feedback kan enkel tussen twee fases Teruggaan naar een vorige fase is niet mogelijk Fases worden sequentieel doorlopen Overgang tussen fases wordt gekenmerkt door uitgebreide documentatie Voor en nadelen van de Waterfall methodologie. Pro’s Cons Goed te gebruiken voor kleinere projecten waar Geen tussentijdse feedback van gebruikers. de eisen en wensen vooraf duidelijk zijn Gestructureerd proces, stappen worden één Er wordt pas getest als de applicatie volledig voor één uitgevoerd gebouwd is. (Daardoor kan het tijdrovender en duurder zijn wanneer bugs zich voordoen) Planning, budget en scope zijn vooraf helder Geen of weinig ruimte voor verandering Veel documentatie en dus gemakkelijker om mensen te introduceren tot het project Prince2 PRINCE2 (PRojects IN Controlled Environments) is een gestandaardiseerde projectmanagementmethodologie die principes, thema's, en processen omvat. Principes: De methodologie is gebaseerd op principes zoals zakelijke rechtvaardiging, leren van ervaring, gedefinieerde rollen en verantwoordelijkheden, en gefaseerde aanpak. Thema's: Zeven thema's worden behandeld gedurende het project, waaronder business case, organisatie, kwaliteit, planning, risico, wijziging en voortgang. Léon Wouters | 2ITSOF1 | s143329 Processen: Zeven processen begeleiden het project van start tot finish, waaronder opstarten van een project, initiëren van een project, sturen van een project, beheersen van een fase, beheren van productlevering, beheren van een faseovergang en afsluiten van een project. Rollen en Verantwoordelijkheden: Specifieke rollen en verantwoordelijkheden worden toegewezen aan teamleden om duidelijkheid en efficiëntie te waarborgen. Aanpassing: PRINCE2 is aanpasbaar aan de specifieke behoeften van een project, waardoor het breed toepasbaar is. Deze methodologie biedt een gestructureerd kader om projecten effectief te beheren en is wijdverbreid in gebruik, vooral in het Verenigd Koninkrijk en internationaal. De verschillende processen bij Prince2: 1. Starting up a project 2. Initiating a project 3. Directing a project 4. Controlling a stage 5. Managing stage boundaries 6. Product delivery 7. Closing a project De 7 thema’s bij Prince2: Business Case: Zorg ervoor dat er een goede reden is om het project te doen en dat deze reden gedurende het hele project geldig blijft. Organisatie: Maak duidelijk wie welke rol heeft in het project. Wie doet wat? Wie is verantwoordelijk voor wat? Kwaliteit: Bepaal aan het begin van het project wat 'goede kwaliteit' betekent. Dit helpt om ervoor te zorgen dat het werk op de juiste manier wordt gedaan. Plannen: Schrijf op hoe je de doelen van het project gaat bereiken. Denk hierbij aan welke dingen wanneer moeten gebeuren, hoeveel het gaat kosten, en wat het project uiteindelijk oplevert. Risico: Bedenk vooraf wat er allemaal mis kan gaan tijdens het project, beoordeel hoe waarschijnlijk deze dingen zijn, en bedenk manieren om ermee om te gaan. Verandering: Sta open voor veranderingen, maar beheer ze goed. Hoe ga je om met verzoeken om dingen te veranderen en hoe los je problemen op die tijdens het project opduiken? Vooruitgang: Houd bij hoe ver het project gevorderd is. Hierdoor kun je controleren of je nog steeds op schema ligt en bepalen wat er misschien moet worden aangepast. Léon Wouters | 2ITSOF1 | s143329 Risicomanagement Risicomatrix Léon Wouters | 2ITSOF1 | s143329 Mitigation Risico Acceptatie: Definitie: Het team erkent de bestaande risico's en besluit deze te aanvaarden. Voorbeeld: Een bedrijf lanceert een nieuw product, wetende dat er een risico is dat het mogelijk niet goed zal verkopen. Risicovermindering: Definitie: Actieve stappen worden ondernomen om de risico's te verminderen. Voorbeeld: Een bedrijf ontwikkelt een back-upplan voor het geval een leverancier niet op tijd kan leveren. Risico-overdracht: Definitie: Het team draagt de verantwoordelijkheid voor het risico over aan een andere partij. Voorbeeld: Een bedrijf sluit een verzekering af om financiële verliezen als gevolg van een natuurramp te beperken. Risico Vermijding: Definitie: Het team neemt maatregelen om het risico volledig te vermijden. Voorbeeld: Een bedrijf besluit geen nieuwe producten te lanceren in een verzadigde markt om mogelijke risico's te vermijden. Léon Wouters | 2ITSOF1 | s143329 HS3: Testing Introductie Waarom is gestructureerd testen belangrijk? Testmanagers behouden zo het overzicht en kunnen zorgen dat alles wordt getest. Maakt deel uit van het risicomanagement en zorgt ervoor dat een deel van de geïdentificeerde risico’s kunnen worden afgewend. Definitie: Testen zijn een reeks van handelingen uitgevoerd om te bepalen of de kwaliteit van de geboden oplossing voldoet aan de vereisten en verwachtingen van de uiteindelijke gebruiker. De testfase is een belangrijke fase gezien het dé kwaliteitscontrole is van de ontwikkelde software. Testtype Testlevel Een testtype test een specifiek deel van de Een testlevel groepeert een aantal oplossing en heeft dus een specifiek doel. testactiviteiten binnen een bepaalde fase in de ontwikkeling. Testtype Functionaliteitstesten Verificatie: Controleren of de functionaliteiten van de software correct werken. Validatie: Beoordelen of de functionaliteiten voldoen aan de verwachtingen en vereisten. Uitgevoerd door: Eindgebruikers zijn betrokken bij het uitvoeren van deze tests. Cross-platform testen (portabilitytesten) Zorgen dat de software kan functioneren op diverse platformen. Testen kunnen handmatig worden uitgevoerd, maar ook geautomatiseerde tools kunnen worden gebruikt. Performantietesten Doel: Zorgen voor snelle en efficiënte werking van applicaties. Belang: Snelle prestaties verminderen frustratie en verhogen acceptatie. Aspecten: Kan het testen van grote gebruikersaantallen en piekmomenten omvatten. Léon Wouters | 2ITSOF1 | s143329 Gebruiksvriendelijkheidstesten Doel: Verzekeren dat gebruikers resultaten bereiken met minimale inspanning. Belang: Gebruikers willen efficiënte interacties met applicaties. Betrokkenheid: Eindgebruikers worden actief betrokken bij het testen. Veiligheidstesten Belang: Cybersecurity is steeds crucialer. Focus: Niet alleen gegevens, maar ook rollen en autorisaties moeten worden getest. Inclusie in andere tests: Rollen kunnen worden opgenomen in functionaliteitstesten; er kan ook gebruik worden gemaakt van PEN testing. Regressietesten Doel: Evalueren van de impact van wijzigingen op andere functionaliteiten. Belang: Ondersteunt het principe van herbruikbaarheid in software. Inhoud: Hertesten van alle functionaliteiten, niet alleen diegene die zijn gewijzigd, na elke verandering. Testtype Testlevel Een testtype test een specifiek deel van de Een testlevel groepeert een aantal oplossing en heeft dus een specifiek doel. testactiviteiten binnen een bepaalde fase in de ontwikkeling. Testlevel Unittesten Doel: Controleren van afzonderlijke delen van de oplossing. Uitvoerders: Worden uitgevoerd door ontwikkelaars. Focus: Testen de technische correctheid van specifieke delen van de oplossing. Integratietesten Doel: Evalueren van de samenwerking tussen verschillende componenten. Context: Richt zich op het testen van de gezamenlijke werking van de verschillende delen van de oplossing. Systeemtesten Doel: Volledige test van de oplossing, inclusief alle componenten. Bereik: Niet beperkt tot software, maar omvat alle aspecten van de oplossing. Acceptatietesten Doel: Beoordeling door eindgebruikers of de oplossing gereed is voor implementatie. Focus: Eindgebruikers testen zowel correcte werking als conformiteit aan vereisten en verwachtingen. Léon Wouters | 2ITSOF1 | s143329 Rollen & verantwoordelijkheden Ontwikkelaars Taken: Voeren unit- en integratietesten uit, verbeteren software bij het identificeren van bugs. Testers Taken: Voeren integratie- en systeemtesten uit op basis van vooraf bepaalde scenario's, documenteren resultaten. Benadering: Testen op een objectieve manier. Eind- en sleutelgebruikers Taken: Voeren acceptatietesten uit om de oplossing te accepteren. Focus: Testen functionaliteiten zoals ze die dagelijks zouden gebruiken. Testmanager/Projectmanager Rol: Coördineert testactiviteiten binnen een project. Verantwoordelijkheden: o Volgt testresultaten op. o Stelt testplan op en selecteert resources. o Formuleert en valideert testscenario's. Deliverables Testplan Inhoud: Gedetailleerde beschrijving van de teststrategie en uit te voeren testscenario's. Wordt gedeeltelijk opgesteld tijdens de analysefase. Vereisten: Vrijmaken van resources. Onderdelen: Testscenario's, testdata, verantwoordelijkheden en planning, testtools, acceptatieafspraken. Testscenario’s Inhoud: Beschrijft diverse te testen scenario's gebaseerd op business processen. Omvat zowel functionele als technische scenario's. Bevat stappen, inputdata en verwachte resultaten. Specificeert wat niet getest zal worden. Léon Wouters | 2ITSOF1 | s143329 Testdata Vereisten: Nodig zijn voldoende en relevante testdata. Soorten: Vaak geanonimiseerde operationele data, soms aangemaakte data. Verantwoordelijkheden en Planning: Inhoud: Wie gaat test uitvoeren en wanneer? Coördinatie van scenario's met verschillende rollen. Overweging van diverse gebruikers voor rollen, hoewel dit niet altijd optimaal is. Testtools Inhoud: Beschrijft de tools die worden gebruikt voor testautomatisering, monitoring en documentatie. Afspraken rond Acceptatie Aspecten: Omdat 100% foutloos testen niet mogelijk is, moeten afspraken worden gemaakt over wanneer een oplossing kan worden vrijgegeven. Testdocumentatie Testresultaten worden opgeschreven zodat de testmanager ze kan bekijken. Negatieve Resultaten Technische fouten worden hersteld door ontwikkelaars. Voor functionele fouten wordt gekeken naar wat er oorspronkelijk beslist is. Als het anders is dan bedoeld, wordt het hersteld. Als de functionaliteit wel goed werkt, start men een procedure om veranderingen aan te vragen. Oplossingen Oplossingen moeten worden opgeschreven. Impact op Project Testresultaten hebben veel invloed op het project. Als er te veel fouten zijn, kan het project worden gestopt of gaat de start later plaatsvinden. Tijdig Testen Moderne projecten testen al eerder om hoge kosten van fouten te voorkomen. Vertrouwen en Weerstand Als gebruikers merken dat het systeem niet goed werkt, vermindert het vertrouwen en wordt de weerstand groter, vooral bij externe toepassingen. Léon Wouters | 2ITSOF1 | s143329 Nauwe Relatie met Ontwerpfase Testscenario's worden gebaseerd op processen en een deel van het testplan wordt al opgesteld tijdens het ontwerp. Continu Testen Testen gebeurt niet alleen tijdens de testfase; het gebeurt ook tijdens de bouw- en voorbereidingsfasen. Na go-live is het nog steeds nodig om te testen bij veranderingen of bug-fixes. Aandachtspunten Testen is als een discipline op zich. Het vereist nauwkeurigheid en het kunnen opvolgen van een scenario. Belangrijk om juiste mensen te selecteren om te testen Combinatie van externe en interne testers Testen is een repetitieve taak. Voor veel testen kan men testtools gebruiken. Minder testers nodig dus een lagere kosten. Investering is nodig maar de tools worden herbruikt. Wanneer men werkt met specifieke testbedrijven zijn deze tools inbegrepen. Voorzie voldoende tijd voor je testfase. Onverwachte bugs kosten veel tijd. Initiële scenario’s inschatten is vrij eenvoudig, maar het aantal fouten inschatten niet! Altijd uitgaan van een pessimistisch scenario. Léon Wouters | 2ITSOF1 | s143329 HS4: Maintenance Wat is ITIL? Staat voor Information Technology Infrastructure Library. Het is een set van “best practices” en richtlijnen voor het beheren en verbeteren van IT-service management (ITSM). Service Strategy Hierin worden de strategische doelstellingen en eisen voor het leveren van effectieve IT-services besproken. Service Design Dit richt zich op het ontwerpen van IT-services en processen die voldoen aan de behoeften van de organisatie en haar klanten. Service Transition Dit behandelt de implementatie van nieuwe of gewijzigde services in de operationele omgeving. Service Operation Hierin worden de dagelijkse operationele activiteiten van het beheer van de IT-services besproken. Continual Service Improvement Dit benadrukt het belang van voortdurende evaluatie en verbetering van de processen en services. Wat zijn de verschillen tussen CI en CD (CI/CD)? Continuous Integration (CI): Doel: Het doel van CI is om regelmatig (vaak meerdere keren per dag) en automatisch alle wijzigingen van meerdere ontwikkelaars in één gedeelde repository te integreren. Proces: Ontwikkelaars combineren hun werk regelmatig, en bij elke integratie wordt een geautomatiseerd build- en testproces geactiveerd om te controleren of de nieuwe wijzigingen het bestaande systeem niet breken. Resultaat: Het zorgt ervoor dat het team frequent en snel integreert, waardoor potentiële integratieproblemen vroegtijdig worden ontdekt. Léon Wouters | 2ITSOF1 | s143329 Continuous Delivery (CD): Doel: Het doel van CD is om software op elk moment gereed te hebben voor implementatie, maar de implementatie zelf wordt handmatig geactiveerd. Proces: Na succesvolle integratie met CI, wordt de software automatisch gebouwd, getest en klaargemaakt voor implementatie. De implementatie zelf wordt echter handmatig gestart wanneer het team klaar is. Resultaat: Het zorgt voor een constant beschikbare en geteste software die handmatig kan worden vrijgegeven wanneer nodig. 4 Grote Luiken Service Management Een dienst maken die voldoet aan de wensen van de klant; het draaiende houden en het onderhoud van de dienst. Service Operations Coördinatie en uitvoering van de activiteiten die nodig zijn om de diensten te leveren en te beheren. Configuration Management Controle op IT infrastructuur. Service Lifestyle De levensloop van de geleverde dienst. Service Management De dienst opzetten De dienst technisch en organisatorisch uitwerken De dienst exploiteren, draaiende houden Controleren of de dienst geleverd wordt zoals afgesproken De dienst aanpassen als er nieuwe vereisten zijn of problemen opduiken. Afspraken staan in ‘Service Level Agreement” Léon Wouters | 2ITSOF1 | s143329 Service Operations Service Operations is een essentieel element onderdeel van de ITIL-levenscyclus voor IT- dienstverlening en omvat alle operationele processen die ervoor zorgen dat de klant krijg wat is overeengekomen met de IT-leverancier. Operationele Functies Teams of groepen mensen die verantwoordelijk zijn voor specifieke processen binnen de levenscyclus van een IT-dienst. Voorbeelden van operationele functies zijn de Servicedesk, Technisch Beheer, IT Operationeel Beheer, Applicatiebeheer en Facilitair Beheer. Servicedesk Het aanspreekpunt voor gebruikers met vragen of klachten. Registreert vragen of klachten en herstelt dienstverlening zo snel mogelijk. Niet alleen reactief maar ook proactief werken. Uithangbord van de IT-organisatie. Incident Management en Service Request Fulfillment Beheer van storingen (incidenten) en verzoeken om dienstverlening. Incidenten richten zich op het herstellen van storingen, terwijl service requests vragen naar dienstverlening behandelen. Afbeelding: Service Desk Léon Wouters | 2ITSOF1 | s143329 De 5 processen Incident management Request fulfilment Problem management Access management Event management Incident Management Incident: “Een storing in de normale werking van de website.” Management: zo snel mogelijk terug naar de normale werking Hoe? Urgentie bepalen Quick fix of work around voorstellen Rapporteren … Voorbeeld prioriteiten Voorbeeld ticket response time Wat moet er in een incident report staan voor (bijvoorbeeld) het gebruik van een op maat gemaakt software pakket? Description/summary Steps to reproduce Actual results Expected result Environment Exact date and time of the issue … Handige Tools hiervoor: Jira Service Management Léon Wouters | 2ITSOF1 | s143329 Request Fullfilment Service Request Een verzoek van een gebruiker voor specifieke diensten, variërend van informatie tot toegang tot bepaalde services. Voorbeelden zijn vragen om hulp, advies of verzoeken voor standaardwijzigingen. Servicedesk Respons De Servicedesk reageert afhankelijk van het type verzoek door direct antwoord te geven of door te verwijzen naar de juiste afdeling of specialist. Niet alle verzoeken zijn meteen duidelijk, zoals het voorbeeld waarbij een gebruiker niet kan printen. Problem Management Het analyseren van incidenten om fouten te vinden, waardoor nieuwe incidenten worden vermeden. Zowel proactief als reactief Proactief: incidenten voorkomen (bv. Via log files) Reactief: incidenten dat gerapporteerd zijn oplossen Access Management Gebruikers het recht geven om IT-diensten en gegevens te gebruiken en ongeautoriseerde gebruikers toegang te weigeren om misbruik te voorkomen. Het controleren op toegang tot data en systemen verzekert de: Vertrouwelijkheid Integriteit Beschikbaarheid Event Management (Monitoring) Dit is het beheren van alarmen tijdens hun volledige levenscyclus. Een alarm is een waarschuwing dat een drempelwaarde is bereikt. Vereist dus monitoring! Léon Wouters | 2ITSOF1 | s143329 Configuration Management Configuration Management wordt cruciaal naarmate het ICT-productieproces complexer wordt. Het omvat het beheren van een logisch model van de IT-infrastructuur in een organisatie. Configuratie Item (CI) Een CI is een component die deel uitmaakt van of direct gerelateerd is aan de infrastructuur. Kan fysiek of logisch zijn en kan ook een samenstelling van andere CI's zijn. Voorbeelden zijn toetsenborden, netwerkkaarten, programma's, handleidingen, etc. Configuration Management Database (CMDB) Informatie over CI's en hun onderlinge relaties wordt vastgelegd in de CMDB. De CMDB is een informatiesysteem dat gegevens over configuratie-items beheert. Configuration Management zorgt voor het ter beschikking stellen van zinvolle informatie over CI's, met betrekking tot processen en management. Simpel uitgelegd: de CMDB is eigenlijk een bibliotheek dat een bedrijf maakt van hun IT- infrastructuur zodat het een makkelijk overzicht heeft als er ergens een probleem is met een CI (Configuratie Item bv. Netwerkkaart). Service Lifecycle Servicestrategie Gericht op strategische planning om bedrijfsdoelstellingen te realiseren. Belangrijke aspecten zijn het luisteren naar de langetermijnvisie van de klant, het ontwerpen en implementeren van een dienstverleningsmodel, en de 4 P's (Perspectief, Positie, Plan, Patroon). Serviceontwerp Het ontwerpen van IT-diensten op basis van de gekozen strategie. De 4 belangrijke componenten zijn mensen, processen, producten en leveranciers. Resultaat omvat een Service Catalog met Service Level Agreements (SLA's). Servicetransitie Zorgen dat nieuwe of gewijzigde diensten voldoen aan de vereisten van de klant. Fasen omvatten planning en voorbereiding, bouwen en testen, pilotproductie, planning en voorbereiding van de uitrol, uitrol, en review en afsluiting van de uitrol. Serviceproductie Het uitvoeren van de diensten zoals ontworpen en getest tijdens de servicetransitiefase. Continue serviceverbetering Zorgen dat de dienst wordt aangepast aan veranderende bedrijfsbehoeften door verbeteringen te identificeren en in te voeren. Gebruik van de Cirkel van Deming: Plan, Do, Check, Act. Léon Wouters | 2ITSOF1 | s143329 De Conclusies Het invoeren van ITIL betekent: elke verandering botst op weerstand. En het vereist: Procesmatig werken bij klant Klantgerichte houding bij IT-leverancier Denken in diensten i.p.v. producten Volgen van gemaakte afspraken/procedures/processen The end Léon Wouters | 2ITSOF1 | s143329