AXI*Helpdesk 3e lijn - van incident naar issue

AXI * HELPDESK 3

_LIJN

Van Incident naar Issue

Analyse document

Afstudeerstage

AXI Breda

Analyse document

Naam: Jeroen Roosendaal j.roosendaal@stu.avans.nl Studentnummer: 1099210

Datum: 21-Juni-2010

Versie: 1.0

Bedrijf: AXI bv.

Bedrijfsbegeleider: Patrick Groetelaers pgrt@axi.nl

Docentbegeleider: Tommy Heunks tam.heunks@avans.nl Academie: Academie voor ICT&Business

Opleiding: Informatica Course: Werkend Leren 2 Periode: Kwartaal 3 + 4

Inleiding:

De klant maakt gebruik van een APEX applicatie om incidenten door te geven aan de helpdesk. De klant gebruikt de helpdesk verder om issues en releases te bekijken.

Een incident is een call die een klant doorspeelt naar de helpdesk. Dit document zal alleen gaan over calls die bij de derde lijn van de helpdesk terechtkomen. De derde lijn wordt ontwikkeling genoemd. Een incident komt altijd terecht bij ontwikkeling. Nadat een incident is aangemeld door de klant, kan dit incident worden verwerkt door ontwikkeling en zal dit incident worden afgesloten. Het incident kan ook worden omgezet naar een issue. Dit gebeurt als voor de oplossing van een incident een aanpassing aan de software moet

worden gedaan. De klant zal op de hoogte worden gebracht als een incident wordt omgezet naar een issue. Een klant kan zelf geen issues aanmaken, dit kan alleen gedaan worden door ontwikkeling.

Een release bestaat uit een aantal issues. Deze issues worden geselecteerd door

ontwikkeling. De klant kan een overzicht zien van alle releases die voor hem van toepassing zijn. De klant kan ook reageren op deze releases. Als een release bij een klant is test staat, dan zal de klant deze release kunnen accepteren. Als de release wordt geaccepteerd, dan kan de klant ook aangeven in welke omgeving de release mag worden geïnstalleerd door ontwikkeling. Een klant kan zelf geen releases aanmaken.

Ontwikkeling maakt gebruik van forms, om de functionaliteiten van de helpdesk te

gebruiken. Voor deze groep gebruikers zijn de functionaliteiten complexer en omvangrijker. Ontwikkeling ontvangt de incidenten van de klant en beoordeeld deze. Er kan worden

gekozen om van een incident een issue te maken. Een incident kan worden afgesloten, ook als er een issue van is gemaakt. Om tot de oplossing van een issue te komen, zal er altijd een aanpassing aan de software worden gedaan. Deze aanpassingen kunnen worden vastgelegd bij het issue. Ook de beschrijving van de oplossing kan worden vastgelegd. Een issue maakt ook gebruik van een aantal statussen die verzet kunnen worden, naarmate de oplossing van het issue vordert. Deze statussen kunnen naar de klant toe gecommuniceerd worden. Als een issue is afgesloten kan deze worden opgenomen in een release. Een release bestaat uit een aantal issues die samen de release zullen vormen. Van de release kan een release note worden gemaakt.

In dit document zullen de verschillende scenario’s voor het gebruik van de derde lijns helpdesk naar voren komen. Van deze scenario’s zullen verschillende use cases gemaakt worden. Per onderdeel zal er ook een sequence diagram in staan. Als laatste komt een klassendiagram aan bod.

Inhoud

INLEIDING: ... 3

1. SCENARIO’S ... 5

1.1 AANMELDEN BIJ HET SYSTEEM: ... 5

1.2 INCIDENTEN AANMELDEN: ... 6

1.3 INCIDENT / ISSUE BEKIJKEN: ... 6

1.4 RELEASE BEKIJKEN: ... 7

1.6 ISSUE AANMAKEN: ... 8

1.7 INCIDENT BEOORDELEN EN OMZETTEN NAAR ISSUE: ... 8

1.8 ISSUE OPENEN EN VERWERKEN: ... 9

1.9 RELEASE INVOEREN: ... 10

1.10 RELEASE BEWERKEN: ... 10

2. USE CASES ... 12

2.1 AANMELDEN BIJ HET SYSTEEM: ... 12

2.2 INLOGGEGEVENS OPVRAGEN: ... 12

2.3 GEGEVENS CONTROLE: ... 13

2.4 COMMENTAAR TOEVOEGEN: ... 13

2.5 INCIDENT / ISSUE BEKIJKEN: ... 13

2.6 ISSUE AANMAKEN: ... 14

2.7 ISSUE BEHEER: ... 14

2.8 RELEASE BEHEER: ... 15

2.9 RELEASE ACCEPTATIE: ... 15

3. USE CASE DIAGRAM:... 16

3.1 USE CASE DIAGRAM: AANMELDEN ... 16

3.2 USE CASE DIAGRAM: ISSUE BEHEER ... 17

3.3 USE CASE DIAGRAM: RELEASE BEHEER ... 18

3.4 USE CASE DIAGRAM: TOTALE SYSTEEM ... 19

4. KLASSENDIAGRAM: ... 20

5. SEQUENCE DIAGRAM: ... 22

5.1 SEQUENCE: INLOGGEN ... 22

5.2 SEQUENCE: INLOG OPVRAAG ... 23

5.3 SEQUENCE: COMMENTAAR TOEVOEGEN ... 23

6. OMGEVINGEN ... 25

6.1 ARCHITECTUUR: ... 25

1. Scenario’s

De scenario’s beschrijven hoe de gebruiker het systeem gebruikt. Er zijn verschillende scenario’s mogelijk per functie van het systeem. Er is altijd 1 scenario dat het pad beschrijft dat de gebruiker volgt als het systeem op de goede manier wordt doorlopen. Dit is het main succes scenario. Per functie zijn er ook alternatieve scenario’s. Deze scenario’s treden in werking als een gebruiker het systeem op een wijze doorloopt, die afwijkt van het succes scenario.

1.1 Aanmelden bij het systeem:

De gebruiker moet zich eerste bekend maken bij het systeem, alvorens hij de functies van het systeem kan gaan gebruiken. Aanmelden is voor klant en ontwikkelaar hetzelfde.

Main Success Scenario:

