TESTER.PL. Od redaktora

Transkrypt

1

2 Od redaktora Minął kolejny rok, pracowita jesień i połowa bardzo nietypowej, ciepłej jesieniozimy. Wszystko to wpłynęło na opóźnienie prac związanych z tym numerem. A tak naprawdę to dwie sprawy: 1. Konferencja SJSI będzie czy nie w tym roku? 2. Rozpoczęcie przez Komisję Egzaminacyjną SJSI egzaminów w zakresie Certyfikowany tester poziom podstawowy Pierwsza sprawa jest wg stanu na dzień dzisiejszy ciągle otwarta. Drugą moŝemy uznać za zakończony sukcesem projekt, trwający prawie cztery lata (od prac związanych z polską wersja słownika poprzez tłumaczenie sylabusa do prac akredytacyjnych). W następnych numerach spróbujemy tą sprawą zająć się dokładniej. Zgodnie z rozpoczętym w poprzednim numerze cyklem zamieszczamy w tym numerze sprawozdanie z dwóch konferencji, które odbyły się jesienią: CMMI Dlaczego powinno Cię to obchodzić - zapraszaliśmy na nią w poprzednim numerze oraz z TESTWAREZ. W numerze dwie ciekawe pozycje: Kamila Dec pisze z intrygującym tytułem Wystarczająco dobry jest lepszy o Good Enough Quality Joanna Droździel przedstawia typowe sytuacje przy Zarządzaniu incydentem i problemem Prócz tego Joanna Nowakowska przedstawia, co działo się na sesji ISTQB w grudniu w ParyŜu. Równocześnie zamieszczamy zaproszenia na trzy ciekawe konferencje organizowane w naszej części Europy: 1. Software & Systems Quality Conferences 2007 w Dusseldorfie ( 2. CONQUEST 2007 w sierpniu w Poczdamie (poniŝej znajdziecie CfP na tą konferencję) 3. Quality Assurance Management and Technologies QAMT w końcu września w Kijowie ( Równocześnie chciałbym kolejny raz - gorąco zachęcić wszystkich czytelników tego periodyku do aktywnej współpracy. Cały czas czekamy na Państwa uwagi, artykuły, felietony wszystko, co Was interesuje, co chcielibyście przeczytać, czego się dowiedzieć. JeŜeli tylko będziemy mogli, postaramy się zrealizować Państwa postulaty. Z ostatniej chwili: Strona 2 z 37

3 zapraszamy teŝ na Test Management Summit Warsaw w Warszawie, 25 marca Program wygląda bardzo ciekawie. Więcej szczegółów na stronie: Strona 3 z 37

4 CONQUEST 2007 This year with EuroSPI 2 September 26 28, 2007, Potsdam, Germany Call for Papers The Call for Papers of the CONQUEST and EuroSPI 2 are out now. Both take place as partner conferences from September 26th to 28th, 2007 in Potsdam (near the German capital Berlin). The main topic of the 10th Conference on Quality Engineering in Software Technology, CONQUEST, is going to be business processes engineering (BPE). The European Systems & Software Process Improvement and Innovation, EuroSPI 2, is going to put emphasis on Success Factors with SPI in a Global Competitive Environment - New Research, Methods and Experiences. Submission Details Contributions may cover any quality related aspect of software engineering, but should be classified by choosing the topics below, which characterize the contribution best: Strona 4 z 37

5 Business processes engineering (BPE), Model driven engineering (MDE), Requirements engineering (RE), Verification and validation (V&V), Testing, Metrics and measurements of system quality and of development processes, Analytical models of software engineering, Project management (PM), Configuration management (CM), IT security Contributions related to industrial experiences are particularly welcomed. Proposals should be submitted electronically to the Program Committee by March 30, Since 1997, CONQUEST has been the platform for software professionals bringing together the software engineering community to discuss software quality aspects, to see how quality engineering methods and techniques are used in both industrial and research environments, to see the latest tools, to share experiences on projects and representative case studies, and to hear about future directions. CONQUEST 2007 will feature tutorials and presentations of invited speakers and from members of the quality and software engineering community. It provides a full picture of software quality in theory and practice. This year special emphasis is given to business process engineering (BPE) how domain specific business processes can be modelled and engineered, how highquality IT infrastructure can be developed for specific business processes, how the business processes are continuously evolved and improved. Papers on the overall quality of business processes are appreciated in particular. Strona 5 z 37

6 Please find more information about both Call for Papers at the following websites: and Strona 6 z 37

7 Wystarczająco dobry jest lepszy Kamila Dec WINUEL SA Absolwentka Wydziału Elektrycznego Politechniki Poznańskiej, kierunek Informatyka. Obecnie jest pracownikiem firmy WINUEL SA. Jako analityk konsultant uczestniczyła w wielu przedsięwzięciach zarządzając nimi, pełniąc rolę analityka, projektanta, biorąc udział w testowaniu funkcjonalnym dostarczanych rozwiązań, wdraŝaniu ich oraz szkoleniach uŝytkowników końcowych. W 2003 roku zdobyła ISEB Software Testing Foundation Certificate. Interesuje się analizą biznesową, testowaniem oraz projektowaniem interakcji. Strona 7 z 37

8 Wystarczająco dobry jest lepszy Kamila Dec WINUEL SA Wprowadzenie Doskonałości teŝ przyda się umiar. Tadeusz Kotarbiński Zainspirowana sformułowaniem Good Enough Quality, pochodzącym z Rational Unified Process (RUP), chciałabym poświęcić kilka chwil zarówno pojęciu Quality, jak i Good Enough, z naciskiem na to drugie. Kiedy nasz produkt jest juŝ wystarczająco dobry, aby przekazać go klientowi? I jakie ryzyko niesie ze sobą zgoda na zastąpienie po prostu dobry przez wystarczająco dobry? W praktyce na pierwsze pytanie najczęściej odpowiada za nas rzeczywistość, dyktowana zobowiązaniami kontraktowymi, terminami i prawami rynku. Wydanie oprogramowania rzadko kiedy jednak oznacza koniec jego rozwoju (a nie jest tak, jeśli produkt, zamiast do archiwum, trafia do rąk klienta), więc świadomość ryzyka, która jest pierwszym krokiem do zaradzenia mu, jest w tej sytuacji praktycznie konieczna. W literaturze i Internecie moŝna przeczytać o wielu metrykach i bazujących na nich metodach, które słuŝą róŝnym celom, np. pozwalają oszacować pracochłonność przedsięwzięcia, a przez to czas i koszt jego realizacji (np. model COCOMO, ang. COnstructive COst MOdel, metoda punktów funkcyjnych, itd.). W niniejszym artykule chciałabym jednak skupić się tylko na tych metrykach i metodach 1, które prowadzą do osiągnięcia następującego celu pozwalają uzyskać odpowiedź na pytanie czy nasz produkt jest wystarczająco dobry, a więc na metrykach jakości oprogramowania i metodach szacowania liczby ukrytych błędów. NaleŜy zwrócić uwagę, Ŝe na tę odpowiedź składają się dwa elementy: ocena jakości procesu testowania poniewaŝ to proces testowania dostarcza nam danych do oceny jakości oprogramowania, musimy mieć pewność, Ŝe dane te są wiarygodne, a proces skuteczny; 1 Muszę tu jednocześnie zaznaczyć, Ŝe są to tylko wybrane metryki i metody. Strona 8 z 37

9 ocena jakości produktu, jakim jest oprogramowanie (na podstawie wiarygodnych wyników dostarczonych przez proces testowania). W poszukiwaniu jakości Do doskonałości brakowało jej tego, Ŝe nie miała wad. Karl Klaus Według autorów [2] pojęcie jakość jest synonimem relacji pomiędzy człowiekiem a rzeczą. Nawet, jeśli produkt pozostaje niezmienny, ludzie i otoczenie się zmieniają, zmienia się więc postrzeganie jakości. Dodatkowo sprawę komplikuje fakt, Ŝe definicja jakości zaleŝy w duŝym stopniu od dziedziny problemu; co innego oznacza to pojęcie dla NASA, a zupełnie co innego oznacza ono w kontekście oprogramowania do zastosowań medycznych, gier komputerowych czy oprogramowania sklepu internetowego. Podobno pojęcie jakość po raz pierwszy zdefiniował Platon jako pewien stopień doskonałości. I ta definicja jest chyba najlepsza na potrzeby niniejszego artykułu. Encyklopedia Wikipedia podaje równieŝ inną ciekawą definicję: Właściwość jednostki odnosząca się do jej zdolności zaspokojenia wymagań jakościowych, przy czym przez wymagania jakościowe rozumiem tu: Funkcjonalność zdolność systemu (przy załoŝonych warunkach uŝytkowania) do realizacji funkcji, które odpowiadają stwierdzonym i przewidywanym potrzebom uŝytkownika. Niezawodność zdolność systemu (przy załoŝonych warunkach uŝytkowania) do utrzymania określonego poziomu bezawaryjności (odporność systemu na awarie). Efektywność zdolność systemu (przy załoŝonych warunkach uŝytkowania) do osiągania efektów odpowiednich do stopnia zuŝycia zasobów. UŜyteczność łatwość zrozumienia, nauki i uŝytkowania systemu oraz zapewnienie satysfakcji uŝytkownika (przy załoŝonych warunkach uŝytkowania). Przenośność zdolność systemu do przenoszenia pomiędzy środowiskami. Pielęgnowalność zdolność systemu do modyfikacji. Definicja jakości według normy ISO 9000 brzmi następująco: Ogół cech i właściwości wyrobu lub usługi, które decydują o zdolności wyrobu lub usługi do zaspokojenia stwierdzonych lub przewidywanych potrzeb uŝytkownika produktu. Przytaczam ją tutaj, ze względu na pewien dodatkowy aspekt, nie uwzględniony w pozostałych definicjach: zdolność do zaspokojenia przewidywanych potrzeb. Wrócę do tego problemu w dalszej części artykułu. Strona 9 z 37

10 Doskonałość absolutna, w czymkolwiek by się przejawiała, jest symptomem śmierci. Antoine de Saint-Exupery Produkt wystarczająco dobry PoniŜej omówiłam wybrane metryki jakości oprogramowania, biorąc pod uwagę zarówno aspekt jakości procesu testowania produktu, jak i jakość samego produktu. Co prawda decyzja dotycząca tego czy produkt jest wystarczająco dobry, a więc czy moŝna juŝ zakończyć testowanie i przekazać go klientowi, jest podejmowana na podstawie róŝnych kryteriów (i w dodatku z róŝną wagą dla kaŝdego z nich), mimo to przy kaŝdej metryce pokusiłam się o określenie jej potencjalnego wpływu na tę decyzję. Jakość procesu testowania Pokrycie wymagań Metryka pokrycia wymagań pozwala stwierdzić jaka część wymagań została przetestowana lub przeszła testy z wynikiem pozytywnym. WyraŜona jest następującym wzorem: Pokrycie wymagań = Liczba wymagań (P, I, W, S) / Liczba wymagań (A, T) Metrykę tę moŝna wykorzystywać na róŝnych etapach procesu testowania, do oceny pokrycia wymagań przez planowane (P), zaimplementowane (I) lub wykonane (W) zadania testowe. Badając ocenę jakości produktu moŝna równieŝ w oparciu o tę metrykę szacować odsetek wymagań, które przeszły testy z wynikiem pozytywnym (S), przy czym liczbę tych wymagań moŝna zarówno odnosić do liczby wszystkich wymagań (A), jak i do liczby wymagań przetestowanych (T). W naszym przypadku (do oceny jakości procesu testowania) metryka pokrycia wymagań jest interesująca jako współczynnik mówiący o tym, ile wymagań zostało faktycznie przetestowanych, czyli: Pokrycie wymagań = Liczba wymagań przetestowanych / Liczba wszystkich wymagań Jak wspomniałam wcześniej, norma ISO mówi o zdolności wyrobu lub usługi do zaspokojenia stwierdzonych lub przewidywanych potrzeb uŝytkownika produktu. Tak naprawdę nigdy nie mamy pewności czy uŝytkownik wyartykułował wszystkie swoje wymagania odnośnie produktu, czy Specyfikacja Wymagań jest kompletna, czy nie pominięto w niej Ŝadnych sytuacji wyjątkowych lub odwołań do standardów, które oprogramowanie musi spełniać. W związku z tym, przez Liczbę wszystkich wymagań w powyŝszym wzorze, naleŝy rozumieć nie tylko wymagania udokumentowane, ale równieŝ wymagania przewidywane. Strona 10 z 37

11 Dobrze zdefiniowany zbiór wymagań charakteryzuje się między innymi tym, Ŝe wymagania są w nim ułoŝone według waŝności. Z punktu widzenia osoby podejmującej decyzję o zakończeniu procesu testowania idealna jest sytuacja, gdy pokrycie wymagań wynosi 100%, jednak w praktyce współczynnik ten moŝe mieć niŝsze wartości (choćby dlatego, Ŝe nie zawsze testowanie wszystkich wymagań jest opłacalne ). W takich przypadkach przydatna moŝe okazać się informacja o pokryciu wymagań według ich wagi. Zupełnie czymś innym jest fakt przetestowania 70% wymagań, z czego wszystkich krytycznych i waŝnych, a tylko części uŝytecznych, niŝ sytuacja przetestowania 90% wymagań, z czego wszystkich uŝytecznych i waŝnych, a tylko części krytycznych. Z mojego punktu widzenia korzystniejsza moŝe okazać się sytuacja pierwsza. Pokrycie kodu Metryka pokrycia kodu pozwala stwierdzić jaka część kodu źródłowego została wykonana podczas testów. WyraŜona jest następującym wzorem: Pokrycie kodu = Liczba wykonanych jednostek kodu / Liczba wszystkich jednostek kodu, gdzie liczba jednostek kodu moŝe być rozumiana jako: liczba linii kodu (LOC ang. lines of code), liczba ścieŝek (instrukcja if then else stanowi dwie moŝliwe ścieŝki do przejścia jedną przy spełnionym warunku i drugą, gdy warunek nie jest spełniony), itp. Kod źródłowy naleŝy traktować jako dokumentację wyobraŝenia programisty o wymaganiach wobec oprogramowania. Na wyobraŝenie to składa się to czego klient naprawdę oczekuje po przejściu przez filtr wyobraŝeń analityka, projektanta i w efekcie samego programisty. Co więcej kod źródłowy moŝe być obarczony dodatkowo takimi uchybieniami jak implementacja funkcji, których klient nie potrzebuje oraz brak funkcji wymaganych. Stąd informacja o pokryciu kodu, choć uŝyteczna w róŝnych zastosowaniach, niewiele wnosi przy próbie odpowiedzi na pytanie czy nasz produkt jest wystarczająco dobry. Nawet jeśli będziemy wiedzieli, Ŝe przetestowano cały kod i co więcej nie znaleziono w nim Ŝadnego błędu, nie będziemy wiedzieli zbyt duŝo o zdolności produktu do zaspokojenia stwierdzonych lub przewidywanych potrzeb jego uŝytkownika. Efektywność usuwania błędów Efektywność usuwania błędów (ang. Defect Removal Effectiveness) jest wyraŝona następującym wzorem (przytaczam jedną z kilku interpretacji tej metryki): DRE = Liczba błędów znalezionych w czasie testów/ Liczba wszystkich znalezionych błędów, Strona 11 z 37

12 gdzie Liczba wszystkich znalezionych błędów jest to suma liczby błędów znalezionych w czasie testów i liczby błędów znalezionych po testach (w szczególności przez klienta, po wydaniu oprogramowania, w danym okresie 2 ). Aby przybliŝyć zastosowanie tej metryki, posłuŝę się przykładem (po modyfikacjach) z opracowania [3]: Faza, w której popełniono błąd Faza, w której wykryto błąd Analiza Projekt Kodowanie RAZEM Analiza Projekt Kodowanie Błędy wykryte po wdroŝeniu oprogramowania (przez klienta i wewnętrznie) RAZEM Efektywność dla fazy analizy = 10/ 14 = 71% Efektywność dla fazy projektowania = 21/ ( ) = 75% Efektywność dla fazy kodowania = 30/ ( ) = 75% Efektywność całkowita = ( )/ ( ) = 86% Metryka ta mówi o tym jak efektywny jest nasz proces testowania i jak skuteczny w wykrywaniu/ usuwaniu błędów. Do oszacowania efektywności całkowitej niezbędna jest jednak informacja o liczbie błędów wykrytych po wdroŝeniu oprogramowania, czego w naszej sytuacji jeszcze nie wiemy. Podstawą w tym przypadku są więc dane historyczne. Jeśli je posiadamy, wiemy jak kształtowały się współczynniki efektywności w innych przedsięwzięciach (np. przy produkcji poprzedniej wersji tego samego oprogramowania) dla zespołu testerów o takich samych lub podobnych kompetencjach i przy takim samym lub podobnym przebiegu procesu testowania. W takich warunkach moŝna załoŝyć, Ŝe efektywność usuwania błędów kształtuje się na podobnym poziomie. Dla modelu CMM określono wartości DRE osiągane przez organizację na kaŝdym z pięciu poziomów dojrzałości. Przytaczam je tutaj za [1]: Poziom dojrzałości według CMM Poziom 5 95% Poziom 4 93% Poziom 3 91% Defect Removal Effectiveness 2 Autor ksiąŝki Metrics and Models in Software Quality Engineering, Stephen H. Kan twierdzi, Ŝe znaczna większość błędów zostaje wykryta w ciągu dwóch lat od wydania oprogramowania. Najczęściej przyjmuje się jednak okres sześciu miesięcy. Strona 12 z 37

13 Poziom dojrzałości według CMM Defect Removal Effectiveness Poziom 2 89% Poziom 1 85% Jakoś produktu Metryka częstości błędów Metryka częstości błędów (ang. Defect Density) jest wyraŝona następującym wzorem: DD = Liczba znanych błędów/ Rozmiar kodu, gdzie Rozmiar kodu jest to liczba okazji do popełnienia błędów [1] wyraŝona jako liczba KLOC (ang Lines of Code) lub liczba punktów funkcyjnych. Istnieje wiele róŝnych definicji LOC. Linią kodu w tym znaczeniu moŝe być kaŝda fizyczna linia kodu, kaŝda wykonywalna linia kodu, z uwzględnieniem komentarzy lub bez, z uwzględnieniem definicji danych lub bez, itd. W wielu przypadkach jest to wartość, którą trudno zmierzyć, i która zaleŝy od uŝytej technologii (potrzeba więcej linii kodu w asemblerze niŝ w C#, aby zaimplementować tę samą funkcjonalność). Z powodu róŝnic w interpretacji metryki LOC i trudnościach w oszacowaniu jej wartości wielu autorów sugeruje metrykę punktów funkcyjnych. 3 Metryka częstości błędów ma kilka zastosowań. MoŜe być między innymi wykorzystywana do porównywania jakości róŝnych komponentów, co pozwoli zidentyfikować te o większym współczynniku błędów i w porę podjąć działania zaradcze. MoŜe równieŝ, co jest najbardziej interesujące z naszego punktu widzenia, być stosowana do oceny czy produkt jest wystarczająco dobry, przy czym w tym przypadku konieczne jest posiadanie danych historycznych, a im więcej ich jest, tym lepiej. Steve McConnell w swoim artykule [4] omawia następujący przykład (podaję go po drobnych modyfikacjach): KLOC Liczba znanych błędów Przed wdroŝeniem Po wdroŝeniu DD Wydanie ,0 Wydanie ,5 Wydanie X ZałóŜmy, Ŝe musimy podjąć decyzję o tym czy jesteśmy gotowi do trzeciego wydania. Biorąc pod uwagę współczynniki DD dla poprzednich dwóch wydań, moŝemy się spodziewać (pod warunkiem, Ŝe nie dokonaliśmy jakichś rewolucyjnych zmian w naszym procesie produkcji), 3 Swoją drogą, oszacowanie liczby punktów funkcyjnych równieŝ jest zadaniem nietrywialnym i często wymaga zaangaŝowania eksperta. Strona 13 z 37

14 Ŝe dla tego wydania osiągniemy równieŝ od 7 do 10 błędów/ KLOC. ZałóŜmy, Ŝe jako kryterium przyjęliśmy usunięcie 95% błędów przed publikacją oprogramowania. Dla współczynnika DD = 7,0 mamy: (600 + X) / 100 = 7,0 X = 100 Łączna liczba błędów wynosi , co oznacza, Ŝe aby spełnić nasze kryterium (95%), musimy wykryć 665 błędów przed publikacją oprogramowania (w takim razie pozostało jeszcze 65). Dla współczynnika DD = 10,0 mamy natomiast: (600 + X) / 100 = 10,0 X = 400 Łączna liczba błędów wynosi , co oznacza, Ŝe aby spełnić nasze kryterium (95%), musimy wykryć 950 błędów przed publikacją oprogramowania (pozostało jeszcze 350 duŝo pracy przed nami). Niezawodność oprogramowania - średni czas międzyawaryjny Zanim omówię tę metrykę, zdefiniuję dwa podstawowe pojęcia, którymi będę się posługiwać: błąd i awaria 4. Awaria to nieoczekiwane zachowanie systemu, które wystąpiło w czasie jego pracy i zostało zauwaŝone przez uŝytkowników. Błąd to pomyłka prowadząca do niepoprawnego zapisu w kodzie źródłowym. Nie kaŝdy błąd musi skutkować awarią oprogramowania, ponadto jeden błąd moŝe powodować kilka róŝnych awarii. W duŝym stopniu zaleŝy to od profilu uŝycia systemu jeśli błąd występuje w funkcji częściej uŝywanej przez uŝytkowników, istnieje większe prawdopodobieństwo, Ŝe się objawi w postaci awarii. Średni czas międzyawaryjny (ang. Mean Time Between Failures) oznacza czas pomiędzy awariami mierzony w określonych jednostkach (najczęściej godzinach, ale równieŝ dniach, miesiącach lub latach). MoŜna więc przyjąć, Ŝe nasze oprogramowanie jest wystarczająco dobre, gdy współczynnik MTBF osiągnie w testach (pod warunkiem ich prowadzenia w odpowiedni sposób) poŝądaną wartość. Autor ksiąŝki [1], Stephen H. Kan twierdzi, Ŝe, dla systemów, które nie mają typowego profilu uŝycia, metryka ta jest trudna do implementacji i moŝe nie być reprezentatywna. Poza tym, gromadzenie danych o czasie pomiędzy wystąpieniem awarii jest bardzo kosztowne i wymaga metod statystycznych. Dlatego teŝ metryka ta jest bardzo rzadko stosowana do oceny 4 W literaturze róŝne pojęcia mają te same definicje. Przyjęłam więc dwa z nich, dla porządku. Strona 14 z 37

15 jakości (niezawodności) oprogramowania komercyjnego (częściej jednak do oceny oprogramowania o krytycznym znaczeniu dla bezpieczeństwa). Inne techniki szacowania liczby ukrytych błędów We wspomnianym juŝ przeze mnie artykule [4] jego autor, Steve McConnell, omawia jeszcze dwie ciekawe techniki, o których chciałabym napisać kilka słów: 1. Defect Pooling Wszystkie błędy znalezione podczas testów naleŝy podzielić na dwa zbiory, A i B. Kryterium podziału jest dowolne, przy czym kaŝdy z tych zbiorów powinien obejmować cały zakres funkcjonalny testowanego produktu. Autor proponuje, aby do jednego zbioru przypisać np. wszystkie błędy znalezione w poniedziałki, środy i weekendy, a do drugiego błędy znalezione w pozostałe dni. MoŜna równieŝ dokonać podziału według testerów błędy znalezione przez jedną połowę zespołu testującego przypisać do jednego zbioru, a błędy drugiej połowy do drugiego. W omawianej technice istotna jest: liczba błędów w zbiorze A (we wzorze oznaczona symbolem A), liczba błędów w zbiorze B (we wzorze oznaczona symbolem B), liczba błędów w części wspólnej zbioru A i B (we wzorze oznaczona symbolem A&B). Liczba wszystkich błędów (znalezionych i pozostających do znalezienia) jest szacowana z następującego wzoru: Całkowita liczba błędów = (A * B)/ A&B Przy stałej liczbie błędów w zbiorze A i B, im mniejsza będzie część wspólna tych zbiorów, tym większa przewidywana całkowita liczba błędów. 2. Defect Seeding Technika ta polega na celowym umiejscowieniu w kodzie źródłowym programu błędów. Informacja o tym ile z tych błędów zostało wykrytych podczas testowania pozwala przewidywać ile błędów z tych, które były pierwotnie w oprogramowaniu, pozostaje jeszcze do wykrycia. Technika ta jest najbardziej skuteczna, jeśli błędy celowo umieszczone w kodzie źródłowym obejmują cały zakres funkcjonalny oraz są róŝnej wagi od błędów krytycznych po kosmetyczne. Przyjmę następujące oznaczenia: P Znalezione Liczba znalezionych błędów pierwotnych P Wszystkie Liczba wszystkich błędów pierwotnych C Znalezione Liczba znalezionych błędów celowo umiejscowionych w kodzie C Wszystkie Liczba wszystkich błędów celowo umiejscowionych w kodzie W technice tej przyjmuje się, Ŝe liczba znalezionych błędów pierwotnych jest równa: Strona 15 z 37

16 P Znalezione = (C Znalezione / C Wszystkie ) * P Wszystkie stąd liczba wszystkich błędów pierwotnych jest równa: P Wszystkie = P Znalezione * (C Wszystkie / C Znalezione ) Jeśli więc w kodzie programu umiejscowiono celowo 40 błędów, z czego wykrytych zostało 30, a pierwotnych błędów wykryto 500, to moŝna się spodziewać, Ŝe łączna liczba błędów pierwotnych wynosi: P Wszystkie = 500 * (40 / 30) = 667 Znaleźliśmy więc dopiero 75% błędów. ZałóŜmy, Ŝe jako kryterium przyjęliśmy usunięcie 95% błędów przed publikacją oprogramowania, co stanowi ok. 630 błędów. Mamy więc jeszcze sporo do zrobienia. Technika ta jest przydatna, lecz ma kilka wad: Celowe umiejscowienie błędów w kodzie programu jest kosztowne, wymaga dodatkowych nakładów pracy. MoŜna zapomnieć o usunięciu tych błędów, a przy ich usuwaniu zrobić kolejne. Ideały są jak gwiazdy. Jeśli nawet nie moŝemy ich osiągnąć, to naleŝy się według nich orientować. Podsumowanie George Bernard Shaw PowyŜej omówiłam wybrane metryki i techniki, które mogą być przydatne przy ocenie czy produkt jest wystarczająco dobry do wdroŝenia. Postawienie sobie takiego pytania wymaga pewnej dojrzałości organizacji, jeszcze większej natomiast wymaga świadoma na nie odpowiedź. Autorzy ksiąŝki [2] proponują taki test jeśli chcesz wiedzieć co organizacja naprawdę myśli o jakości, obserwuj trzy ostatnie dni kaŝdego sześciomiesięcznego przedsięwzięcia zobacz co się stanie, jeśli ostatniego dnia zostanie zgłoszony nowy problem. Osobiście wyznaję w takich sytuacjach zasadę: lepszy znany wróg niŝ nieznany przyjaciel. Wykrycie i usunięcie wszystkich błędów jest niemoŝliwe, a jeden błąd zazwyczaj stanowi nikły procent całości. Pochopne usuwanie go w ostatniej chwili moŝe z kolei spowodować całą lawinę błędów, które wykryje dopiero niezadowolony klient. Trzeba pogodzić się ze świadomością, Ŝe za kaŝdym razem kiedy publikujemy oprogramowanie, dajemy uŝytkownikom do ręki produkt z błędami 5 (choć i tak to uŝytkownicy będą mieli większą trudność z pogodzeniem się z tym faktem). Dobrze jest jednak wiedzieć jak wadliwy jest to produkt i czy wydanie go tu i teraz przysporzy więcej korzyści czy problemów. 5 Stąd właśnie wymagania dotyczące dostępności i niezawodności są podgrupą wymagań niefunkcjonalnych. Strona 16 z 37

17 W niniejszym opracowaniu omówiłam tylko wybrane metryki i techniki szacowania liczby ukrytych błędów oparte na danych dostarczonych przez proces testowania (liczba znalezionych błędów). Pomijam tematykę modeli niezawodności, równieŝ bazujących na tych danych, których zastosowanie wymaga pewnej wiedzy statystycznej. W literaturze moŝna takŝe przeczytać o wielu innych metodach, na przykład opartych na miarach rozmiaru programu (bazujących na związku pomiędzy rozmiarem programu, a liczbą ukrytych w nim błędów). Większość z tych metod, między innymi z racji tego, Ŝe operują pojęciem błędu zamiast awarii (róŝnice między nimi patrz rozdział dotyczący metryki MTBF), a więc tak naprawdę nie mówią za duŝo o niezawodności oprogramowania, spotyka się z szeroko zakrojoną krytyką. Stąd trwają prace nad wykorzystaniem w tym obszarze drzew decyzyjnych czy sieci Bayesa, które pozwalają bazować na wielu róŝnych kryteriach będących wyznacznikiem niezawodności. Więcej informacji moŝna znaleźć w [1] oraz wielu artykułach dostępnych w Internecie. Literatura KsiąŜki: [1] Metrics and Models in Software Quality Engineering, 2nd Edition, Stephen H. Kan, Addison Wesley Professional, 2003 [2] The Rational Unified Process Made Easy, A Practitioner s Guide to the RUP, Per Kroll, Philippe Kruchten, Pearson Education Inc., 2003 Artykuły: [3] Defect Removal Effectiveness, Linda Westfall (dostępne w Internecie pod adresem: [4] Gauging Software Readiness With Defect Tracking, Steve McConnell (artykuł dostępny pod adresem: [5] An overview of software quality concepts and management issues, Claude Y. Laporte, 2005 (artykuł dostępny w Internecie pod adresem: Strona 17 z 37

18 Software & Systems Quality Conferences 2007 We would like to invite you to join colleagues and associates from the Software & Systems Quality Management and Testing profession at the industry s most important conference in The programme has been carefully designed by our independent programme committee to fulfill the comments and feedback gathered from delegates at our conferences and seminars throughout the year. We have selected presentations that offer new answers to obstacles and problems we face today and case studies wherever possible. We have had a tremendous response to the call for papers this year and we are grateful to everyone for communicating their ideas for the 2007 conference. The SQC conference provides solutions, state-of-the-art best practices and services to IT professionals. The mission of this must attend conference, now in its 12th year is to: help make sense of trends, technologies, and strategies in the Software & Systems Quality world today learn about the latest developments in outsourcing, process models and optimization, test management and test automation, embedded systems learn about testing in SOA and agile project environment, and model-based testing Exhibitors are also preparing to show their latest offerings to you at the most comprehensive exhibition in this field in So come along and see the latest tools and services from the leading suppliers in software testing and quality. Prepare yourself for three interesting days packed with lectures, workshops, and tutorials as well as the accompanying exhibition and an evening event in Dusseldorf. Get to know the latest trends and innovative solutions, discuss the issues that matter to your business, swap experience and information with experts. For further information please have a look at Strona 18 z 37

19 Zarządzanie problemem i incydentem Joanna Droździel Joanna Droździel jest absolwentem Informatyki na Wydziale Elektrycznym Politechniki Warszawskiej. Obroniła pracę magisterską z zakresu metodyki ITIL. Od października 2006 roku prowadzi blok wykładów Zarządzanie usługami IT na Podyplomowym Studium Prowadzenia Projektów Informatycznych na Politechnice Waszawskiej. Obecnie pracuje w firmie IMPAQ na stanowisku analityka do spraw zapewnienia jakości, biorąc udział w projektach dla klientów w kraju, jak równieŝ dla klientów zagranicznych. W obecnej pracy wykorzystuje głównie procesy z zakresu Service Support, zarządzania problemem oraz incydentem. Strona 19 z 37

20 Zarządzanie problemem i incydentem Joanna Droździel 1. Service Desk W większości przedsiębiorstw wyodrębniony został oddział odpowiedzialny za bezpośredni kontakt z uŝytkownikiem. Najpopularniejszą jednostką realizującą to zadanie jest Help Desk, ale pojawiają się równieŝ inne rozwiązania takie jak: Call Center, Customers Service Center oraz Customer Hotline. Bez względu na bardzo rozbudowane obowiązki, jednostki te mają jedno wspólne zadanie do wykonania: jak najszybsze rozwiązanie awarii oraz incydentów zgłaszanych przez uŝytkowników. Działania całego działu informatycznego postrzegane są przez działalność Help Desku, poniewaŝ stanowi on pierwszy i jedyny bezpośredni kontakt dla uŝytkownika. Z badań Forrester Research wynika, Ŝe prawie połowa z 2000 badanych uŝytkowników jest niezadowolona z jakości świadczonych usług. Narzekają przede wszystkim na wydłuŝający się czas rozwiązywania zgłoszonych incydentów. MenedŜerowie działów informatycznych oraz przedstawiciele zarządu prześcigają się w wymyślaniu coraz to ciekawszych nazw dla jednostek odpowiedzialnych za bezpośredni kontakt z uŝytkownikiem. Chcą tym samym zamknąć epokę nie lubianych działów Help Desk. Jednak nie w nazwie tkwi problem ale w sposobie organizacji pracy. Dlatego metodyka ITIL wychodzi z propozycją Service Desku. Jego zadaniem jest nie tylko szybka reakcja na zgłoszenie czyli realizacja procesu zarządzania incydentem, ale równieŝ wspieranie procesów zarządzania problemem, zmianą, konfiguracją, wersją, dostępnością oraz procesu zarządzania poziomem usług. Na czym polega unikalność działu Service Desk? Przede wszystkim na poprawnie określonych zadaniach, procesach a w szczególności na pełnej odpowiedzialności, poniewaŝ od efektywności pracy działu Service Desk zaleŝy poprawność pozostałych procesów Service Support. Jednak by działania te przebiegały sprawnie i efektywnie, potrzeba zrozumiałych dla wszystkich zasad. Wytyczne muszą być jasne zarówno dla pracowników działu, uŝytkowników jak i przede wszystkim dla osób odpowiedzialnych za poprawną realizację pozostałych procesów Service Support. Informacje uzyskane dzięki cięŝkiej i efektywnej pracy zespołu Service Desk przekazywane są osobom odpowiedzialnym za realizacje pozostałych procesów omawianego obszaru. Błędnie wykorzystane mogą skutkować załamaniem się całego obszaru Service Strona 20 z 37

21 Support. Dlatego współpraca na linii Service Desk - pozostałe procesy musi być rozwinięta na bardzo wysokim poziomie. 2. Zarządzanie incydentem Jednym z głównych zadań pracowników Service Desk jest zagwarantowanie stałej dostępności usługi informatycznej (Zarządzanie dostępnością). Jednak nawet w sytuacji, gdy firma dysponuje sprzętem najnowszej generacji, trudno wykluczyć moŝliwość wystąpienia awarii. Dlatego pracownicy tego działu powinni być gotowi na szybką reakcję. UŜytkownicy kaŝdego dnia zgłaszają do działu Service Desk kilkadziesiąt a niekiedy i kilkaset awarii. Proces, który jako pierwszy przychodzi z pomocą w sytuacji awaryjnej to proces zarządzania incydentem. Na wstępie warto zapoznać się z pojęciem incydentu. OtóŜ incydent - według metodyki ITIL - to kaŝde zdarzenie (które nie jest częścią normalnego działania) powodujące lub mogące spowodować przerwę w dostarczeniu usługi. Powodów wystąpienia incydentów moŝe być bardzo wiele. Zasadniczo incydenty ze względu na powód wystąpienia podzielone zostały na dwie grupy: incydenty wynikające z awarii sprzętu (awaria drukarki, monitora) oraz incydenty wynikające z awarii oprogramowania (brak dostępu do bazy danych, aplikacji). Cykl Ŝycia incydentu od momentu wykrycia do momentu zamknięcia został omówiony w podrozdziale przedstawionym poniŝej. Proces zarządzania incydentem Celem procesu jest jak najszybsze przywrócenie usługi oraz zminimalizowanie niekorzystnego wpływu na działalność biznesu. Nie ma tutaj miejsca ani czasu na szukanie przyczyn wystąpienia awarii. Na tym etapie stosuje się gotowe i wypróbowane procedury przywracające usługę informatyczną. KaŜdy wykryty incydent powinien zostać zgłoszony i zarejestrowany przez osobę z działu Service Desk. Metodyka ITIL nie podaje jednej konkretnej drogi zgłoszenia incydentu, więc nie jest waŝne czy odbywa się to drogą telefoniczną, za pomocą poczty elektronicznej czy teŝ osobiście. Istotną kwestią na tym etapie procesu jest stworzenie takiego klimatu pracy by uŝytkownicy wykrywając awarię nie bali się zgłaszać jej pracownikom Service Desku. WaŜne teŝ jest by nie doszło do takiej sytuacji gdy kaŝdy uŝytkownik w obawie przed trudnymi pytaniami informatyków podejmuje próbę samodzielnej naprawy awarii, co w rezultacie moŝe doprowadzić do jeszcze większych szkód. Dlatego by uniknąć takich zachowań, pracownik działu Service Desk, przyjmując zgłoszenie o awarii, powinien zadawać tylko pytania potrzebne do identyfikacji obszaru czy części infrastruktury. UŜytkownik zgłaszając awarię nie musi znać numeru seryjnego uszkodzonego monitora czy Strona 21 z 37

22 drukarki; wystarczy, Ŝe wskaŝe miejsce, gdzie dana część infrastruktury się znajduje. W tym przypadku wystarczy informacja, iŝ drukarka znajduje się w dziale księgowym a wszystkimi pozostałymi potrzebnymi informacjami powinien dysponować Service Desk. Informacje te powinny znajdować się w Bazie Konfiguracji - CMDB, która zawiera najdrobniejsze szczegóły o danym sprzęcie i oprogramowaniu oraz relacjach miedzy nimi. Po przyjęciu zgłoszenia ma miejsce określenie przyczyny wystąpienia incydentu. Pełen cykl obsługi incydentu przedstawiono na rysunku 1. Rysunek 1. Cykl Ŝycia incydentu. Z reguły Service Desk jest przeciąŝony pracą poniewaŝ uŝytkownicy generują setki zgłoszeń dziennie. WaŜne jest by w gąszczu błahych awarii nie zostały przeoczone zdarzenia, dla których kaŝda minuta zwłoki przynosi działalności biznesowej wysokie straty. Dlatego bardzo pomocne na tym etapie pracy jest właściwe określenie priorytetu zgłoszenia przez pracownika przyjmującego informację o awarii. Osoba przyjmująca zgłoszenie powinna posiadać odpowiednią wiedzę techniczną niezbędną w szybkim naprawianiu awarii, ale równieŝ powinna znać realia działania przedsiębiorstwa oraz hierarchię priorytetów określoną w ramach umowy Strona 22 z 37

23 SLA tak, by swoją decyzją nie naraŝała firmy na niepotrzebne koszty. Po określeniu priorytetu incydentu następuje przypisanie do odpowiedniej grupy wsparcia. Rysunek 2 przedstawia strukturę grup wsparcia wymienionych przez autorów metodyki ITIL. JeŜeli jest to awaria dobrze znana pracownikom Service Desku oraz dysponują oni gotową do realizacji procedurą naprawienia, wówczas zgłoszenie jest kierowane na pierwszą linie obsługi incydentu. Rysunek 2. Linie wsparcia procesu zarządzania incydentem. JeŜeli natomiast ma miejsce sytuacja, gdzie pracownik Service Desk nie potrafi określić przyczyny wystąpienia awarii, wówczas takie zgłoszenie kierowane jest do drugiej linii wsparcia odpowiedzialnej za poszukiwanie rozwiązania. Wskazane jest aby przed przekierowaniem zdarzenia do drugiej grupy wsparcia udało się je naprawić, nie czyniąc tym samym szkód finansowych dla działalności biznesowej przedsiębiorstwa. Jednak przypadków, które zostały naprawione bez poznania przyczyny ich powstania jest niewiele. Z reguły na drugą linię wsparcia trafiają nierozwiązane problemy, których bez wnikliwego procesu zarządzania problemem nie sposób naprawić. Dlatego wielu praktyków metodyki ITIL uwaŝa, iŝ druga i Strona 23 z 37

24 trzecia linia wsparcia w procesie zarządzania incydentem realizuje załoŝenia procesu zarządzania problemem (będzie o tym mowa w rozdziale następnym). Niekiedy pracownicy drugiej linii wsparcia nie mogąc znaleźć rozwiązania problemu, korzystają z pomocy trzeciej linii wsparcia, którą z reguły stanowią konsultanci z firm zewnętrznych. W procesie zarządzania incydentem nie ma czasu na szukanie przyczyny wystąpienia awarii. Na tym etapie prac w obszarze Service Support stosuje się procedury oraz rozwiązania stanowiące Bazę Wiedzy. Zawiera ona scenariusze postępowania na wypadek konkretnych awarii. Gdy brakuje w bazie danego rozwiązania, wówczas jest to jednoznaczne z sytuacją, iŝ pracownicy Service Desk mają do czynienia z nowym typem awarii, dotychczas nieopisanym. W takiej sytuacji incydent staje się problemem i trafia do procesu zarządzania problemem. Zarówno uŝytkownicy jak i pracownicy Service Desku wiedzą, jak wiele awarii naprawianych jest na bieŝąco. Jest jednak równieŝ grupa nierozwiązanych incydentów, dlatego Service Desk powinien cały czas śledzić oraz monitorować przebieg realizacji incydentów. Nie moŝe dojść do sytuacji, w której pracownicy zapomną o naprawieniu awarii, co w rezultacie narazi przedsiębiorstwo na straty finansowe. By tego uniknąć wiele firm, których uŝytkownicy generują setki zgłoszeń dziennie, decyduje się na zakup dodatkowego oprogramowania pomocnego w obsłudze incydentów. Po określeniu procedury w Bazie Wiedzy następuje etap naprawienia incydentu i w efekcie jego zamknięcie. Według autorów metodyki ITIL Service Desk powinien rozwiązać 85% wszystkich zgłoszeń juŝ w pierwszej linii wsparcia, bez korzystania z pomocy pozostałych grup. Działania proaktywne procesu zarządzania incydentem Zadaniem działu Service Desk nie jest tylko naprawianie zgłaszanych awarii ale przede wszystkim podjęcie działań eliminujących awarie drobne, błahe. Wiadomo, Ŝe nie sposób przeszkolić wszystkich uŝytkowników tak, by nie generowali niepotrzebnych zgłoszeń ale warto czasami zwrócić uwagę na błędy popełniane przez uŝytkowników. Zazwyczaj uŝytkownicy z braku wiedzy, bojąc się zapytać pracowników działu informatycznego, drogą prób i błędów poznają tajniki nowej aplikacji bądź sprzętu. Częściej jednak poszerzają swoją wiedzę drogą popełnianych błędów, za które strona biznesowa zmuszona jest płacić, a Service Desk naprawiać. Dlatego warto przyjrzeć się zachowaniom uŝytkowników oraz ich starym, złym nawykom. Jeden szybki telefon do działu Service Desk z krótkim zapytaniem uchroni organizację przed niepotrzebnymi kosztami. Jako przykład negatywnego zachowania uŝytkownika moŝe posłuŝyć problem drukowania na foliach. Wystarczyło aby uŝytkownik wykonał jeden telefon do Service Desku z zapytaniem, na której drukarce moŝna w ten sposób drukować. Uchroniłoby to firmę przed niepotrzebną wymianą drukarki. Jednak nie wszystkie awarie wynikają z Strona 24 z 37

25 nieprofesjonalnych zachowań uŝytkowników, tego typu awarie stanowią niewielką część wszystkich incydentów. Zdecydowana większość awarii wynika z przestarzałego sprzętu zalegającego w wielu przedsiębiorstwach. Zasada, Ŝe im starsze tym lepsze sprawdza się w przypadku wina. W przypadku komputerów jest odwrotnie - trzyletnia maszyna moŝe juŝ spowodować właścicielowi niemałe kłopoty. Amerykańscy specjaliści wyliczyli, iŝ koszt obsługi starego komputera jest od 3 do 5 razy większy niŝ zakup nowego sprzętu. Dlatego strona biznesowa nie powinna ograniczać funduszy na zakup nowej infrastruktury informatycznej. Zwłaszcza, Ŝe przestarzały sprzęt wymusza na uŝytkownikach bardzo groźne dla całej infrastruktury działania. UŜytkownicy aby przyśpieszyć działanie komputerów wyłączają programy antywirusowe, co sprowadza na przedsiębiorstwo kolejne straty finansowe spowodowane incydentami naruszeń bezpieczeństwa informatycznego. Według raportu magazynu CIO oraz firmy PricewaterhauseCoopers, opracowanego w roku 2003, w 17% firm miało miejsce powyŝej 10 wypadków dotyczących naruszeń bezpieczeństwa firmy w ciągu roku, co było równoznaczne z przestojem w pracy o całkowitym wymiarze od 4 do 8 godzin. Dlatego zamiast wydawać pieniądze na gaszenie poŝarów, warto zainwestować w działania profilaktyczne eliminujące moŝliwość wystąpienia takiego poŝaru. Dzięki takiej postawie ilość zakłóceń w normalnej pracy zarówno dla pracowników Service Desku, jak i uŝytkowników zostanie zmniejszona do niezbędnego minimum. 3. Zarządzanie problemem MenedŜerowie róŝnych działów informatycznych mieli zapewne niejednokrotnie do czynienia z sytuacją, uznawaną przez nich za sytuację bez wyjścia: co zrobić w wypadku, gdy następuje przerwa w dostawie usługi z przyczyn nie rozpoznanych przez personel Service Desku. Z pomocą moŝe przyjść proces zarządzania problemem. NiezaleŜnie od tego Service Desk powinien próbować przywrócić usługę w stopniu, na jaki pozwalają realia zaistniałej awarii. JeŜeli podjęte działania nie przyniosły oczekiwanych rezultatów naleŝy poddać problem szczegółowej analizie. Względy formalne określają, iŝ awarie zgłoszone przez uŝytkowników stają się problemami wówczas, gdy pierwsza linia wsparcia Service Desk nie dysponuje gotowym rozwiązaniem bądź procedurą. W takiej sytuacji incydent staje się problemem. Efektywne zarządzanie problemem zaleŝy w duŝym stopniu od poprawnej implementacji procesu zarządzania incydentem. Strona 25 z 37

26 Proces zarządzania problemem Proces zarządzania incydentem miał na celu jak najszybsze przywrócenie usługi, natomiast proces zarządzania problemem odpowiada za minimalizowanie niekorzystnego wpływu na działalność biznesową incydentów i problemów. Nie ma określonej kolejności wdraŝania procesu zarządzania problemem; najlepszym rozwiązaniem jest wdraŝanie go równolegle z procesem zarządzania incydentem. Zazwyczaj na proces zarządzania problemem nakłada się kilka incydentów, dlatego teŝ warto spojrzeć na to zagadnienie z szerszej perspektywy. Pracownicy Service Desku obserwują kaŝdy indywidualny incydent; w procesie zarządzania problemem jest czas by przejrzeć się całej grupie. Proces zarządzania problemem składa się z dwóch podprocesów: kontroli problemu oraz kontroli błędu. Podproces kontroli problemu ma za zadanie przekształcić nieznaną awarię w znany błąd, natomiast podproces kontroli błędu ma za zadanie rozwiązać znane błędy przygotowując tym samym RfC dla procesu zarządzania zmianą. Service Desk nie posiada gotowych scenariuszy postępowania w przypadku kaŝdej moŝliwej awarii. W procesie zarządzania problemem następuje więc identyfikacja przyczyn występowania incydentów oraz poszukiwanie rozwiązań. Dana awaria kierowana jest do grupy pracowników odpowiedzialnych za proces zarządzania problemem. Zespół ten pracuje w bardziej komfortowych warunkach, niŝ te z jakimi mają do czynienia pracownicy Service Desku. Przede wszystkim działania w procesie zarządzania problemem nie mają określonych ram czasowych, toteŝ pośpiech jest tutaj wręcz niewskazany. NaleŜy jednak zachować w tej kwestii zdrowy umiar. Grupa poszukująca rozwiązania dla danego problemu powinna mieć szczególnie na uwadze względy finansowe, starając się wykluczyć sytuacje naraŝające stronę biznesową na jakiekolwiek dodatkowe straty. Dlatego bardzo waŝne jest aby zespół składał się zarówno z osób bardzo dobrze wyszkolonych technicznie, jak równieŝ osób posiadających konieczną wiedzę biznesową. Z reguły problemy, które kierowane są do tej grupy, wymagają bardzo wnikliwej analizy. WaŜne by w trakcie procesu korzystano z róŝnych technik pomocnych w analizie problemu. Do najczęściej stosowanych naleŝą: Ankiety eksperckie - cechą charakterystyczną tej metody jest jej prostota. Polega na zidentyfikowaniu właściwego eksperta w danej dziedzinie projektu informatycznego, np.: oprogramowaniu, którego zadaniem jest przygotowanie ankiety w oparciu o przekazane informacje. Następnie w rozmowie z szefem działu IT konsultanci posługują się gotowymi zestawami pytań. Dane otrzymane z ankiet dotyczą ryzyka związanego z harmonogramem, kosztami i wydajnością. Strona 26 z 37

27 Burza mózgów - zwana twórczą dyskusją, umoŝliwia przeprowadzenie otwartej, dynamicznej rozmowy na tematy związane z wykrytym problemem. Pozwala spojrzeć na problem w sposób nowatorski, co byłoby niemoŝliwe przy wykorzystaniu innych metod. Technice tej towarzyszy sporo emocji. Praca odbywa się w zespole. Rozwiązania które powstają w czasie spotkania od razu są utrwalane, by po spotkaniu udostępnić je upowaŝnionym osobom w firmowym Intranecie. Analiza załoŝeń - zadaniem tej techniki jest przeanalizowanie wszystkich aspektów i ich weryfikacja prowadząca do zatwierdzenia lub odrzucenia sposobu rozwiązania problemu. Takie działanie prowadzi do powszechnego zrozumienia warunków i własności projektu. Proces zarządzania problemem rozpoczyna się od identyfikacji oraz wstępnej klasyfikacji problemu. Po określeniu przyczyn wystąpienia problemu naleŝy zaproponować scenariusz postępowania zmierzający do naprawy problemu. Bardzo waŝne aby takich scenariuszy było kilka, tak by osoby odpowiedzialne za realizację podprocesu kontroli błędu mogły wybrać rozwiązanie optymalne zarówno dla strony informatycznej jak i biznesowej. Na tym etapie procesu zarządzania problemem jest wystarczająco duŝo czasu by opracować klika wariantów naprawy problemu. Po wykryciu przyczyny wystąpienia awarii zadaniem osoby odpowiedzialnej za podproces zarządzania problemem jest opracowanie dokumentacji, tak by stanowiła ona podstawę do reakcji dla pracowników Service Desk. Nie chodzi tutaj o produkowanie zbędnej dokumentacji, ale o udokumentowanie rozwiązania, z którego w przyszłości mogliby korzystać pracownicy mający bezpośredni kontakt z uŝytkownikiem. Takie działania mają na celu zwiększenie liczby rozwiązywanych przez Service Desk awarii juŝ na pierwszej linii wsparcia. Podprocesy składające się na proces zarządzania problemem przedstawiono na rysunku 3. Strona 27 z 37

28 Rysunek 3. Proces zarządzania problemem. Gdy działania w podprocesie zarządzania problemem zakończą się sukcesem rozpoznany problem zostaje przekazany do podprocesu zarządzania błędem, który ma na celu wdroŝenie opracowanych procedur. Osoby odpowiedzialne za podproces kontroli błędu zmuszone są korzystać z pomocy grupy realizującej proces zarządzania zmianą. Naprawa błędu wymaga wprowadzenia dodatkowych zmian, które muszą być wdroŝone poprawnie. Dlatego proces zarządzania problemem zaleŝy nie tylko od efektywności procesu zarządzania incydentem ale równieŝ od skuteczności procesu zarządzania zmianą. Jednak na zamknięciu błędu proces się nie kończy. Przed osobami odpowiedzialnymi za realizację procesu zarządzania problemem stoi dodatkowe zadanie: sprawdzenie naprawionych elementów. O ile w przypadku małych incydentów wystarczy telefon do uŝytkownika z zapytaniem o sposób rozwiązania, to juŝ w przypadku duŝych problemów taka forma nadzoru moŝe nie wystarczyć. Dlatego konieczny jest formalny przegląd sprawdzający załoŝone cele oraz Strona 28 z 37

29 sposób ich realizacji. Tak przeprowadzony proces pomoŝe w usystematyzowaniu procesów zasilających Bazę Wiedzy w rekordy o znanych błędach i sposobie ich rozwiązania. Działania proaktywne procesu zarządzania problemem Proces zarządzania problemem przez niektórych praktyków metodyki ITIL uwaŝany jest za przedłuŝenie procesu zarządzania incydentem. Ma on na celu nie tylko opracowanie strategii naprawy problemu, ale przede wszystkim podejmuje działania proaktywne, polegające na analizie infrastruktury informatycznej oraz raportów pochodzących z aplikacji wsparcia. Proaktywne działania zmierzające do realizacji procesu zarządzania problemem muszą mieć poparcie w danych zgromadzonych przez proces zarządzania incydentem. JeŜeli proces zarządzania incydentem będzie prowadzony bardzo chaotycznie, bez moŝliwości sprawdzenia całej historii zdarzenia, wówczas proaktywny proces zarządzania problemem nie będzie przynosił oczekiwanych rezultatów. W rzeczywistości będzie sprowadzony do koniecznego minimum, a w ostateczności całkowicie zaniknie. Działania proaktywne realizują załoŝenia ustalone w procesach zarządzania dostępnością oraz ciągłością (Proces zarządzania dostępnością) oraz (Proces zarządzania pojemnością). Nie tylko zdarzenia na które brakuje scenariuszy w Bazie Wiedzy trafiają do procesu zarządzania problemem; kieruje się tam równieŝ i te incydenty, które udało się naprawić, ale przyczyna ich wystąpienia jest nadal nieznana. Wówczas rekord dotyczący tego incydentu zostaje zamknięty w procesie zarządzania incydentem, a w jego miejsce zostaje otwarty rekord w procesie zarządzania problemem. Warto nie tylko rozwiązanie kaŝdego problemu przedstawić pracownikom Service Desku ale równieŝ opracować wstępny koszt naprawy takiego problemu oraz strat finansowych, jakie poniósł biznes z racji wystąpienia. NaleŜy takie oszacowanie przedstawić stronie biznesowej na jednym z licznych spotkań. Przedstawiony raport napewno przekona stronę biznesową do inwestycji w działania proaktywne zapobiegające wystąpieniu problemów. Tylko takie działania mogą uchronić firmę przed zwiększającą się liczbą incydentów mających negatywny wpływ na działalność biznesową, co jest równoznaczne z poprawieniem jakości świadczonych usług. Strona 29 z 37

30 CMMI Dlaczego powinno Cię to obchodzić Relacja z konferencji Kamila Dec Wprowadzenie 27 września 2006 w Warszawie odbyła się konferencja CMMI Dlaczego powinno Cię to obchodzić zorganizowana przez firmy: Software Mind i Kugler Maag CIE. Konferencja związana była z zagadnieniami Capability Maturity Model Integration, przy czym prelegenci dzielili się zarówno wiedzą teoretyczną na ten temat, jak i, co szczególnie cenne praktycznymi doświadczeniami, nie zawsze zakończonymi sukcesem, zdobytymi podczas usprawniania procesów produkcji oprogramowania w swoich firmach. Konferencję rozpoczęli: Christophe Debou z Kugler Maag CIE oraz Jay Douglass z SEI Europe, którzy wprowadzili nas w zagadnienia związane z CMMI oraz Software Process Improvement. Później wystąpili przedstawiciele takich firm, jak: Deutsche Bank, Motorola, AXA Belgium, Software Mind oraz DaimlerChrysler Financial Services opowiadając o sukcesach i poraŝkach, czyli doświadczeniach zdobytych podczas wspinania się na kolejne poziomy dojrzałości CMMI. Co ciekawe wszystkie te firmy aktualnie osiągnęły drugi i/ lub starają się osiągnąć trzeci poziom dojrzałości. Najbardziej zaawansowana jest w tym względzie Motorola, która co prawda osiągnęła poziom piąty, jednak w modelu CMM, i równieŝ stoi przed mniej lub bardziej Ŝmudną drogą przejścia na model CMMI. Dzięki temu, jak sądzę, prelegenci i uczestnicy konferencji mieli okazję osiągnąć wysoki poziom zrozumienia własnych bolączek i problemów związanych z usprawnieniem procesów produkcji oprogramowania. Dlaczego powinno Cię to obchodzić Jak mówił w swoim wystąpieniu Jay Douglass z SEI Europe, jakość produktu w duŝym stopniu zaleŝy od jakości procesu, w którym ten produkt powstaje. Dla jakości produktu bardzo istotne jest więc, aby: 1. dokładnie zdefiniować ten proces, 2. mierzyć jego efektywność, 3. ciągle szukać sposobów na jego usprawnienie. To właśnie jest podstawą Process Improvement. Capability Maturity Model Integration stanowi kompendium dobrych praktyk, które pozwalają osiągnąć cele biznesowe związane z kosztami przedsięwzięć, harmonogramami, Strona 30 z 37