Zákaznická podpora UŽIVATELSKÁ PŘÍRUČKA

Zákaznická podpora

UŽIVATELSKÁ PŘÍRUČKA

Zákaznická podpora - Uživatelská příručka

Obsah: 1.

VERZE DOKUMENTU ...................................................................................................................... 1

2.

POUŢITÉ TERMÍNY ........................................................................................................................ 1

3.

MOTIVACE ..................................................................................................................................... 1

4.

PŘÍSTUP K TTP .............................................................................................................................. 2

4.1. 4.2. 4.3. 5.

BEZPEČNOST TTP ................................................................................................................... 3 PŘIHLAŠOVACÍ STRÁNKA DO TTP ......................................................................................... 3 UŢIVATELÉ TTP ...................................................................................................................... 4 KONFIGURACE ............................................................................................................................... 4

5.1. 5.2. 5.3. 6.

KONFIGURACE UŢIVATELE TTP S PŘÍSTUPEM ...................................................................... 4 DALŠÍ KONFIGURACE ............................................................................................................. 5 NOTIFIKAČNÍ PRAVIDLA ........................................................................................................ 5 ZPRACOVÁNÍ DEFEKTŮ ................................................................................................................. 6

6.1. 6.2. 6.3. 6.4. 7.

STATUS DEFEKTŮ .................................................................................................................. 8 PŘIŘAZENÍ DEFEKTU ........................................................................................................... 10 KOMENTÁŘ K DEFEKTU........................................................................................................ 10 ODHAD ŘEŠENÍ DEFEKTU .................................................................................................... 11 PŘIDÁNÍ POŢADAVKU ................................................................................................................. 12

7.1. 7.1.1. 7.1.2. 7.1.3. 7.1.4. 7.1.5. 7.1.6. 7.1.7. 7.1.8. 7.1.9. 7.1.10. 7.1.11. 7.1.12. 7.1.13. 7.2. 7.2.1. 7.2.2. 7.2.3. 7.2.4. 7.2.5. 7.2.6. 7.2.7. 7.2.8. 7.2.9. 7.2.10. 7.2.11. 7.3.

7.3.1. 7.3.2. 7.4. 7.5. 7.6.

ZÁHLAVÍ DEFEKTU ............................................................................................................... 12 Summary (povinné) 12 Status (Pouze ke čtení) 12 Disposition (Pouze ke čtení) 12 Type (Kombo, povinné) 12 Severity (Kombo, Povinné) 13 Priority (Kombo, Povinné) 14 Product (Kombo, Povinné) 14 Component (Kombo, Volitelné) 15 Reference (Volitelné) 15 Entered by (Pouze ke čtení) 15 Date Entered (Pouze ke čtení) 15 AS/400 reference (Pouze ke čtení) 15 Test/Live (Povinné) 15 TĚLO DEFEKTU ..................................................................................................................... 16 Reported (Pouze ke čtení) 16 Found by (Kombo, Povinné) 16 Date Found by (Pouze ke čtení) 16 Version Found by (Volitelné) 16 Description (Povinné) 17 Reproduced (Kombo, Volitelné) 17 Steps to reproduce (Volitelné) 17 Computer configuration (Kombo, Volitelné) 17 Other HW and SW (Volitelné) 17 Project (Volitelné) 17 Attachments 17 PRIORITIZACE DEFEKTŮ NALEZENÝCH V TESTOVACÍM PROSTŘEDÍ ZÁKAZNÍKA ............. 17 Pravidla prioritizace defektů 17 Priority defektu z testovaciho prostředí 18 CUSTOM FIELDS DEFEKTU................................................................................................... 18 WORKFLOW A HISTORIE DEFEKTU ..................................................................................... 18 WORKAROUND DEFEKTU ..................................................................................................... 18


8.

MODIFIKACE DEFEKTU ............................................................................................................... 18

8.1. 8.2. 8.3.

ZMĚNA STATUSU DEFEKTU A JINÉ AKCE ............................................................................ 19 ZMĚNA ZÁHLAVÍ ČI TĚLA DEFEKTU ..................................................................................... 19 NOVÝ VÝSKYT PROBLÉMU ................................................................................................... 20

9.

FILTRY ......................................................................................................................................... 20

10.

REPORTY ..................................................................................................................................... 21

11.

PROCES ZÁKAZNICKÉ PODPORY ................................................................................................. 21

11.1. 11.2. 11.3. 11.3.1. 12.

AKTÉŘI PROCESU ................................................................................................................. 21 PROCESNÍ MAPA .................................................................................................................. 23 HLAVNÍ PROCESNÍ SCÉNÁŘ ................................................................................................. 24 Alternativní scénáře 25

PŘÍLOHY ...................................................................................................................................... 27

Důvěrné Tento dokument je vlastnictvím BSC Praha, spol. s r. o. a nemůţe být bez předchozího souhlasu BSC rozmnoţován a kopírován. Tento dokument je poskytnut zákazníkovi za předpokladu, ţe jeho obsah bude přístupný jen odpovědným pracovníkům zákazníka a ţádné informace z tohoto dokumentu nebudou předány třetí straně. Dokument bude navrácen BSC pokud ho jiţ zákazník nebude potřebovat.


1. VERZE DOKUMENTU Verze

Autor

Datum

Status

Verze 01

Petr Zahálka

17.6.2002

Počáteční verze pro pilot v ZIBA

Verze 02

Petr Zahálka

7.7.2002

Změny při pilotním provozu

Verze 03

Petr Zahálka

9.9.2002

Srovnání s podporou EBS

Verze 04

Petr Zahálka

15.10. 2003

Nastavení sloupců

Verze 05

Filip Zeman

12.5.2004