De klant opent zijn internet browser en surft naar de helpdesk. Hij komt in het beginscherm waar hij zijn inloggegevens in moet vullen. De klant voert eerst zijn inlognaam in, en daarna zijn paswoord. Hij drukt op de knop login, en het systeem gaat zijn ingevoerde gegevens vergelijken met de gegevens die in de database zijn opgeslagen. Het systeem heeft de klant gevonden in de database, en zoekt de functies die de klant mag gebruiken. Het systeem zet deze gegevens in een sessie, en stuurt deze gegevens terug naar de klant. De klant is nu aangemeld, en wordt door het systeem doorgestuurd naar zijn beginpagina. Op deze beginpagina kan de klant tussen zijn verschillende functies kiezen. Als de klant klaar is zal hij uitloggen, en zal de sessie verbroken worden door het systeem. De klant keert terug naar het inlogscherm.

Alternatieve scenario’s:

Server niet bereikbaar:

De klant opent zijn internet browser en surft naar de helpdesk. De server van de helpdesk is niet beschikbaar, waardoor de klant de helpdesk niet kan gebruiken. De klant krijgt een foutmelding op zijn scherm.

Verkeerde inloggegevens:

De klant opent zijn internet browser en surft naar de helpdesk. Hij voert zijn inloggegevens in, maar deze komen niet overeen met de gegevens uit de database. Het systeem stuurt een foutmelding terug die de klant op zijn scherm krijgt. De klant zal zijn inloggegevens opnieuw moeten invoeren.

Inloggegevens vergeten:

De klant opent zijn internet browser en surft naar de helpdesk. Bij het inlogscherm

aangekomen komt hij erachter dat hij zijn inloggegevens is vergeten. De klant drukt op de knop forgot password en wordt doorgestuurd naar een ander scherm, waar hij zijn email adres in moet voeren. Nadat hij zijn email adres heeft ingevoerd, worden zijn inloggegevens

De onderstaande scenario’s hebben betrekking op de functionaliteiten zoals die door de klant worden gebruikt.

1.2 Incidenten aanmelden:

Een klant kan een incident aanmaken als hij een fout heeft ontdekt in de software of als hij een vraag heeft over de software. Het aanmelden van een incident kan ook door

ontwikkeling worden gedaan, dit zal op dezelfde manier gebeueren.

Main Success Scenario:

De klant heeft een fout ontdekt in een programma dat door de ontwikkelaar is gemaakt. Hij geeft dit door aan ontwikkeling door hier een incident van aan te maken in de helpdesk. Om dit te doen logt de klant eerst in bij het systeem. Als de klant is ingelogd, ziet hij een

overzicht met de incidenten die hij al heeft aangemaakt. Omdat er een nieuw incident aangemaakt moet worden, drukt hij op de knop create incident. De klant zal worden

doorgestuurd naar een scherm waarin hij zijn gegevens kan invoeren. De klant doorloopt de pagina en voert alle verplichtte informatie in over een incident, en drukt daarna op de knop create incident. Het incident wordt door het systeem opgeslagen in de helpdesk. De klant keert terug naar zijn beginpagina en krijgt een boodschap op het scherm dat zijn incident succesvol is verwerkt. Op de beginpagina is nu het incident toegevoegd.

Alternatieve scenario’s:

Incorrecte invoer:

De klant is bij het invoeren van een incident verplichtte informatie vergeten in te voeren. De klant drukt op de knop save, maar het systeem zal het incident nu niet opslaan. De klant krijgt een foutmelding op het scherm en zal de gewenste informatie moeten invoeren om door te gaan. De klant voert de informatie alsnog in, en drukt weer op de knop. Het incident is nu wel volledig ingevuld en zal worden toegevoegd in de database. De gebruiker keert terug naar zijn beginpagina en zal een melding krijgen dat het incident succesvol is toegevoegd.

1.3 Incident / Issue bekijken:

Een klant kan een incident of issue bekijken. Tijdens het bekijken, kan de klant commentaar geven dat bij ontwikkeling terechtkomt. Ook kan de klant hier zien of ontwikkeling

commentaar bij een incident heeft toegevoegd. Een klant kan enkel een inicdent bekijken, hij kan deze niet aanpassen. De ontwikkelaar kan wel een incident bewerken. Hier zal dan ook een nieuw scenario voor worden gemaakt.

Main Success Scenario:

De klant krijgt een mail van ontwikkeling dat er een wijziging is aangebracht in een incident dat is aangemeld door de klant. De klant is ingelogd in de helpdesk en heeft op zijn

beginpagina het incident geselecteerd dat hij wilt gaan bekijken. Op de beginpagina staan alleen de incidenten die voor de klant relevant zijn. De klant drukt op het nummer van het incident en er wordt een nieuw scherm geopend, met daarin de details van het incident. De klant leest het commentaar dat door ontwikkeling is ingevoerd, en leest dat ontwikkeling nog enkele vragen heeft over het incident. De klant drukt op de knop add comment en een

nieuw scherm wordt geopend waarin hij zijn antwoord kan geven. De klant voert alle velden in en drukt op de knop save. Het commentaar wordt opgeslagen in de database. De klant keert terug naar het detail scherm van een incident en ziet dat het commentaar succesvol is toegevoegd.

Alternatieve scenario’s:

Incorrecte invoer:

De klant is bij het invoeren van commentaar verplichtte informatie vergeten in te voeren. De klant drukt op de knop save, maar het systeem zal het commentaar nu niet opslaan. De klant krijgt een foutmelding op het scherm en zal de gewenste informatie moeten invoeren om door te gaan. De klant voert de informatie alsnog in, en drukt weer op de knop. Het commentaar is nu wel volledig ingevuld en zal worden toegevoegd in de database. De gebruiker keert terug de detailpagina en zal een melding krijgen dat het commentaar succesvol is toegevoegd.

1.4 Release bekijken:

Main Success Scenario:

De klant heeft ingelogd en klikt op het tabblad releases. Er opent een nieuw scherm met daarop de releases die voor de klant beschikbaar zijn. De klant ziet de release niet meteen staan en voert een zoekterm in het zoekveld in. Het systeem zoekt de releases die aan de zoekterm voldoen. De klant vind de release en klikt het nummer aan. De release opent in een nieuw scherm. De klant ziet de gegevens van de release. Bij de release komt te staan dat deze bij de klant op de testomgeving staat. De klant besluit hier commentaar op te geven, en aan te geven dat de release wordt goedgekeurd. De klant voert het commentaar in, en klikt het vinkje aan, zodat de release geaccepteerd wordt. Hierna geeft de klant aan dat de release in de productie omgeving mag worden geïnstalleerd. De klant keert terug naar het scherm met details van de release en ziet dat de status van de release is aangepast. De klant keert terug naar het overzicht en logt uit.

Alternatieve scenario’s:

Incorrect zoeken:

De klant voert de zoekterm in en vind de gewenste release niet. Hij zal dan een nieuwe zoekterm in voeren om wel tot het gewenste resultaat te komen.

Release niet accepteerbaar:

De klant opent de release, terwijl deze al is afgesloten. De klant ziet op zijn scherm dat de release al is goedgekeurd of geweigerd. De klant kan ook geen commentaar meer geven. De klant gaat terug naar het overzicht van de releases.

Release niet accepteren:

De klant opent de release en besluit de release niet te accepteren omdat de oplossingen in de release niet naar wens zijn. De klant klikt het vinkje niet accepteren aan, en voegt commentaar toe. De klant keert terug naar de geselecteerde release en ziet op zijn beeldscherm dat de release niet geaccepteerd is. De klant keert terug naar het overzichtsscherm van zijn releases.

ontwikkelaar worden gebruikt.

1.6 Issue aanmaken:

Main Success Scenario:

De ontwikkelaar is ingelog en heeft het scherm incident management geopend. Het incident waar de ontwikkelaar een issue van wilt maken is geopend. De ontwikkelaar drukt op de knop create issue. Het scherm issue management wordt geopend. In het scherm zijn de gegevens van het incident overgenomen. De ontwikkelaar vult de overgenomen gegevens aan met extra informatie over het incident. Hij is nu klaar met het aanmaken van het issue. Hij sluit het scherm en keert terug naar het incident management scherm.

Alternatieve scenario’s:

Direct issue aanmaken:

De ontwikkelaar komt erachter dat er een fout zit in de software. Hij gaat hier zelf een issue van aanmaken. Hij opent de helpdesk, logt in en selecteert het scherm issue management. Het scherm zal geen ingevoerde gegevens bevatten. De ontwikkelaar zoekt het programma waar het issue betrekking op heeft. Hij voert geen klant in, want er heeft geen klant melding gemaakt van de fout. Hij voert ook de overige informatie in die relevant is voor het issue. Na deze handelingen sluit hij het scherm en is het issue ingevoerd. De ontwikkelaar sluit de helpdesk.

1.7 Incident beoordelen en omzetten naar issue:

Main Success Scenario:

De ontwikkelaar krijgt een mail dat een klant een incident heeft gemeld. Hij opent de helpdesk en logt in. Uit de lijst met beschikbare schermen die bij de helpdesk horen, kiest hij het follow up scherm. Hierin zoekt hij het incident op, en drukt op de knop open incident. Het scherm incidenten opent met daarin de details van het incident. De ontwikkelaar vult de informatie in die voor hem relevant zijn. De ontwikkelaar ziet dat hij voor de oplossing van het incident de software moet gaan aanpassen. Hij bedenkt een workaround zodat de klant wel verder kan met het programma, en sluit het incident af. Omdat het probleem nog niet juist is verholpen, maakt de ontwikkelaar een issue aan van het incident. Het issue is aangemaakt en de ontwikkelaar keert terug naar het managementscherm van het incident.

Alternatieve scenario’s:

Direct incident openen:

De ontwikkelaar weet het nummer van het incident. Hij logt in en kiest voor het scherm incidenten. Hier voert hij het nummer van het incident in, en drukt op zoeken. De gegevens van het incident komen op het scherm.

Incident zoeken:

De ontwikkelaar logt in en kiest voor het scherm incidenten. Hij voert een organisatie in en drukt op zoeken. In het scherm kan hij bladeren tussen de verschillende incidenten die bij deze organisatie horen. De details van de incidenten worden getoond op het scherm.

Incident niet naar issue:

De ontwikkelaar beoordeelt het incident en komt tot e conclusie dat er geen software aangepast hoeft te worden om tot een goede oplossing van het probleem te komen. Hij communiceert de oplossing naar de klant en sluit het incident af. De gebruiker keert terug naar het overzicht met incidenten.

Incident koppelen:

De ontwikkelaar beoordeelt het incident en komt tot de conclusie dat het incident al is gemeld door een andere klant, en dat er al een issue van is aangemaakt. De ontwikkelaar drukt op de knop koppel incident. Er opent een nieuw scherm waarin de ontwikkelaar het issue opzoekt. Het issue is gevonden en de ontwikkelaar drukt op de knop ‘koppel’. Het incident is nu gekoppeld aan een bestaand issue. De ontwikkelaar keert terug naar het incident, sluit dit af en koppelt de oplossing terug naar de klant.

1.8 Issue openen en verwerken:

Main Success Scenario:

De ontwikkelaar opent de helpdesk en logt in. Hij krijgt een lijst met beschikbare schermen en kiest het scherm issue follow up. In dit scherm ziet hij alle issues die relevant voor hem zijn. Hij kiest een issue en drukt op de knop open issue. Het issue wordt geopend in het scherm issue management. In het scherm past de ontwikkelaar de gegevens aan die

relevant zijn voor de oplossing van het issue. De ontwikkelaar drukt op de knop action. Een nieuw scherm opent zich. In dit scherm geeft hij aan welke nieuwe status het issue heeft. Hij drukt op commit en het scherm sluit zich. Hij gaat verder naar het tabblad bestanden, en voert in welke bestanden hij heeft aangepast of gaat aanpassen. De ontwikkelaar leest het commentaar dat de klant heeft ingevoerd bij het issue. Hij drukt op de knop wederom actions en een nieuw scherm opent zich. In dit scherm geeft hij antwoord op de vraag van de klant. Hij voert ook de oplossing van het issue in. De klant verzet de status naar solved om aan te geven dat het issue opgelost is. De ontwikkelaar sluit het issue en keert terug naar de lijst met issues.

Alternatieve scenario’s:

Gebruikt bestand toevoegen:

De ontwikkelaar kiest de bestanden die relevant zijn voor de oplossing van het issue. Bij de selectie bekijkt het systeem of er issues open staan die voor de oplossing dezelfde

bestanden gaan aanpassen. De gebruiker heeft een bestand geselecteerd dat ook in een ander issue wordt aangepast en krijg hierover een melding op zijn scherm. De ontwikkelaar neemt notie van de melding en gaat verder met de afhandeling van het issue.

Issue onduidelijk:

De ontwikkelaar opent het issue en leest de beschrijving hiervan. Het is voor hem nog onduidelijk wat er precies bedoelt wordt met de informatie zoals deze door de klant ingevoerd is. Hij klikt op de knop action, en het nieuwe venster opent. Hij voegt