Aktualizace, změna designu

Verze 06

Filip Zeman, J. Dostálová

23.6.2004

Nový vzhled, finalizace procesů

Verze 07

Petr Mozola

27.2.2007

Aktualizace

Verze 08

Petr Mozola

3.10.2011

Aktualizace

2. POUŽITÉ TERMÍNY             

TTP – TestTrack Pro SW pro administraci Poţadavků. Společnost – BSC Praha, spol. s.r.o. Zákazník – Zákazník, který má alespoň jednoho Uţivatele TTP s přístupem do TTP. Uživatel TTP – kaţdý Uţivatel TTP (i bez přístupu do TTP). Uživatel TTP s přístupem – vybraný Uţivatel s právem přístupu do TTP. Komponenta – aplikace, nástroj nebo objekt poskytovaný Společností (např. GEMINI / Security Server). Produkt – skupina Komponent tvořící ucelenou část obchodní funkčnosti (např. GEMINI / GSM). Systém – všechny licencované Produkty Zákazníka. Modul – konkrétní funkce Produktu. Koncový uživatel – koncový uţivatel Systému, Produktu nebo Komponenty. Požadavek – poţadavek Zákazníka na základě smlouvy o Zákaznické podpoře. Defekt – Poţadavek Uţivatele TTP zaregistrovaný v TTP. Problém – nesprávná funkce Systému, Produktu nebo Komponenty.

3. Motivace Cílem tohoto dokumentu je seznámit uţivatele Zákaznické podpory s pravidly, která platí pro poskytování této sluţby. Zákaznická podpora je realizována prostřednictvím TTP. Cílem Uţivatelské příručky není všestranný popis ovládání TTP, ale shrnutí těch oblastí, které jsou specifické právě pro vyuţívání Zákaznické podpory. Podrobného průvodce ovládacími prvky TTP najdete v částí Nápověda TTP (viz. Obrazovka 1). Poznámka: Nápověda TTP popisuje ovládací prvky nezávisle na jejich dostupnosti pro Uţivatele TTP. Dostupnost ovládacích prvků závisí na vašem bezpečnostním nastavení – v případě otázek kontaktujte Zákaznickou podporu Společnosti. Část Nápověda TTP (viz. Obrazovka 1) je k dispozici buď z přihlašovací stránky (viz. Obrazovka 4) nebo z hlavičky aplikace TTP, kliknutím na ikonu ‘? Help’ .

1


Obrazovka 1

4. Přístup k TTP Na stránky Zákaznické podpory se přímo ideas.com/cz/sluzby-a-reseni/customer-services/ .

dostanete

zadáním

adresy

http://www.bsc-