commentaar toe naar de klant in de vorm van een ophelderende vraag. Hij klikt op add comment en het commentaar wordt toegevoegd bij het issue. De status van het issue wordt niet verzet, en de ontwikkelaar sluit het scherm. Hij keert terug naar het overzichtsscherm van het issue.

Incident toevoegen aan issue:

De ontwikkelaar opent het issue en leest de beschrijving. Hij bedenkt zich dat er al een incident is gemeld dat over dezelfde fout in de software gaat. Hij gaat naar het tabblad incidenten en drukt op de knop toevoegen. Er opent een scherm met de incidenten. De ontwikkelaar zoekt het incident en drukt op de knop voeg toe. Het geselecteerde incident is toegevoegd aan het issue, en de ontwikkelaar keert terug naar het issue management scherm. Hij handelt het issue verder af en keert terug naar het overzichtscherm.

1.9 Release invoeren:

Main Success Scenario:

De gebruiker is ingelogd in de helpdesk en start het scherm release management op. Hij kiest voor welk product hij de releases wilt zien. Na de keuze opent een scherm met daarin de releases voor dit product. De gebruiker maakt een nieuwe release aan door op de knop nieuw te drukken. Er opent een nieuw scherm waarin de gebruiker de verschillende issues ziet, die bij het geselecteerde product horen. De gebruiker selecteert enkele issues, en activeert het vinkje om aan te geven dat de release zichtbaar moet zijn voor de klanten. Door deze actie kan de release niet meer worden aangepast. Ook geeft hij een status aan de release. Het systeem controleert de gegevens. De gebruiker sluit het venster, en keert terug naar het release scherm. De nieuwe release is opgeslagen in de database en wordt getoond op het scherm. De klant kan de nieuwe release zien en beoordelen in de APEX applicatie.

Alternatieve scenario’s:

Onbruikbaar issue:

De gebruiker voert issues toe en het systeem controleert de invoer. Na controle blijkt dat er enkele issues een overlap vormen met issues uit andere releases. Er komt een foutmelding op het scherm van de gebruiker. Het issue kan niet worden toegevoegd, en wordt verwijderd uit de release. De gebruiker kan verder met de invoer van de release.

Niet zichtbaar:

De gebruiker zet bij het aanmaken van de release het vinkje zichtbaar voor klant niet aan. Door deze actie kan de release in een later stadium nog worden aangepast, en is de release niet zichtbaar in de APEX applicatie. De klant kan niet reageren op de release. De gebruiker voert de verdere gegevens van de release in, en sluit het scherm. Hij keert terug naar het overzicht met de releases.

1.10 Release bewerken:

Main Success Scenario:

De gebruiker is ingelogd bij de helpdesk en opent het scherm release management. Hij voert het product in en ziet een lijst met releases. De gebruiker selecteert uit de lijst de release die bewerkt gaat worden. De release opent in een nieuw scherm. De gebruiker gaat naar het tabblad issues en voegt enkele issues toe. Het systeem controleert de invoer op overlapping. Na de controle verzet de gebruiker de status van de release en zet het vinkje zichtbaar aan. De release kan niet meer worden aangepast, en zal zichtbaar zijn voor de klant.

Main Success Scenario:

De gebruiker is ingelogd bij de helpdesk en opent het scherm release management. Hij voert het product in en ziet een lijst met releases. De gebruiker selecteert uit de lijst de release die bewerkt gaat worden. Hij druk op de knop open release, en de release opent in een nieuw scherm. Na het openen ziet de gebruiker dat de klant de release heeft geaccepteerd en hier commentaar bij heeft gevoegd. De gebruiker leest het commentaar en drukt op de knop action om antwoord te geven. Na het geven van antwoord, verzet de gebruiker de status op geaccepteerd, en sluit de release. De gebruiker keert terug naar het overzicht met releases.

Alternatieve scenario’s:

Niet geaccepteerd:

De gebruiker opent de release en leest dat de gebruiker de klant de release niet heeft geaccepteerd. Hij leest het commentaar van de klant en reageert hierop. De gebruiker zet de status van de release op niet geaccepteerd, en sluit het scherm. De gebruiker keert terug naar het scherm met het overzicht van de releases.

2. Use Cases

De use cases geven de functionele eisen van het software systeem weer. Ze beschrijven hoe de gebruiker met het systeem om wilt gaan. De use case is een beschrijving van een reeks interacties tussen een of meer actoren en het systeem. Een actor is een entiteit die buiten het systeem staat, en direct communiceert met het systeem. Een actor kan een mens of een andere systeem zijn. In de onderstaande use cases komen alleen menselijke actoren voor. De use cases zijn afgeleid aan de hand van de scenario’s. De scenario’s zijn per onderwerp samengevoegd en vormen een use case over dat onderwerp.

2.1 Aanmelden bij het systeem:

Samenvatting De gebruiker dient eerst in te loggen alvorens met het systeem te kunnen werken.

Aannamen De gebruiker weet op welke omgeving hij moet inloggen. De gebruiker beschikt over inloggegevens.

Beschrijving 1. De gebruiker gaat naar de omgeving waarop gewerkt gaat worden.[1] 2. De gebruiker komt in het inlogscherm en voert zijn inlog gegevens

in.[2]

3. De gebruiker drukt op de knop om de inloggegevens te verzenden.<<uses>> gegevens controle

4. Het systeem bepaalt de functionaliteiten voor de gebruiker. 5. De gebruiker wordt doorgestuurd naar zijn beginpagina.

6. De gebruiker is succesvol aangemeld en kan gaan werken met het systeem.

7. De klant logt uit en gaat terug naar stap 2.

Uitzonderingen [1]als de omgeving niet beschikbaar is, krijgt gebruiker foutmelding [2]als gebruiker inloggegevens vergeten is, gebruiker vraagt

inloggegevens op. <<extend>>inloggegevens opvragen

[3]als systeem inloggen niet goedkeurt, gebruiker keert terug naar stap 2. Resultaat De gebruiker is ingelogd in het systeem, en kan gaan werken met de

functionaliteiten.

2.2 Inloggegevens opvragen:

Samenvatting De gebruiker is zijn inloggegevens vergeten en vraagt deze opnieuw aan Aannamen De gebruiker heeft bekende inloggegevens

Beschrijving 1. Gebruikt voert email adres in.

2. Systeem controleert email adres [1].