Podobu stránky Zákaznické podpory ukazuje Obrazovka 2, na kterou se můţete dostat i přes webové stránky Společnosti (http://www.bsc-ideas.com/com). Jakmile kliknete na tlačítko „Vstoupit“ v poli klientská zóna

Obrazovka 2

2


Tip: Chcete-li se připojit přímo k TTP Bankovní divize pro registrované Zákazníky nebo chcete-li si uloţit přímý link mezi oblíbené sloţky, pouţijte tuto cestu: https://support.bsc.cz/cgi-bin/ttcgi.exe?command=LoginScreen&databaseid=8

4.1. Bezpečnost TTP Připojení k TTP je zajištěno protokolem SSL. Proto se při přístupu na adresy uvedené výše objeví podobná bezpečnostní výstraha jakou ukazuje Obrazovka 3.

Obrazovka 3 Důvodem je absence autority support.bsc.cz (CA, která vydala TTP SSL certifikát) ve sloţce důvěryhodných certifikačních autorit vašeho prohlíţeče. V případě, ţe chcete toto upozornění při příštím přihlášení potlačit, přidejte support.bsc.cz CA mezi důvěryhodné autority:   

klikněte na tlačítko View Certificate (Zobrazit certifikát), zkontrolujte údaje na certifikátu, instalujte certifikát kliknutím na tlačítko Install Certificate (Instalovat certifikát) – dále následujte průvodce.

Chcete-li pokračovat na přihlašovací stránku, klikněte na Yes (Ano). Pozor: Práce s TTP je zabezpečena časovým limitem. Spojení se ukončí po 15 minutách nečinnosti uţivatele.

4.2. Přihlašovací stránka do TTP Do TTP pro registrované Zákazníky se mohou přihlásit pouze Uţivatelé TTP s přístupem. Jakmile je Uţivatel TTP zaregistrován správcem TTP, je mu zasláno uţivatelské jméno a defaultní heslo. Heslo je moţné změnit po prvním přihlášení. Viz. přihlašovací stránka TTP, Obrazovka 4. Poznámka: rozdíl mezi Uţivatelem TTP s přístupem a Uţivatelem TTP najdete v kapitole 4.3. Tip: pouţijte Start at: kombo, chcete-li po úspěšném přihlášení rychle otevřít poţadovaný náhled.

3


Obrazovka 4

4.3. Uživatelé TTP Existují dva typy Uţivatelů TTP: 1. Uživatel TTP s přístupem – uţivatel má své uţivatelské jméno a heslo pro přihlášení do TTP. Kaţdý Zákazník si musí zaloţit nejméně jednoho Uţivatele TTP s přístupem, aby jeho zaměstnanci mohli pouţívat TTP. 2. Uživatel TTP bez přístupu – tento Uţivatel nemá přímý přístup do TTP. Chce-li TTP vyuţívat, musí se do TTP přihlásit za pouţití uţivatelského jména a hesla Uţivatele TTP s přístupem. Po přihlášení je však moţné při práci s Defekty pouţívat uţivatelské jméno jakéhokoliv Uţivatele TTP. Kaţdý zaměstnanec Zákazníka pracující s TTP by měl pouţívat svého vlastního Uţivatele TTP. Poznámka: Při práci s TTP je daleko efektivnější uvádět jméno aktuálního Uţivatele TTP, jelikoţ jedině tak lze jednoznačně určit, kdo s Defektem pracoval. Doporučení: Jestliţe má Zákazník pouze jednoho Uţivatele TTP s přístupem, je lepší jej pouţívat pouze pro účely přihlašování do TTP. Pozor: V jednom okamţiku můţe být přihlášený pouze jeden Uţivatel TTP s přístupem. Další pokus o přihlášení stejného Uţivatele TTP s přístupem odhlásí dříve přihlášeného uţivatele! Kontaktujte oddělení Zákaznické podpory Společnosti kdykoliv potřebujete přidat nebo změnit své Uţivatele TTP nebo v případě jakéhokoliv problému s přístupem do TTP.

5. Konfigurace V TTP existuje několik konfiguračních sekcí. Některé z nich jsou přístupné pro Uţivatele TTP s přístupem, jiné jsou dostupné pouze pro správce TTP.

5.1. Konfigurace Uživatele TTP s přístupem Otevřete nabídku User options (Možnosti Uživatele) (viz. Obrazovka 5), chcete-li nastavit:      

heslo, počet záznamů na stránce, zobrazení jmen, zobrazení statusů, moţnosti více Defektů, časovou zónu.

4


Obrazovka 5 Poznámka: změna konfigurace ovlivní pouze Uţivatele TTP s přístupem!

5.2. Další konfigurace Další konfigurace jsou Uţivatelům TTP skryté. Kontaktujte oddělení Zákaznické podpory v případě poţadavku na změnu: 1. Křestního jména a příjmení Uţivatele TTP (povinné), 2. Telefonního či faxového čísla Uţivatele TTP (volitelné), 3. E-mailu Uţivatele TTP (volitelné), Poznámka: E-mail je povinný v případě vyuţívání notifikačních pravidel, 4. Adresy Uţivatele TTP (volitelné), 5. Informace o prostředí Uţivatele TTP jako je PC, periferní zařízení (volitelné), 6. Nastavení zobrazení Uţivatele TTP s přístupem: Sloupce viditelné na stránkách Defect list, Filters a Reports, Základní filtr na stránce Defect list. 7. Notifikačních pravidel (volitelné) – viz. podrobněji v 5.3.

5.3. Notifikační pravidla Notifikační pravidla slouţí pro informování o obdrţení Poţadavku a jeho následném řešení. TTP umoţňuje zasílat informace o 3 typech změn:

5


  

přidání Poţadavku, přiřazení Poţadavku, změně Poţadavku.

Tabulka 1 zobrazuje defaultní nastavení notifikačních pravidel Uţivatelům TTP. Uživatel TTP s přístupem

Uživatel TTP

Přiřazení

X

X

Neposílejte mi e-mail, jestliže jsem přiřazení provedl já

X

X

Přidání nového Defektu

-

-

N/A

-

Změna Defektu

X

-

Neposílejte mi e-mail, jestliže jsem Defekt změnil já

X

-

Jakákoliv modifikace

-

-

Změna statusu

X

-

Uzavření

-

-

Přidání, editace nebo vymazání

-

-

Verze

Neposílejte mi e-mail, jestliže jsem nový Defekt přidal já

Tabulka 1 Nastavení je moţné upravit dle specifických potřeb Zákazníka. Je moţné vytvořit pravidlo, které vygeneruje notifikaci po takřka jakémkoliv zásahu do TTP. Notifikační pravidla se vytvářejí jako filtr TTP (vizi. kapitola 9), byť tento filtr slouţí pouze pro účely notifikace. Příklad: 1) Uţivatel TTP chce dostávat notifikaci o všech změnách týkajících se Defektů určitého Produktu. 2) Uţivatel TTP (obvykle manaţer) chce dostávat vyrozumění o Defektech, které byly uvolněny k Zákazníkovi za účelem testování nebo uzavřeny (viz. kapitola 6.1, kde najdete podrobnosti o jednotlivých statusech).

6. Zpracování Defektů Kaţdý Defekt TTP má svou historii, kterou najdete v Defect workflow (Zpracování Defektů) (viz. Obrazovka 6) a Defect history (Historie Defektů) (viz. Obrazovka 7).

6


Obrazovka 6

Obrazovka 7

7


6.1. Status Defektů V rámci svého ţivotního cyklu prochází Defekt různými stavy. Status představuje skutečný stav Defektu a definuje, jaký typ akce můţe následovat. Samozřejmě ne všechny Defekty procházejí všemi definovanými statusy, záleţí na účelu Poţadavku a dalších okolnostech. Celkový seznam statusů i s jejich popisem viz. Tabulka 1. Vztahy mezi statusy při zpracování Defektů viz. Graf 1. Status

Popis

Open

Poţadavek byl přidán do databáze. Nebyl uzavřen ani vyřešen.

Open (Re-opened)

Poţadavek byl znovu otevřen a musí projít ţivotním cyklem.

Open (Verify Failed)

Poţadavek nebyl splněn. Ověření nebylo úspěšné.

Fixed

Poţadavek byl vyřešen a čeká na ověření.

Need Another fix

Poţadavek byl vyřesen častečně a potřebuje ještě další fix

Release to Deployment

Poţadavek byl vyřešen a čeká na nasazení do testovacího prostředí

Release to Testing

Poţadavek byl vyřešen a je připraven k testování.

Need Customer Verify

Poţadavek byl ověřen Společností, ale fungování musí ještě ověřit Zákazník.

Release to Customer Testing