3. Systeem verstuurd inloggegevens naar email adres. 4. Gebruiker keert terug naar inlogscherm.

Resultaat Gebruiker krijgt zijn inloggegevens op email adres.

2.3 Gegevens controle:

Use Case Gegevens controle.

Actoren Systeem.

Samenvatting Systeem controleert ingevoerde gegevens. Aannamen

Beschrijving 1. Systeem krijgt ingevoerde gegevens. 2. Systeem valideert ingevoerde gegevens.

3. Systeem accepteert invoer, gebruiker kan verder[1].

Uitzonderingen [1]systeem accepteert invoer niet, gebruiker krijgt foutmelding. Resultaat Systeem heeft invoer gevalideerd.

2.4 Commentaar toevoegen:

Actoren Gebruiker: klant / ontwikkelaar Samenvatting Gebruiker voegt commentaar toe Aannamen Gebruiker is ingelogd.

Gebruiker mag functionaliteit gebruiken.

Beschrijving 1. Gebruiker drukt op knop om commentaar te geven. 2. Gebruiker voert commentaar in.

3. Systeem controleert ingevoerd commentaar. <<uses>> gegevens controle

4. Systeem verwerkt commentaar.

5. Gebruiker keert terug naar beginscherm. Uitzonderingen Geen

Resultaat Gebruiker heeft commentaar toegevoegd.

2.5 Incident / Issue bekijken:

Samenvatting Gebruiker bekijkt een incident of issue. Aannamen Gebruiker is ingelogd.

Gebruiker mag functionaliteit gebruiken. Gebruiker heeft incidenten / issues. Beschrijving 1. Gebruiker ontvangt mail.

2. Gebruiker opent scherm. 3. Gebruiker zoekt incident.

4. Gebruiker opent gevonden incident. [1] 5. Gebruiker leest commentaar.

6. Gebruiker voegt commentaar toe <<uses>> commentaar toevoegen. 7. Klant keert terug naar beginscherm.

Uitzonderingen [1]incident niet gevonden, gebruiker keert terug naar stap 3. Resultaat Gebruiker heeft incident bekeken en commentaar toegevoegd.

2.6 Issue aanmaken:

Actoren Gebruikers: ontwikkelaar

Samenvatting Gebruiker maakt nieuw issue aan. Aannamen Gebruiker is ingelogd.

Gebruiker mag functionaliteit gebruiken. Gebruiker heeft incidenten.

Beschrijving 1. Gebruiker opent incident. [1] 2. Gebruiker zet incident om in issue.

3. Gebruiker voert meer gegevens issue in <<uses>>gegevens controle. 4. Gebruiker verzet status.

5. Gebruiker voegt commentaar toe <<uses>>commentaar toevoegen. 6. Gebruiker keert terug naar overzicht.

Uitzonderingen [1]gebruiker maakt issue aan zonder incident. Gebruiker begint bij stap 3. Resultaat Gebruiker heeft nieuw issue aangemaakt.

2.7 Issue beheer:

Use Case Issue beheer

Actoren Gebruikers: ontwikkelaar / klant Samenvatting Gebruikers verwerken issues. Aannamen Gebruiker is ingelogd.

Gebruiker mag functionaliteit gebruiken. Gebruiker heeft issues.

Beschrijving 1. Klant opent issue.

2. Klant geeft commentaar <<uses>> commentaar toevoegen. 3. Ontwikkelaar opent issue.

4. Ontwikkelaar past gegevens issue aan <<uses>>gegevens controle. 5. Ontwikkelaar verzet status.

6. Systeem sluit issue af.[1] Uitzonderingen [1]alleen als status dit aangeeft. Resultaat Issue is afgesloten.

2.8 Release beheer:

Use Case Release beheer

Actoren Gebruikers: ontwikkelaar

Samenvatting Gebruiker maakt nieuwe release aan. Aannamen Gebruiker is ingelogd.

Gebruiker mag functionaliteit gebruiken. Beschrijving 1. Gebruiker opent release.

2. Gebruiker voert gegevens release in.

3. Systeem controleert gegevens <<uses>> gegevens controle. 4. Gebruiker verzet status.

5. Gebruiker voegt commentaar toe <<uses>> commentaar toevoegen. 6. Gebruiker laat release zichtbaar zijn voor klant[1].

7. Klant beoordeelt release <<extend>>release acceptatie[2] 8. Gebruiker verzet status.

9. Systeem sluit release af.

10. Gebruiker keert terug naar overzicht.

Uitzonderingen [1]gebruiker laat release niet zichtbaar zijn voor klant. Systeem laat release aanpasbaar. Gebruiker keert terug naar overzicht.

[2]release nog niet beoordeeld door klant. Gebruiker keert terug naar overzicht.

Resultaat Gebruiker heeft nieuwe release aangemaakt.

2.9 Release acceptatie:

Samenvatting Gebruiker accepteert release. Aannamen Gebruiker is ingelogd.

Gebruiker mag functionaliteit gebruiken. Release is zichtbaar.

Beschrijving 1. Gebruiker opent release. 2. Gebruiker beoordeelt release. 3. Gebruiker accepteert release.[1] 4. Gebruiker geeft vervolgomgeving aan.

5. Gebruiker geeft commentaar <<uses>> commentaar geven. 6. Systeem verzet status.

7. Gebruiker keert terug naar overzicht.

Uitzonderingen [1]gebruiker accepteert release niet. Gebruiker gaat verder naar stap 5. Resultaat De gebruiker heeft de release geaccepteerd.

Klant

Ontwikkelaar

Aanmelden bij

systeem

Inloggegevens

opvragen

«extends»

Gegevens controle

«uses»

«uses»

Aanmelden

3. Use case diagram:

Het use case diagram geeft in een schema weer hoe de relaties tussen de verschillende use cases en de actoren zijn. Een use case digram bevat alle use cases. De actoren staan altijd buiten het diagram.

De functionaliteiten van het systeem kunnen worden opgedeeld in 3 delen. Het eerste deel bestaat uit het aanmelden bij het systeem. Het tweede deel uit het aanmelden en

beoordelen van issues. Het laatste deel bestaat uit het aanmaken en beoordelen van releases.

Voor ieder van deze delen is een apart use case diagram gemaakt.

3.1 Use case diagram: aanmelden

Het eerste use case diagram bevat het inloggen bij het systeem door zowel klant als ontwikkelaar.

Issue beheer Klant Incident bekijken Issue aanmaken gegevens controle «extends» «uses»

Issue beheer «uses»

Commentaar toevoegen «uses» «uses» «uses» «uses»

3.2 use case diagram: issue beheer

Na het aanloggen bij het systeem kan gebruik worden gemaakt van de functionaliteiten die zijn toegewezen door het systeem. Alle functionaliteiten die te maken hebben met het beheren van issues, zijn ondergebracht in het onderstaande use case diagram.

Release beheer

Klant

Ontwikkelaar

Release acceptatie

Release beheer

Gegevens controle

Commentaar

toevoegen

«uses»

«uses»

«uses»

«uses»

«uses»

3.3 Use case diagram: release beheer

De gemaakte en afgewerkte issues kunnen worden opgenomen in een release. Dit wordt gedaan in releasebeheer. Enkel de ontwikkelaars bepalen welke issues worden opgenomen in een release. De release moet worden geaccepteerd door de klant. Het use case diagram ziet er als volgt uit:

3.4 Use case diagram: totale systeem

4. Klassendiagram:

In het klassendiagram wordt de statische structuur van het nieuwe systeem weergegeven. Het wordt weergegeven aan de hand van de verschillende klassen en de onderlinge relatie. Er komen 3 soorten klassen in voor:

Entity-klassen: de klassen die blijvende informatie bevatten. Dit zijn de klassen met informatie over bijvoorbeeld issues en incidenten.

Boundary-klassen: de klassen die de interactie tussen het systeem en de actoren weergegeven. Deze klassen zijn verantwoordelijk voor de communicatie tussen het systeem en de buitenwereld. Een voorbeeld van een boundary klasse zijn de

schermen van een applicatie of een overzichtsdocument van een issue.

Control-klassen: de klassen die de flow van de scenario’s beheren. Deze klassen zorgen ervoor dat het systeem de gebruiker een bepaald scenario laat doorlopen. Een voorbeeld hiervan is de loginControl, die ervoor zorgt dat de gebruiker ingelogd of geweigerd wordt, aan de hand van de ingevoerde gegevens.

+klikOpKnop() +voerGegevensIn() -naam -product -inlogNaam -inlogCode -functionaliteiten «entity» Klant +stuurFunctionaliteiten() +vraagGegevens() «boundary» loginGUI_Forms -productNummer -nummer -omschrijving -commentaarNummer -releaseNummer «entity» Issue -organisatieNummer -incidentNummer -omschrijving -commentaarNummer «entity» Incident +controleerGegegevens() +stuurGegevensTerug() +stuurFunctionaliteitenterug() -inlogNaam -inlogCode «control» loginControle +stuurFoutmelding() +controleerIngevoerdeGegevens() +slaContentOp() «control» gegevensControle +nieuwIssue() +koppelIncident() +voegCommentaarToe() +bewerkIssue() +voegReleaseToe() «boundary» issueGUI_Forms +nieuwIncident() +bewerkIncident() +nieuwIssue() +voegCommentaarToe() «boundary» incidentGUI_Forms +bekijkRelease() +accepteerRelease() «boundary» releaseGUI_Forms -commentaarNummer -commentaar «entity» Commentaar -organisatieNummer -releaseNummer -releaseOmschrijving -commentaarNummer «entity» Release -productNummer -productOmschrijving «entity» Product +klikOpKnop() +voerGegevensIn() +bewerkGegevens() -naam -product -inlogNaam -inlogCode -functionaliteiten «entity» Ontwikkelaar «entity» content «boundary» GUI_Forms «boundary» GUI_APEX +voegCommentaatToe() +bekijkIssue() «boundary» issueGUI_APEX +voegCommentaarToe() +bekijkIncident() «boundary» incidentGUI_APEX +nieuweRelease() +voegIssueToe() «boundary» releaseGUI_APEX +stuurFunctionaliteiten() +vraagGegevens() «boundary» loginGUI_APEX 0..* 0..* * 0..1 0..* 0..* 0..1 * 0..* 0..* 0..* 0..* 1 0..1 * * 0..* 0..*

5. Sequence diagram:

De sequence diagrammen geven de interactie tussen de verschillende objecten weer, om het systeemgedrag te verwezenlijken.

5.1 Sequence: inloggen

loginGui

Gebruiker loginControle Gebruiker

Inlog gegevens Inlog gegevens Controleer gegevens functionaliteiten functionaliteiten startpagina

GUI

Gebruiker gegevensControle content

gegevens invoeren

Controleer gegevens

gegevens opslaan

gegevens opgeslagen gegevens opgeslagen

5.2 Sequence: inlog opvraag

loginGUI

Klant loginControle Klant

Paswoord opvragen Klantgegevens Gegevens opvragen Inloggegevens Inloggegevens Inloggegevens Gegevens invoeren

5.4 Sequence: Issue toevoegen

IncidentGUI

Ontwikkelaar IssueGUI gegevensControle Issue Incident

Incident openen Incident gegevens Issue gegevens Gegevens opslaan Issue nummer Issue opgelsagen

6. Omgevingen

6.1 Architectuur:

Het systeem gaat gebruik maken van twee verschillende interfaces. De interface voor de klant zal worden gemaakt in APEX. De interface van de ontwikkeling zal worden

geproduceerd in Oracle Forms. Beide interfaces maken gebruik van dezelfde APEX database. De 2 verschillende systemen draaien op dezelfde server. Ook de database zit op deze

server. Het systeem is enkel toegankelijk voor medewerkers en klanten van AXI. Het systeem kan worden benadert door een web browser. Het maakt niet uit welke browser dit is.

De architectuur van het systeem zal er als volgt uit gaan zien:

De database AXI*HELP zal de gegevens van de applicatie gaan bevatten. Uit de databases ADONIS en AXI*MARKET worden enkel gegevens opgevraagd. Deze gegevens uit deze tabellen zullen niet worden gewijzigd.

6.2 Schermen:

6.2.1 Schermen forms applicatie

De forms applicatie maakt gebruik van verschillende schermen. Ieder scherm heeft zijn eigen unieke nummer. De schermen kunnen worden aangeroepen vanuit een tree, die wordt gegenereerd op basis van de rechten van de gebruiker.