Poţadavek je připraven na testování Zákazníkem.

Waiting for migration

Poţadavek je připraven na migraci do produkčního prostředí.

Closed (Verified)

Poţadavek byl vyřešen a jeho fungování bylo ověřeno Společností. Poţadavek byl uzavřen.

Closed (Customer Verified)

Poţadavek byl vyřešen a jeho fungování bylo ověřeno Zákazníkem. Poţadavek byl uzavřen.

Closed (Fixed)

Poţadavek byl úspěšně vyřešen a uzavřen bez potřeby testování.

Closed

Poţadavek byl uzavřen, ţádná oprava není nutná. Tabulka 1

8


Graf 1

9


6.2. Přiřazení Defektu Statusy představují skutečný stav Defektu, nezobrazují však osobu, která je v daném okamţiku za Defekt zodpovědná. K tomuto účelu se vyuţívají přiřazení. Kdykoliv je nutné změnit odpovědnost za Defekt, provede se to prostřednictvím přiřazení jinému Uţivateli TTP. Na rozdíl od statusů je přiřazení nezávislé na aktuálním statusu Defektu. Poznámka: TTP zajišťuje automatické přiřazení autorovi změny statusu. V případě potřeby proto nezapomeňte provést po změně stavu manuální přiřazení. Tip: Kaţdé přiřazení obsahuje textové pole pro účely popisu. Pouţijte toto pole k informování Uţivatele TTP o podrobnostech přiřazení. Příklad přiřazení viz. Obrazovka 8Error! Reference source not found.. Principy přiřazení při zpracování Defektu viz. Graf 1.

Obrazovka 8

6.3. Komentář k Defektu Tam, kde je to vhodné, lze vyuţít komentář k Defektu. Tento krok je nezávislý na změně statusu a přiřazení, takţe je uţitečný v případě nutnosti informovat Uţivatele TTP o novinkách nebo o pokroku při řešení Defektu. Příklad komentáře k Defektu ukazuje Obrazovka 9. Pozor: Informování budou pouze Uţivatelé s odpovídajícími notifikačními pravidly!

10


Obrazovka 9

6.4. Odhad řešení Defektu Někdy je dobré vědět, jak dlouho bude řešení Poţadavku trvat nebo kdy přesně bude nalezeno konečné řešení. K tomuto účelu slouţí akce Estimate. V rámci akce je moţné vloţit odhadovanou dobu řešení nebo verzi opravované Komponenty. Odhad řešení Defektu je volitelnou akcí, viz. Obrazovka 10. Pozor: Realizace odhadu řešení je k dispozici pouze pracovníkům Společnosti, pracovníci Zákazníka mají právo zobrazení!

Obrazovka 10

11


7. Přidání Požadavku Kaţdý Uţivatel TTP můţe přidat nový Poţadavek kliknutím na ikonu Add (Přidat) na Defects list (Seznamu Defektů). Následuje popis všech sekcí, které je nutné projít při zakládání Poţadavku do systému TTP. Po skončení nezapomeňte potvrdit zadání kliknutím na ikonu Save (Uložit). Poznámka: Není nutné za kaţdých okolností vyplňovat všechna níţe popsaná nepovinná pole, je nicméně nezbytné je alespoň projít, jelikoţ jsou často zdrojem důleţitých informací. Poznámka: Pole, které je nezbytné před uloţením do databáze vyplnit, jsou označena jako povinná.

7.1. Záhlaví Defektu

Obrazovka 11

7.1.1.

Summary (povinné)

Krátká textová identifikace Poţadavku. Zkuste být maximálně struční při zachování dostatečné výstiţnosti. Poznámka: Pole se často vyuţívá při full-text vyhledávání.

7.1.2.

Status (Pouze ke čtení)

Současný status Defektu. TTP jej automaticky změní po odpovídající akci. Seznam statusů viz. Tabulka 1.

7.1.3.

Disposition (Pouze ke čtení)

Pro účely Společnosti. Při zanesení Poţadavku se automaticky nastaví na ‘Open – Not Reviewed’. Seznam hodnot:     

Open – Not Reviewed, Open – Reviewed, Need Customer Input, Fix in Future Release, Hold.

7.1.4.

Type (Kombo, povinné)

Typ Poţadavku je důleţitou hodnotou pro výpočet priority Defektu. 1. Product Crash – Produkt není funkční jako celek nebo povaha chyby neumoţňuje vyuţívat ani část Produktu nebo jde o zásadní bezpečnostní Problém s dopadem na celý Produkt. Správného fungování nemůţe být dosaţeno ani zásahem operátora.

12


Typický příklad: Není moţné spustit klíčovou Komponentu Produktu nebo se přihlásit k Front-end aplikaci, zásadní bezpečnostní Problém na webovém serveru. 2. Module Crash – kompaktní část Produktu nefunguje bez moţnosti zlepšení zásahem operátora nebo jde o zásadní bezpečnostní Problém Modulu. Typický příklad: nedostupná funkce ‚Domácí platební příkaz‘ nebo ‚Zůstatek na účtech‘, nestabilita Modulu, bezpečnostní Problém omezený na ‚Domácí platební příkaz‘. 3. Incorrect Functionality – Modul nebo jeho část neodpovídá funkční specifikaci, funkčnost Modulu je významně sníţena, případně jeho provoz vyvolává velké Problémy. Jsou nezbytné nestandardní zásahy operátora či Koncového uţivatele. Typický příklad: nefunguje ověření čísla účtu na Modulo11, Problémy s pouţíváním filtru na pohyby na účtu, nutnost provádět nepředvídatelné manuální zásahy ze strany operátora při zpracování konce dne, provoz Modulu nebo Komponenty je citelně pomalejší. 4. Cosmetic – Produkt nebo jeho Modul je zbytečně komplikovaný nebo se objevil design Problém ve Front-end Komponentě. Typický příklad: nezbytnost manuálně vyplňovat poloţky, nevhodné rozloţení dat, chybné řazení či filtrování dat. 5. Feature request – Problém neovlivňuje funkci Systému, Zákazník poţaduje změnu funkčnosti. Typický příklad: je poţadována změna limitu na Dobíjecí poţadavek. 6. Otázka – otázka, návrh, nabídka, připomínka. Tabulka 2 ukazuje seznam typů a jejich vah pro výpočet priority. Váha