De schermen zien er uniform uit. Het lettertype van ieder scherm is gelijk. De hoofdkleuren van de schermen zijn grijs, wit en geel. Er is voor deze kleuren gekozen, omdat dit een rustig uiterlijk tot gevolg heeft. In de schermen kan duidelijk worden gezien welke invoermogelijkheden een veld heeft. Als een veld wit is, kan het worden ingevoerd. Is het veld grijs, dan kan er geen data worden ingevoerd in het veld. Een Multi record veld heeft meerdere regels. Door middel van een gele kleur, wordt duidelijk gemaakt op welke regel de gebruiker zich bevindt. Dit geld ook voor de single velden. Deze worden aangegeven met een licht gele kleur. Ook de knoppen in de applicatie zijn uniform. De functionaliteit van de knop bepaalt zijn uiterlijk. Een knop om een scherm te sluiten zal bijvoorbeeld een rood kruis bevatten.

Alvorens de forms applicatie gebruikt kan gaan worden, moet er eerst worden ingelogd. Het inloggen gebeurt aan de hand van een gebruikersnaam en passwoord.

Inlogscherm:

Er worden functionaliteiten bepaald die de gebruiker mag gebruiken. Niet iedere gebruiker heeft dezelfde rechten. De gebruiker wordt na het inloggen doorgestuurd naar een scherm met een tree. Van hieruit kan worden gekozen met welk scherm gewerkt gaat worden. Ieder scherm heeft een eigen nummer, dat ook ingevoerd kan worden.

De schermen die voor het aanmaken en beheren van issue worden gebruikt, zijn gegroepeerd onder issue management.

De schermen 510 en 511 worden voornamelijk gebruikt voor het aanmaken en bewerken van issues. Scherm 511 is het ‘follow up’ scherm. Hierin worden een overzicht gegenereerd van de issues die relevant zijn voor een gebruiker. In scherm 519 worden de verschillende gebruikers beheert. In dit scherm wordt op basis van verschillende producten toegekend welke gebruikers welke issues kunnen zien. Ook kunnen in dit scherm de project managers worden aangegeven en de verschillende omgevingen waarin het product geïnstalleerd is.

Scherm 519

Scherm 511 is opgebouwd aan de hand van deze producten. In de tree links, staan de verschillende producten, waarvoor de gebruiker geselecteerd is. Naast de tree komt relevante informatie over de verschillende issues die voor het geselecteerde product zijn aangemaakt.

Een gedetailleerd overzicht van het geselecteerde issue zal onder aan het scherm worden weergegeven.

Het scherm bevat ook enkele knoppen. De knoppen hebben een standaard uiterlijk die door de gehele applicatie worden gebruikt.

Scherm 511

Het 2e _{hoofdscherm is het scherm om een issue aan te maken en te bewerken. In het}

scherm wordt linksboven begonnen, en zal er naar rechtsonder gewerkt worden. De belangrijkste gegevens staan altijd op het scherm weergegeven. De minder relevante informatie staan in tabbladen onder aan het scherm.

Met de knop ‘add action’ wordt een nieuw scherm geopend, waarin een actie kan worden gedaan op het huidige issue.

6.2.1 Schermen APEX applicatie:

De APEX applicatie is gemaakt voor de klanten. Via deze applicatie kan een klant een issue bekijken en volgen. Ook is het mogelijk voor de klant om een reactie op een issue te geven. Inlogscherm APEX:

Na het inloggen komt de klant op een zogenaamde landingspagina, van waaruit verder kan worden gegaan naar het issueoverzicht. De landingspagina is voor iedere gebruiker anders. Er is vooraf bepaalt welke functionaliteiten een klant kan gebruiken.

Met de tabbladen rechtsboven kan worden doorgesprongen naar de projects helpdesk. In de projects helpdesk kan de klant zijn incidenten en issues zien, door op de bijhorende knoppen te drukken:

Nadat op de knop issues is gedrukt, komt er een overzichtsscherm met daarin alle issues die voor de klant zichtbaar mogen zijn:

Op dit scherm komen alle relevante issues te staan voor de persoon die is ingelogd. Als op het issuenummer wordt gedrukt, dan zal worden doorgesprongen naar een detailscherm over het geselecteerde issue. De envelopjes voor het issue nummer, geven aan of het issue al bekeken is in detail vorm. Een dichte envelop wilt zeggen dat dit niet het geval is. Een envelop met een plusje geeft aan dat er nieuw commentaar is bij een issue.

In bovenstaand scherm is in detailvorm het geselecteerde issue weergegeven. Het commentaar dat is weergegeven is alleen zichtbaar als het bedoelt is voor de organisatie waar de ingelogde persoon voor werkt. Als op de knop Add comment wordt gedrukt, dan opent een volgend scherm zich.

Figuur 7.13 Comment

In bovenstaand scherm kan commentaar worden toegevoegd. Ook kan er een totaal van 3 bestanden worden toegevoegd. Het commentaar zal alleen zichtbaar zijn voor de organisatie die het commentaar toevoegt, en de medewerkers van ontwikkeling. Het toegevoegde commentaar wordt ook zichtbaar in de forms applicatie.

7. Testscenario’s

Testscenario Inloggen

Samenvatting Actor logt in om gebruik te maken van de functionaliteiten van het systeem

Gebaseerd op Login scherm

Start situatie De gebruiker heeft het systeem geopend in de webbrowser 1. Voer inloggegevens in en druk op

knop inloggen. De gebruiker wordt ingelogd en doorgestuurd naar system tree. 2. Einde test

Testscenario Van incident naar Issue

Samenvatting Actor selecteert een incident en maakt op basis van dit incident een Issue. Gebaseerd op Scherm 442

Start situatie Scherm 442 is geopend en er is een incident geselecteerd.

1. Druk op de knop ‘create issue’ Scherm 510 wordt geopend met daarin de gegevens van het eerder geselecteerde incident.

2. Voer overige gegevens Issue in. De overige gegevens zijn ingevoerd. 3. Druk op functie toets F10 Het issue wordt opgeslagen in de database

Audit gegevens en issuenummer worden aangemaakt.

4. Sluit scherm 510 Er wordt teruggekeerd naar scherm 442 5. Herhaal stappen 1 – 2 De gegevens zijn ingevoerd.

6. Sluit scherm 510 Er wordt gevraagd om gegevens op te slaan

7. Kies ‘NO’ Gegevens worden niet opgeslagen en er

wordt teruggekeerd naar scherm 442. 8. Einde test

Testscenario Issue aanmaken

Samenvatting Actor maakt een nieuw issue aan. Gebaseerd op Scherm 510

Start situatie Scherm 510 is geopend. 1. Voer gegevens die verplicht zijn in:

Product Version Language Component Short description

De verplichte gegevens worden ingevoerd.