Type Product Crash

11

Module Crash

9

Incorrect Functionality

6

Cosmetic

1

Feature Request

0

Question

0 Tabulka 2

7.1.5.

Severity (Kombo, Povinné)

Závaţnost Poţadavku. Dopad Problému na Uţivatele aplikace. Jde o důleţitou hodnotu pro výpočet priority Defektu: 1. All System Users – Problém ovlivňuje všechny Koncové uţivatele Systému. 2. All Product Users – Problém ovlivňuje všechny Koncové uţivatele Produktu. 3. Most of Product Users – Problém má vliv na více neţ 30 % Koncových uţivatelů Produktu. 4. Minority of Product Users – Problém má vliv na méně neţ 30 % Koncových uţivatelů Produktu. 5. No User problem – Problém neovlivňuje Koncové uţivatele. 6. Risk – kvalifikováno riziko vzniku Problému v Systému, Produktu nebo Komponentě. Tabulka 3 obsahuje ţebříček závaţnosti a její váhu pro výpočet priority. Váha

Severity All System Users

21

13


All Product Users

19

Most of Product Users

16

Minority of Product Users

6

No User problem

2

Risk

0 Tabulka 3

7.1.6.

Priority (Kombo, Povinné)

Priorita je číslo na stupnici od 0 do 32. Jde o důleţitou hodnotu, která je klíčovým parametrem při pro stanovení pořadí řešení a další třídění či filtrování Defektů. Hodnota priority se vypočítá jednoduše jako součet váhy typu a závaţnosti 1. Vţdy je nezbytně nutné zachovat vztah mezi prioritou, typem a závaţností. Tabulka 4 ukazuje všechny varianty priorit, které je moţné pouţít místo manuálního výpočtu. Type

Severity All System Users

All Product Users

Most of Product Users

Minority of Product Users

No User problem

Risk

Product Crash

32

30

27

17

13

11

Module Crash

30

28

25

15

11

9

Incorrect Functionality

27

25

22

12

8

6

Cosmetic

22

20

17

7

3

1

Feature Request

21

19

16

6

2

0

Question

21

19

16

6

2

0

Tabulka 4

7.1.7.

Product (Kombo, Povinné)

Klasifikace Produktu. Notifikační pravidla obvykle pracují i s Produktem, takţe je uţitečné zvolit odpovídající typ Produktu. Jelikoţ je tato oblast je často rozšiřována, je uvedeno jen několik příkladů:     

GEMINI/HB server, GEMINI/PB, GEMINI/GSM, GEMINI/IBS 3.1, GEMINI/400,

1

Společnost brzy dokončí implementaci automatického dopočtu pole priority. Váš projektový vedoucí Vás bude o realizaci této změny informovat.

14


  

GEMINI/SA, GEMINI/UDEBS PL/SQL objekty, AS/400 CMS rozhraní.

7.1.8.

Component (Kombo, Volitelné)

Klasifikace Komponenty. Uvádějte pouze v případě, kdy jste si bezpečně jisti, které Komponenty se problém týká; v opačném případě ponechte defaultní hodnotu.

7.1.9.

Reference (Volitelné)

Obvykle se nepouţívá. Připraveno pro speciální účely jako odkazy na Systém incidentů Zákazníka.

7.1.10.

Entered by (Pouze ke čtení)

Jméno přihlášeného Uţivatele TTP s přístupem. Není moţné modifikovat.

7.1.11.

Date Entered (Pouze ke čtení)

Systémové datum. Není moţné modifikovat.

7.1.12.

AS/400 reference (Pouze ke čtení)

Pro speciální účely Společnosti.

7.1.13.

Test/Live (Povinné)

Nastavte prostředí, kde se Problém vyskytuje:   

Test – Testovací prostředí, Pre-Live – Předmigrační nebo pilotní prostředí, Live – Produkční prostředí.

15


7.2. Tělo Defektu

Obrazovka 12

7.2.1.

Reported (Pouze ke čtení)

Výskyt Problému se můţe vícekrát opakovat. Abychom se vyhnuli duplicitám, je nezbytné přidávat nové výskyty jiţ jednou objevených Problému k existujícím Defektům. Více informací najdete v kapitole 8.3. V případě prvního zadání obsahuje poloţka pouze jeden záznam se jménem Uţivatele TTP s přístupem.

7.2.2.

Found by (Kombo, Povinné)

Zde je moţné změnit jméno Uţivatele TTP z přihlášeného uţivatele na toho, který Problém skutečně identifikoval. Defaultní hodnotou je jméno přihlášeného Uţivatele TTP s přístupem. Tip: V případě, ţe pouţíváte pouze jednoho TTP Uţivatele s přístupem, změňte jméno na jméno aktuálního Uţivatele TTP.

7.2.3.

Date Found by (Pouze ke čtení)

Datum výskytu. V případě opakovaného výskytu se můţe lišit od data zadání!

7.2.4.

Version Found by (Volitelné)

Verze Komponenty, kde byl Problém identifikován, pokud je známá.

16


7.2.5.

Description (Povinné)

Podrobný popis Poţadavku. Zkuste být maximálně podrobní. Detaily viz. Příloha A .

7.2.6.

Reproduced (Kombo, Volitelné)

Frekvence výskytu:     

Always, Sometimes, Rarely, Could Not, I Didn't Try.

7.2.7.

Steps to reproduce (Volitelné)

Popis kroků vedoucích k reprodukci Problému. Mohou být velmi uţitečné při lokalizaci Problému.

7.2.8.

Computer configuration (Kombo, Volitelné)

Zvolte správnou konfiguraci hardwaru, jestliţe je k dispozici.

7.2.9.

Other HW and SW (Volitelné)

Vyplňte další informace týkající se konfigurace HW nebo SW, které by mohly být pro identifikaci Problému uţitečné.

7.2.10.

Project (Volitelné)

Vţdy zvolte pokud se Defekt váţe na konkrétní projekt

7.2.11.

Attachments

Místo pro artefakty jako jsou logy, screenshoty, konfigurační soubory. Klikněte na ikony Browse (Procházet) a Upload (Stáhnout) a přiloţte tak zvolený artefakt k Defektu. Příloha A se podrobně zabývá všemi vyţadovanými přílohami v jednotlivých případech. Poznámka: Čas ukládání přímo závisí na velikosti souboru a vašem připojení. Pokuste se omezit velikost souboru archivací, komprimací či vyseknutím bloku (GRAPováním).

7.3. Prioritizace defektů nalezených v testovacím prostředí zákazníka 7.3.1.

Pravidla prioritizace defektů



Kaţdý nově zaloţený defekt v testovacím prostředí zákazníka musí být označen v poli CB priority v záloţce Custom Fields prioritou dle bodu 7.3.2 a označením projektu (bod 7.2.10.) – zodpovědnost Project Manager příslušného projektu, popřípadě jím stanovená osoba



Práce spojené s řešením, testováním a plánovaním všech defektů v projektu se vţdy řídí uvedenými prioritami



Odpovědnost za vyplněnou prioritu je vţdy na autorovi defektu



Úpravu priority můţe provést autor defektu pouze po konzultaci s odpovědnou osobou dodavatele. Autor defektu musí byt schopen obhájit jim stanovenou prioritu a projevit součinnost při jejím rozporování.

17


7.3.2.

Priority defektu z testovaciho prostředí

brání zákazníkovi v testováni aplikace, je nezbytné vytvoření fix packu, popřípadě nového releasu

5

nekorektní chováni aplikace – s aplikaci lze pracovat, ale chování aplikace neodpovídá specifikacím. Existuje workaround, nicméně je nezbytné defekt s touto prioritou distribuovat v první další plánované release

4

problém nebránící testu v testovacím prostředí zákazníka, s aplikaci lze pracovat a dokončit základní pozitivní scénáře, lze distribuovat a naplánovat do dalších zákaznických releases

3

kosmetický problém, lze naplánovat do dalších zákaznických release

2

otázka na developera, technical leada, analytika, připomínka k chováni aplikace

1

7.4. Custom fields Defektu Speciální sekce připravená pro specifická pole Zákazníka nebo Společnosti. Pokud je tato sekce prázdná, pak ji prosím ignorujte.

7.5. Workflow a historie Defektu Podrobnější informace najdete v kapitole 6.

7.6. Workaround Defektu Uţitečná textová sekce, kde najdete informace, jak se Problém dočasně obejít aţ do nalezení finálního řešení.

8. Modifikace Defektu Jakmile je Poţadavek uloţen, stane se Defektem s unikátním identifikátorem – číslem Defektu. Uţivatelé TTP s odpovídajícími notifikačními pravidly vţdy najdou v mailové notifikaci číslo Defektu spolu s dalšími důleţitými informacemi, které se týkají prováděných akcí. Čísla Defektů společně s dalšími poloţkami definovanými Uţivatelem (viz. kapitola 5.2, kde najdete podrobnosti, jak poloţky konfigurovat) jsou uvedena v sekci Defect list (Seznam Defektů), která zobrazuje Defekty dle aplikovaného filtru – viz. Obrazovka 13. Podrobnosti o detailu Defektu zobrazíte kliknutím na ikonu View (Zobrazit) nebo Edit (Editovat).

18


Obrazovka 13 Tip: Pokud nevidíte poţadovaný Defekt v seznamu Defektů Defect list, zkuste aplikovat odpovídající filtr (viz. kapitola 9, která se zabývá filtry a jejich modifikací) nebo pouţijte pole Go to Defect (Přejděte na Defekt), jehoţ pomocí se Vám poţadovaný Defekt okamţitě otevře. Tip: Chcete-li Defekt pouze zobrazit, pouţijte ikonu View (Zobrazit). Ikona Edit (Editovat) vţdy Defekt uzamkne pro ostatní Uţivatele TTP a to aţ do chvíle neţ provedete akci Save (Uložit) nebo Cancel (Zrušit). Povoleny jsou následující způsoby modifikace Defektů:   

změna statusu Defektu nebo realizace jiné akce uvedené v kapitole 6, změna záhlaví nebo těla Defektu, přidání nového výskytu Defektu.

Poznámka: Všechny způsoby modifikace mohou být následovány notifikací (viz. kapitola 5.3).

8.1. Změna statusu Defektu a jiné akce Existují dvě moţnosti, jak tyto změny realizovat: 1. Ze sekce Defect list (Seznam Defektů) – označte jeden či více Defektů a zvolte poţadovanou akci na levé straně. Vzhledem k tomu, ţe můţe být zvolena jakákoliv mnoţina Defektů, jsou k dispozici všechny akce dostupné příslušnému Uţivateli TTP s přístupem. 2. Z Defect detail (Podrobností o Defektu) – označte Defekt a klikněte na ikonu Edit (Editovat). Objeví se detail Defektu. Na levé straně je k dispozici jen ta mnoţina akcí, která je v daný moment logicky proveditelná – viz. Obrazovka 14.