2. Druk op functie toets F10 Het issue wordt opgeslagen in de database Audit gegevens en issuenummer worden

aangemaakt.

3. Sluit scherm 510 Er wordt teruggekeerd naar begin scherm 4. Einde test

Testscenario Issue openen

Samenvatting Actor zoekt een issue op en opent deze. Gebaseerd op Scherm 511

Start situatie De gebruiker is ingelogd

1. Gebruiker opent scherm 511 Scherm 511 wordt geopend met daarop alle beschikbare issues

2. Selecteer een issue Een issue is geselecteerd en de tabbladen worden gevuld met informatie over dit issue. 3. Druk op knop ‘open issue’ Scherm 510 wordt geopend, met het

geselecteerde issue.

4. Herhaal stap 1 Scherm 511 wordt geopend

5. Druk op knop ‘Search’ Zoekscherm wordt geopend 6. Voer een zoekterm in en druk op

knop OK Issues worden gezocht en worden weergegeven in de lijst. 7. Herhaal stap 2 – 3 Scherm 510 wordt geopend, met het

geselecteerde issue. 8. Einde test

Testscenario Add bookmark

Samenvatting Actor geeft een issue een bookmark, zodat deze makkelijk kan worden teruggevonden.

Gebaseerd op Scherm 511

Start situatie De gebruiker is ingelogd

1. Gebruiker opent scherm 511 Scherm 511 wordt geopend met daarop alle beschikbare issues

2. Selecteer een issue Een issue is geselecteerd en de tabbladen worden gevuld met informatie over dit issue. 3. Druk op knop ‘add bookmark’ Issue wordt toegevoegd aan bookmarks. 4. Druk op tree ‘bookmarked’ Bookmarked issues worden getoond. 5. Druk op knop ‘remove bookmark’ Issue wordt verwijderd uit bookmarks. 6. Einde test

Testscenario Add action - Comment

Samenvatting Actor geeft commentaar op een issue en kan de handler en status veranderen

Gebaseerd op Scherm 510

Comment Handler Status

3. Laat het vinkje ‘Visible for all’ staan

en druk op add action. Het comment wordt opgeslagen in de database, bij het geselecteerde issue, en is voor alle gerelateerde organisaties zichtbaar. 4. Herhaal stap 2 -3 De gegevens zijn ingevoerd.

5. Zet het vinkje ‘visible for all’ uit. Het invoervlak organisation wordt toegankelijk

6. Selecteer organisaties Het commentaar wordt voor de geselecteerde organisaties zichtbaar. 7. Druk op knop ‘add action’ Het comment wordt opgeslagen in de

database, bij het geselecteerde issue, en is alleen zichtbaar voor de geselecteerde organisaties.

8. Herhaal stap 1 Er wordt een scherm geopend waar een actie kan worden toegevoegd.

9. Druk op knop ‘Close’ Het commentaar wordt niet opgeslagen en de gebruiker keert terug naar scherm 510. 10. Einde test.

Testscenario Add action - Attachments

Samenvatting Actor kan een attachment toevoegen aan een issue Gebaseerd op Scherm 510

Start situatie Scherm 510 is geopend en er is een issue geselecteerd

1. Druk op knop ‘add action’ Er wordt een scherm geopend waar een actie kan worden toegevoegd.

2. Open tabblad attachments Tabblad attachments wordt geopend 3. Druk op knop ‘Upload’ Scherm 999 wordt geopend.

4. Selecteer een bestand om toe te

voegen Bestand wordt toegevoegd.

5. Voer een omschrijving in, en vernader het vinkje visible.

De omschrijving is ingevoerd, en het attachment is wel of niet zichtbaar voor de klant.

6. Druk op F10 en sluit scherm De gegevens worden opgeslagen bij het attachment en er wordt terug gekeerd naar scherm 510.

7. Herhaal stap 1 – 2 Tabblad attachments wordt geopend 8. Druk op knop ‘close’ Er wordt teruggekeerd naar scherm 510. 9. Einde test

Testscenario Attachments openen / Downloaden

Samenvatting Actor bekijkt of download een eerder opgeslagen attachment Gebaseerd op Scherm 510 - tabblad attachments

1. Selecteer een attachment. Het geselecteerde attachment wordt gemarkeerd.

2. Druk op knop show Het geselecteerde attachment wordt geopend.

3. Herhaal stap 1 Het geselecteerde attachment wordt gemarkeerd.

4. Druk op knop ‘download’ Er verschijnt een scherm waarin de locatie kan worden geselecteerd.

5. Selecteer een locatie waar opgeslagen

kan worden. Het attachment wordt opgeslagen.

6. Einde test.

Testscenario Incident toevoegen aan issue.

Samenvatting Actor voegt een incident toe aan een issue. Gebaseerd op Scherm 510 – Tabblad incidents

Start situatie Scherm 510 – tabblad incidents is geopend. 1. De gebruiker drukt op de knop ‘add

incidents’

Er wordt een scherm geopend met daarin alle relevante incidenten.

2. Vink de incidenten aan die

toegevoegd dienen te worden. De incidenten zijn geselecteerd.

3. Druk op de knop ‘Add incident’ De incidenten worden toegevoegd aan het issue.

4. Herhaal stap 1-2 De incidenten zijn geselecteerd.

5. Druk op de knop ‘Close’ Het scherm wordt gesloten, en de incidenten worden niet opgeslagen.

6. Einde test

Testscenario Incident openen vanuit tabblad incidents

Samenvatting Actor opent een gekoppeld incident. Gebaseerd op Scherm 510 – Tabblad incidents

Start situatie Scherm 510 – tabblad incidents is geopend. 1. Selecteer een incident dat geopend

moet worden. Incident is gemarkeerd

2. Druk op knop ‘open incident’ Scherm 442 wordt geopend met het geselecteerde incident.

3. Einde test

Testscenario Gewijzigde bestanden toevoegen aan issue

Samenvatting Actor voegt bestanden toe die gewijzigd gaan worden voor oplossing van het issue.

Gebaseerd op Scherm 510 – Tabblad Files

bestanden waaruit gekozen kan worden. 2. Selecteer de bestanden De bestanden zijn geselecteerd

3. Druk op knop ‘add files’ De bestanden worden toegevoegd aan het issue.

4. Herhaal stap 1-2 De bestanden zijn geselecteerd

5. Druk op knop close De bestanden worden niet toegevoegd aan het issue, en er wordt teruggekeerd naar scherm 510.