8.2. Změna záhlaví či těla Defektu Můţete změnit kterékoliv pole záhlaví nebo těla přístupné pro Uţivatele TTP s přístupem. Stačí kliknout na ikonu Save (Uložit) a uloţit tak provedené změny.

19


Obrazovka 14

8.3. Nový výskyt Problému V případě, ţe se stejný Problém objeví znovu, není vhodné jej zadávat jako nový Defekt – tato metoda by vedla k duplicitám Defektů. V TTP existuje pro tyto účely speciální funkce přístupná z těla Defektu kliknutím na Add (Přidat). Objeví se nová instance těla Defektu, kam je moţné zanést specifika nového výskytu. Vyplňte poloţky stejným způsobem jako při přidávání nového Defektu (viz. kapitola 7.2).

Obrazovka 15

9. Filtry V TTP existuje řada předpřipravených filtrů, které mohou být uţitečné při filtrování Defektů na stránce Defect list. V případě potřeby si můţete definovat svůj vlastní filtr na stránce Filters page (Stránka filtrů). Klikněte na ikonu Add (Přidat) na Filters page (Stránce filtrů) a vytvořte si vlastní filtr tak, ţe vyplníte:   

Název, Popis, Podmínky.

Viz. příklad v Obrazovka 16.

20


Obrazovka 16 Poznámka: Uţivatelé TTP s přístupem mohou vytvářet nebo modifikovat pouze vlastní filtry! V případě potřeby vytvoření či modifikace veřejného filtru (viditelného rovněţ pro ostatní Uţivatele TTP) kontaktujte oddělení Zákaznické podpory Společnosti.

10. Reporty Stránka Reports page (Stránka reportů) zpřístupňuje reporty. Reporty se skládají z mnoha funkčních a designových parametrů – podrobnosti jsou specifikovány v sekci Nápověda TTP (viz. kapitola 3). Tip: Report je vţdy zaloţen na aktuálním filtru. Pokud pro vaše účely ţádný filtr nevyhovuje, vytvořte si nejdříve svůj vlastní filtr (viz. kapitola 9). Poznámka: Uţivatelé TTP s přístupem mohou vytvářet nebo modifikovat pouze vlastní reporty! V případě potřeby vytvoření či modifikace veřejného reportu (viditelného rovněţ pro ostatní Uţivatele TTP) kontaktujte oddělení Zákaznické podpory Společnosti.

11. Proces Zákaznické podpory Veškeré důleţité ovládací prvky TTP a principy jejich pouţití byly podrobně popsány. Cílem této sekce je přesně specifikovat proces řešení Problémů od jejich zaloţení aţ k finálnímu vyřešení. Jen důsledná aplikace popsaných procesů vede k dosaţení poţadovaných výsledků Zákaznické podpory.

11.1.

Aktéři procesu

Procesu se účastní tito aktéři (někteří z nich jsou jiţ popsáni v kapitole 2):         

TTP, Zákazník, Uživatel - pracovník Zákazníka registrovaný v systému TTP, Incident manager – pracovník Společnosti zodpovědný za management defektů, Řešitel – pracovník Společnosti zodpovědný za odstranění problému, Tester – pracovník Společnosti, který zabezpečuje integrační a regresní testy, Deployer – pracovník Společnosti, který zastřešuje nasazení komponent do testovacího prostředí popřípadě k zákazníkovi. Defect Manager - pracovník Společnosti zodpovědný za distribuci Komponent k zákazníkovy

21


22

Podpora zákazníků - Uživatelská příručka

11.2.

Procesní mapa

23


11.3.

Hlavní procesní scénář

1. Incident identification – Uţivatel identifikuje Problém a zároveň zajistí veškeré potřebné údaje a další artefakty potřebné k zaloţení Defektu jako jsou:    

seznam Produktů, jichţ se problém týká, závaţnost problému, dopad na koncové uţivatele Produktu, aplikační logy, screenshoty, chybové hlášky a další artefakty, které jsou vyţadovány viz. Příloha A

2. New Defekt entry - Uţivatel zaloţí Defekt v TTP dle pravidel uvedených v této uţivatelské příručce. V případě úspěšného zařazení Defektu do TTP databáze je automaticky vygenerována notifikace, kterou obdrţí:  Uţivatel, který zaloţil Defekt,  ostatní Uţivatelé, kteří mají nastaven filtr na dotčený Produkt,  Incident Manager. 3. Primary Defekt analysis - Incident manager vyhodnotí, zda Defekt splňuje kritéria hlášení dle této uţivatelské příručky a zásad uvedených viz. Příloha A a to zejména zda:     

uvedená priorita odpovídá reálné závaţnosti hlášeného Problému, je uveden správný Produkt a Komponenta, je popis Problému dostačující pro zahájení řešení, je uvedeno jakým způsobem Problém vyvolat, jsou k Defektu připojeny vyţadované artefakty (logy, screenshots, apod.), tak jak je definuje Příloha A .

V případě, ţe je to moţné, navrhne Incident manager způsob dočasného řešení problému (WorkAround). 4. Assigning to Solver - Incident manager aktualizuje disposition na ‚Open – reviewed‘ a provede přiřazení defektu Řešiteli. Při přiřazení vezme v potaz zejména následující faktory:  prioritu Defektu,  zkušenosti Řešitele s Produktem,  aktuální alokaci zdrojů. 5. Problem analysis – Řešitel provede základní analýzu Problému a na základě jeho priority jej začlení do svého implementačního plánu. V případě, ţe je to moţné, navrhne Řešitel způsob dočasného řešení problému (WorkAround). 6. Implementation – Řešitel provede úpravu vedoucí k odstranění hlášeného Problému či nápravě stavu do souladu s funkční specifikací. 7. Unit testing – Řešitel provede UNIT test modifikovaných Komponent. 8. Fix and release to testing – Řešitel provede akce ‘Fix’ s volbou ‘Fixed‘ a ‘Release to testing’ v systému TTP a přiřadí Defekt Testerovi nebo Deployerovi (ve specifických případech můţe být i sám Řešitel). 9. Need another fix – Řešitel provede akci Need another fix pokud je třeba další fix 10. Release to Deployment – Deployer provede nasazení do testovacího prostředí a přiřadí defekt Testerovi 11. Integration or/and regressive testing – Tester provede integrační a/nebo regresní testy dotčených Komponent, provede akci ‚Verify‘ s volbou ‚Need customer verification‘ a přiřadí Defekt na Defekt managera 12. Release distribution –Defect manager zabezpečí distribuci modifikovaných Komponent k Zákazníkovi, případně jejich migraci do Zákazníkova testovacího prostředí. Distribuci předchází uvolnění dokumentu Delivery Advice, případně další průvodní dokumentace. Preferovaným způsobem distribuce je zveřejnění distribučního balíku a průvodní dokumentace na sdíleném prostoru (např. FTP serveru). 13. Release to Customer testing – Defect manager uvolní Defekt k Zákaznickým testům změnou statusu v TTP na ‚Release to customer testing‘ a přiřadí Defekt Uţivateli.

24


14. Customer testing – pracovníci Zákazníka na základě Delivery Advice protestují dodané Komponenty. 15. Customer Verify – Uţivatel označí Problém za přetestovaný akcí ‚Customer verify‘ v systému TTP s volbou ‚Waiting for migration‘. 16. Migration to live – Na základě uzavřených dohod mezi Společností a Zákazníkem proběhne migrace do produkčního systému Zákazníka. 17. Migration verify – Uţivatel potvrdí úspěšnou migraci akcí ‚Migration verify‘ s volbou ‚Closed (Customer verified)‘. Defekt je tímto uzavřen v systému TTP.

11.3.1.

Alternativní scénáře

1a Identifikovaný Problém dosahuje priority 29-32: 1.

Zákazník kontaktuje telefonicky Zákaznickou podporu Společnosti (podrobnosti o tom kdy a jak je moţno Zákaznickou podporu kontaktovat jsou předmětem smlouvy o údrţbě).

2.

následuje návrat před krok 2.

1b. Identifikovaný problém je typu požadavek (feature request) či dotaz (question): 1.

Uţivatel zaloţí Defekt typu feature request či dotaz,

2.

další Defekt WorkFlow se řídí specifickými pravidly dohodnutými mezi Zákazníkem a Společností,

3.

konec procesu.

3a. V Defektu je chybně uveden Produkt či Komponenta: 1.

Incident Manager změní Product či Komponentu,

2.

následuje návrat před krok 3

3b. Priorita Defektu neodpovídá závažnosti problému: 1.

Incident Manager změní disposition na ‘Need Customer input’,

2.

Incident Manager přiřadí Defekt Uţivateli s poţadavkem na přehodnocení Severity a Typu,

3.

Uţivatel přehodnotí Type a Severity a přiřadí Defekt zpět Defect Managerovi,

4.


3c. Defekt nesplňuje kritéria korektního hlášení: 1.

Incident Manager změní disposition na ‘Need Customer input’,

2.

Incident manager provede přiřazení Uţivateli s ţádostí o doplnění či přehodnocení uvedených údajů,

3.

Uţivatel doplní či pozmění údaje, které nesplňují kritéria hlášení, případně doplní poţadované artefakty a přiřadí Defekt zpět na Incident managera,

4.


5a. Pro provedení analýzy potřebuje Řešitel podrobnější informace či další artefakty: 1.

Řešitel přiřadí Defekt na Incident Managera s ţádostí o doplnění,

2.


7a. Výsledky UNIT testů jsou neuspokojivé: 1.


11a. Výsledky integračních či regresních testů jsou neuspokojivé: 1.

Tester provede akci ‘Verify’ s volbou ‘Open (Verify failed)’ v systému TTP a přiřadí Defekt zpět Řešiteli,

2.


14a. Výsledky Zákaznických testů jsou neuspokojivé: 1.

Uţivatel provede akci ‘Customer Verify’ s volbou ‘Open (Verify failed)’ v systému TTP a přiřadí Defekt zpět Společnosti,

2.

Defect manager po analýze důvodů provede přiřazení Defektu Řešiteli,

25


3.


15a. Není potřeba sledovat migraci do produkčního prostředí: 1. Uţivatel Defekt verifikuje akcí ‘Customer verify’ s volbou ‘Closed (Customer verified)’ uzavření Defektu, 2. Konec procesu. 16a. Migrace do produkčního prostředí je neúspěšná: 1. V případě, ţe je neúspěch migrace zapříčiněn chybou na migrovaných Komponentách, provede Uţivatel akci ‘Migration verify’ s volbou ‘Customer Verify failed’ v systému TTP a přiřadí Defekt zpět Společnosti, 2. Defect manager po analýze důvodů provede přiřazení Defektu Řešiteli, 3. následuje návrat před krok 5.

26


12. Přílohy Příloha A – pravidla příloh Defektů v TTP

27

Zákaznická podpora UŽIVATELSKÁ PŘÍRUČKA

Recommend Documents