TESTER.PL. Od redaktora

Wielkość: px
Rozpocząć pokaz od strony:

Download "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 (www.sqsconferences.com/de) 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 (http://www.qamt.net). 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

Tworzenie przypadków testowych

Tworzenie przypadków testowych Tworzenie przypadków testowych Prowadząca: Katarzyna Pietrzyk Agenda 1. Wprowadzenie 2. Wymagania 3. Przypadek testowy Definicja Schemat Cechy dobrego przypadku testowego 4. Techniki projektowania Czarnej

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design

Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design Case Study Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design Zadanie Naszym zadaniem było zaprojektowanie interfejsu aplikacji do sprzedaŝy ubezpieczeń

Bardziej szczegółowo

proste, migawkowe badanie IT w Twojej organizacji realizowane z trzech kluczowych perspektyw: działu IT, Twojego podstawowego biznesu oraz działu

proste, migawkowe badanie IT w Twojej organizacji realizowane z trzech kluczowych perspektyw: działu IT, Twojego podstawowego biznesu oraz działu zanim zaproponujemy konkretne rozwiązanie, poznajemy specyfikę Twojej firmy i Twoje cele biznesowe. poznajemy punkt widzenia nie tylko IT, ale przede wszystkim osób odpowiedzialnych za podstawowy biznes

Bardziej szczegółowo

Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej

Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej Wiesław Paluszyński Prezes zarządu TI Consulting Plan prezentacji Zdefiniujmy

Bardziej szczegółowo

Optymalizacja Automatycznych Testów Regresywnych

Optymalizacja Automatycznych Testów Regresywnych Optymalizacja Automatycznych Testów Regresywnych W Organizacji Transformującej do Agile Adam Marciszewski adam.marciszewski@tieto.com Agenda Kontekst projektu Typowe podejście Wyzwania Cel Założenia Opis

Bardziej szczegółowo

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu Zarządzanie ryzykiem w projektach informatycznych Marcin Krysiński marcin@krysinski.eu O czym będziemy mówić? Zarządzanie ryzykiem Co to jest ryzyko Planowanie zarządzania ryzykiem Identyfikacja czynników

Bardziej szczegółowo

Krzysztof Tomkiewicz Bydgoszcz, 26 października 2009 r.

Krzysztof Tomkiewicz Bydgoszcz, 26 października 2009 r. Usługi IT jak skutecznie z nich korzystać? Krzysztof Tomkiewicz Bydgoszcz, 26 października 2009 r. AGENDA I II III IV Model usługowy funkcjonowania IT Przykład podejścia usługowego Najlepsze praktyki w

Bardziej szczegółowo

ISO 27001 w Banku Spółdzielczym - od decyzji do realizacji

ISO 27001 w Banku Spółdzielczym - od decyzji do realizacji ISO 27001 w Banku Spółdzielczym - od decyzji do realizacji Aleksander Czarnowski AVET Information and Network Security Sp. z o.o. Agenda ISO 27001 zalety i wady Miejsce systemów bezpieczeństwa w Bankowości

Bardziej szczegółowo

Wdrażanie i eksploatacja systemów informatycznych

Wdrażanie i eksploatacja systemów informatycznych Małgorzata Plechawska-Wójcik Wdrażanie i eksploatacja systemów informatycznych Laboratorium nr 8 Eksploatacja systemu wg ITIL Wstęp ITIL (ang. Information Technology Infrastructure Library) metodyka zarządzania

Bardziej szczegółowo

Projektowanie zorientowane na uŝytkownika

Projektowanie zorientowane na uŝytkownika Uniwersytet Jagielloński Interfejsy graficzne Wykład 2 Projektowanie zorientowane na uŝytkownika Barbara Strug 2011 Hall of shame Hall of shame Model wodospad Feedback Problem z modelem waterfall Projektowanie

Bardziej szczegółowo

Katalog szkoleń certyfikowanych Testowanie Oprogramowania

Katalog szkoleń certyfikowanych Testowanie Oprogramowania Katalog szkoleń certyfikowanych Testowanie Oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

Egzamin ITIL Foundation

Egzamin ITIL Foundation Egzamin ITIL Foundation Przykładowy arkusz egzaminacyjny A, wersja 5.1 Test wielokrotnego wyboru (tylko jedna odpowiedź jest prawidłowa) Instrukcja 1. Należy udzielić odpowiedzi na wszystkie 40 pytań.

Bardziej szczegółowo

bo od managera wymaga się perfekcji

bo od managera wymaga się perfekcji bo od managera wymaga się perfekcji MODELOWANIE PROCESÓW Charakterystyka modułu Modelowanie Procesów Biznesowych (BPM) Modelowanie procesów biznesowych stanowi fundament wdroŝenia systemu zarządzania jakością

Bardziej szczegółowo

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo

Szkolenia zgodne z sylabusem ISTQB. www.cts.com.pl

Szkolenia zgodne z sylabusem ISTQB. www.cts.com.pl Szkolenia zgodne z sylabusem www.cts.com.pl DLACZEGO WARTO PRZYJŚĆ NA DO CERTYFIKATU? Aby dostarczyć klientom potrzebną jakość, konieczne jest testowanie produktów informatycznych. O największych awariach,

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

Warsztaty. podjęcie pracy/ własnej działalności jako Webmaster CMS. Oferta

Warsztaty. podjęcie pracy/ własnej działalności jako Webmaster CMS. Oferta Warsztaty podjęcie pracy/ własnej działalności jako Webmaster CMS Oferta e-mail: biuro@garg.pl, www.garg.pl 1. Wstęp Internet, to miejsce, w którym powinien znaleźć się kaŝdy przedsiębiorca. Jeśli kogoś

Bardziej szczegółowo

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa tel: 22 667 17 04, faks: 22 667 17 33

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa tel: 22 667 17 04, faks: 22 667 17 33 Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa tel: 22 667 17 04, faks: 22 667 17 33 993200/370/IN-402/2012 Warszawa, dnia 22.05.2012 r. Informacja dla

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Testy poziom po poziomie

Testy poziom po poziomie poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.

Bardziej szczegółowo

Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015

Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015 Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015 ZAPEWNIAMY BEZPIECZEŃSTWO Piotr Błoński, Warszawa, 17.03.2016 r. Program 1. Zarządzanie zmianą - zmiany w normie ISO 9001:2015 2. Zarządzanie

Bardziej szczegółowo

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE ŚcieŜki Certyfikacji Testera Karol Mioduszewski - CORRSE Kierunki rozwoju W dół, w górę czy w bok? Rozwój w dół Specjalizacja Zagłębianie się w wybrany wycinek wiedzy, np. testy wydajnościowe lub konkretne

Bardziej szczegółowo

Katalog szkoleń certyfikowanych Testowanie oprogramowania

Katalog szkoleń certyfikowanych Testowanie oprogramowania Katalog szkoleń certyfikowanych Testowanie oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Krajowy System Informatyczny SIMIK 07-13. Tymczasowe procedury zgłaszania problemów/zmian/incydentów dot. naruszenia bezpieczeństwa informacyjnego.

Krajowy System Informatyczny SIMIK 07-13. Tymczasowe procedury zgłaszania problemów/zmian/incydentów dot. naruszenia bezpieczeństwa informacyjnego. Krajowy System Informatyczny SIMIK 07-13 Tymczasowe procedury zgłaszania problemów/zmian/incydentów dot. naruszenia bezpieczeństwa informacyjnego. Zatwierdzam: Wersja 1.1. Warszawa, dnia 25 lipca 2008

Bardziej szczegółowo

Optymalizacja wybranych procesów obsługi klienta. Dzień 1.

Optymalizacja wybranych procesów obsługi klienta. Dzień 1. Optymalizacja wybranych procesów obsługi klienta w sektorze publicznym Dzień 1. Cele warsztatów Główne cele naszego warsztatu to: przygotowanie do samodzielnego optymalizowania procesów utrwalenie techniki

Bardziej szczegółowo

Warsztaty przygotowujące osoby bezrobotne do prowadzenia własnego

Warsztaty przygotowujące osoby bezrobotne do prowadzenia własnego Warsztaty przygotowujące osoby bezrobotne do prowadzenia własnego Sklepu Internetowego sprzedawca w Internecie Oferta e-mail: biuro@garg.pl, www.garg.pl 1. Wstęp Handel Internetowy zdobywa coraz większą

Bardziej szczegółowo

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów

Bardziej szczegółowo

Projekt. Prince2 PRoject. IN Controlled Environments PROCESY KOMPONENTY TECHNIKI

Projekt. Prince2 PRoject. IN Controlled Environments PROCESY KOMPONENTY TECHNIKI 4 Kilka słów o metodyce Prince2 Do czego słuŝy? 5 Kilka słów o metodyce Prince2 Skąd się wzięła? Prince2 PRoject IN Controlled Environments Metodyka zarządzania projektem, nie realizacji projektu!!! Projekty

Bardziej szczegółowo

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk dr T Bartosz Kalinowski 17 19 września 2008, Wisła IV Sympozjum Klubu Paragraf 34 1 Informacja a system zarządzania Informacja

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

Projekty IT w praktyce biznesowej

Projekty IT w praktyce biznesowej Projekty IT w praktyce biznesowej Wojciech Murzyn wojciech@murzyn.pl (501) 217 547 1 Korzyści z inwestycji w IT 10% szefów firm uważa, że inwestycje w IT przyniosły planowane, duże korzyści 10% 47% 43%

Bardziej szczegółowo

SERVICEDESK PUNKT STYKU BIZNESU Z TECHNOLOGIĄ IT

SERVICEDESK PUNKT STYKU BIZNESU Z TECHNOLOGIĄ IT Z E S Z Y T Y N A U K O W E P O L I T E C H N I K I Ł Ó D Z K I E J Nr 1091 Organizacja i Zarządzanie, z. 46 2010 TOMASZ SOBESTIAŃCZYK Politechnika Łódzka SERVICEDESK PUNKT STYKU BIZNESU Z TECHNOLOGIĄ

Bardziej szczegółowo

PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH. załącznik do ZR 154/2014 z dnia 22 grudnia 2014 roku

PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH. załącznik do ZR 154/2014 z dnia 22 grudnia 2014 roku PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH załącznik do ZR 154/2014 Spis treści I. CEL I ZAKRES OBOWIĄZYWANIA INSTRUKCJI... 3 II. DEFINICJE I SKRÓTY... 3 III.

Bardziej szczegółowo

Audyty bezpieczeństwa dla samorządów i firm. Gerard Frankowski, Zespół Bezpieczeństwa PCSS

Audyty bezpieczeństwa dla samorządów i firm. Gerard Frankowski, Zespół Bezpieczeństwa PCSS Audyty bezpieczeństwa dla samorządów i firm Gerard Frankowski, Zespół Bezpieczeństwa PCSS 1 Plan prezentacji Wprowadzenie Dlaczego korzystanie z infrastruktur teleinformatycznych jest niebezpieczne? Czy

Bardziej szczegółowo

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 4 Zbigniew Misiak (BOC IT Consulting) zbigniew.misiak@gmail.com Czym się będziemy zajmować? Powtórzenie kluczowych zagadnień Prosty test

Bardziej szczegółowo

Zapewnienie bezpieczeństwa w całym cyklu życia aplikacji (czyli dlaczego lepiej zapobiegać chorobom, niż leczyć je w zaawansowanym stadium)

Zapewnienie bezpieczeństwa w całym cyklu życia aplikacji (czyli dlaczego lepiej zapobiegać chorobom, niż leczyć je w zaawansowanym stadium) Zapewnienie bezpieczeństwa w całym cyklu życia aplikacji (czyli dlaczego lepiej zapobiegać chorobom, niż leczyć je w zaawansowanym stadium) dr inż. Jakub Botwicz CISSP, ECSA 9.10.2012 jakub.botwicz@pl.ey.com

Bardziej szczegółowo

INFORMATYKA PROJEKTY ROZWIĄZANIA OFERTA - AUDYT LEGALNOŚCI OPROGRAMOWANIA

INFORMATYKA PROJEKTY ROZWIĄZANIA OFERTA - AUDYT LEGALNOŚCI OPROGRAMOWANIA INFORMATYKA PROJEKTY ROZWIĄZANIA OFERTA - AUDYT LEGALNOŚCI OPROGRAMOWANIA Warszawa, 2010 Informacje o firmie RavNet RavNet od ponad 10 lat zajmuje się szeroko pojętą informatyczną obsługą firm. Jesteśmy

Bardziej szczegółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

Bardziej szczegółowo

Nr sprawy: BDG-II-281-17-PC/09 Warszawa dn. 29 października 2009 r.

Nr sprawy: BDG-II-281-17-PC/09 Warszawa dn. 29 października 2009 r. Nr sprawy: BDG-II-281-17-PC/09 Warszawa dn. 29 października 2009 r. Treść zapytań wraz z wyjaśnieniami do SIWZ W związku ze złoŝeniem pytań dotyczących treści specyfikacji istotnych warunków zamówienia,

Bardziej szczegółowo

Przypadki bez przypadków. Jak dobierać scenariusze testowe.

Przypadki bez przypadków. Jak dobierać scenariusze testowe. Przypadki bez przypadków. Jak dobierać scenariusze testowe. Konferencja SQAM 2008 Warszawa, 29. kwietnia Wojciech Pająk 29 kwietnia 2008 Warszawa Zagadnienia prezentacji 1. Wprowadzenie 2. Definicje przypadków

Bardziej szczegółowo

Źródła dumy zawodowej testera oprogramowania

Źródła dumy zawodowej testera oprogramowania Źródła dumy zawodowej testera oprogramowania Tom Gilb & Kai Gilb: False QA is calling your activity QA when in fact you only do testing. http://www.result-planning.com/real+qa+manifesto Nie jestem QA!

Bardziej szczegółowo

Krytyczne czynniki sukcesu w zarządzaniu projektami

Krytyczne czynniki sukcesu w zarządzaniu projektami Seweryn SPAŁEK Krytyczne czynniki sukcesu w zarządzaniu projektami MONOGRAFIA Wydawnictwo Politechniki Śląskiej Gliwice 2004 SPIS TREŚCI WPROWADZENIE 5 1. ZARZĄDZANIE PROJEKTAMI W ORGANIZACJI 13 1.1. Zarządzanie

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Zmiany i nowe wymagania w normie ISO 9001:2008

Zmiany i nowe wymagania w normie ISO 9001:2008 FORUM WYMIANY DOŚWIADCZEŃ DLA KONSULTANTÓW 19-20 listopada 2007r. Zmiany i nowe wymagania w normie ISO 9001:2008 Grzegorz Grabka Dyrektor Działu Certyfikacji Systemów, Auditor Senior TÜV CERT 1 Zmiany

Bardziej szczegółowo

Efektywne Zarządzanie IT w Przedsiębiorstwie, II edycja

Efektywne Zarządzanie IT w Przedsiębiorstwie, II edycja SZKOŁA GŁÓWNA HANDLOWA W WARSZAWIE Podyplomowe Studia Efektywne Zarządzanie IT w Przedsiębiorstwie, II edycja Spotkanie informacyjne 19.12.2006 r. Od wieku na oceanie wiedzy Szkoła Główna Handlowa w Warszawie

Bardziej szczegółowo

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec

Bardziej szczegółowo

Zarządzanie usługami informatycznymi system BITIS itsm

Zarządzanie usługami informatycznymi system BITIS itsm usługami informatycznymi system BITIS itsm dr inż. Janusz Dorożyński główny specjalista, pełnomocnik zarządu janusz.dorozynski@zeto.bydgoszcz.pl ZETO Bydgoszcz SA 45 lat aktywności na polskim rynku informatycznym

Bardziej szczegółowo

ŚCIEŻKA: Zarządzanie projektami

ŚCIEŻKA: Zarządzanie projektami ŚCIEŻKA: Zarządzanie projektami Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Kadrze menedżerskiej i kierowniczej przedsiębiorstw Kierownikom

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

Typowe błędy w analizie rynku nieruchomości przy uŝyciu metod statystycznych

Typowe błędy w analizie rynku nieruchomości przy uŝyciu metod statystycznych Typowe błędy w analizie rynku nieruchomości przy uŝyciu metod statystycznych Sebastian Kokot XXI Krajowa Konferencja Rzeczoznawców Majątkowych, Międzyzdroje 2012 Rzetelnie wykonana analiza rynku nieruchomości

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy dedykowanymi zasobami (ang. agile testers) Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania

Bardziej szczegółowo

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

Bardziej szczegółowo

Case study: Mobilny serwis WWW dla Kolporter

Case study: Mobilny serwis WWW dla Kolporter Case study: Mobilny serwis WWW dla Kolporter Sklep internetowy Kolporter.pl oferuje swoim Klientom blisko 100 000 produktów w tym: ksiąŝki, muzykę, film i gry. Kolporter postanowił stworzyć nowy kanał

Bardziej szczegółowo

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010. Autor: Jolanta Łabędzka-Benisz. www.omec.

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010. Autor: Jolanta Łabędzka-Benisz. www.omec. PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010 Autor: Jolanta Łabędzka-Benisz www.omec.pl W A R S Z A W A R Z E S Z Ó W W R O C Ł A W 1 Agenda Wstęp

Bardziej szczegółowo

Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK

Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK Opis Szkolenie realizowane w ramach: Oferowane zajęcia umożliwiają uczestnikom poznanie najlepszych metod i narzędzi stosowanych

Bardziej szczegółowo

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Jak teoria pomaga w codziennej praktyce zapewniania i kontroli jakości Piotr Ślęzak Stowarzyszenie Jakości Systemów Informatycznych

Bardziej szczegółowo

Raport Coachowie Europa i Polska

Raport Coachowie Europa i Polska Raport Coachowie Europa i Polska COACHING W związku z róŝnymi definicjami i róŝnym rozuminiem coachingu, obliczenie zapotrzebowania na coachów i adekwatny do tego potencjał szkół coachingu został oparty

Bardziej szczegółowo

NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Jak usprawnić pracę w zespole IT? Wykorzystanie narzędzi do pracy grupowej na przykładzie zespołu Polska.pl Agnieszka Kukałowicz-Kolaszyńska, Starszy Specjalista IT

Bardziej szczegółowo

KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA PROJEKTAMI W PRZEDSIĘBIORSTWIE

KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA PROJEKTAMI W PRZEDSIĘBIORSTWIE KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA PROJEKTAMI W PRZEDSIĘBIORSTWIE Seweryn SPAŁEK Streszczenie: Zarządzanie projektami staje się coraz bardziej powszechne w przedsiębiorstwach produkcyjnych, handlowych

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

STUDIA PODYPLOMOWE Zarządzanie Projektami

STUDIA PODYPLOMOWE Zarządzanie Projektami STUDIA PODYPLOMOWE Zarządzanie Projektami (Program studiów) Opracowanie: dr inż. Jacek Jakieła Program studiów Zarządzanie projektami 2 CEL STUDIÓW, ADRESAT I PROFIL ABSOLWENTA Studia podyplomowe Zarządzanie

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO, WSPARCIA UśYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO, WSPARCIA UśYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO, WSPARCIA UśYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ I. Serwis gwarancyjny oraz wsparcie uŝytkowników Help Desk 1. Wykonawca zobowiązany

Bardziej szczegółowo

Jerzy Nawrocki, Inżynieria oprogramowania II

Jerzy Nawrocki, Inżynieria oprogramowania II Jerzy Nawrocki, Jerzy Nawrocki Instytut Informatyki Politechnika Poznańska Etap przedprojektowy Etap przedprojektowy (2) Piąta zasada zwinności Cykl życia wg XPrince Osoby i interakcje O K Działające oprogr.

Bardziej szczegółowo

I. O P I S S Z K O L E N I A

I. O P I S S Z K O L E N I A Sektorowy Program Operacyjny Rozwój Zasobów Ludzkich Priorytet 2 Rozwój społeczeństwa opartego na wiedzy Działanie 2.3 Rozwój kadr nowoczesnej gospodarki I. O P I S S Z K O L E N I A Tytuł szkolenia Metodyka

Bardziej szczegółowo

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów

Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów Eksploracja danych Piotr Lipiński Informacje ogólne Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów UWAGA: prezentacja to nie

Bardziej szczegółowo

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager.

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. Na szkolenie zapraszamy: testerów kierowników działów testowych analityków systemowych

Bardziej szczegółowo

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 Odpowiada na pytania: Jaka część projektów IT kończy się w Polsce sukcesem? Jak wiele projektów sponsorowanych jest przez instytucje publiczne? Czy kończą się

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

Bardziej szczegółowo

I. 1) NAZWA I ADRES: Instytut Techniki Budowlanej, ul. Filtrowa 1, 00-611 Warszawa, woj.

I. 1) NAZWA I ADRES: Instytut Techniki Budowlanej, ul. Filtrowa 1, 00-611 Warszawa, woj. Warszawa: Usługa doradcza w zakresie opracowania i wdroŝenia zintegrowanego systemu za-rządzania w Instytucie Techniki Budowlanej w ramach realizacji projektu - Rozwój in-frastruktury informatycznej -

Bardziej szczegółowo

Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp

Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp Prezentujemy Państwu propozycję modułu aplikacji internetowej słuŝącej do prezentacji zaplanowanych wizyt klienta

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

Ryzyko w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012r. w sprawie Krajowych Ram Interoperacyjności ( )

Ryzyko w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012r. w sprawie Krajowych Ram Interoperacyjności ( ) Ryzyko w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012r. w sprawie Krajowych Ram Interoperacyjności ( ) Dr inż. Elżbieta Andrukiewicz Przewodnicząca KT nr 182 Ochrona informacji w systemach teleinformatycznych

Bardziej szczegółowo

Kiedy IT staje się biznesem - opcja for Service Provider platformy Tivoli's Process Automation Engine

Kiedy IT staje się biznesem - opcja for Service Provider platformy Tivoli's Process Automation Engine Kiedy IT staje się biznesem - opcja for Service Provider platformy Tivoli's Process Automation Engine Gerard Lipiec 2010 IBM Corporation Agenda Perspektywa biznesowa Usługi IT Model biznesowy Service Provider

Bardziej szczegółowo

SZKOLENIE BADANIE SATYSFAKCJI KLIENTA I ZARZĄDZANIE SATYSFAKCJĄ KLIENTA W PRZEDSIĘBIORSTWIE

SZKOLENIE BADANIE SATYSFAKCJI KLIENTA I ZARZĄDZANIE SATYSFAKCJĄ KLIENTA W PRZEDSIĘBIORSTWIE SZKOLENIE ROZWIĄZANIA W ZAKRESIE ROZWOJU KAPITAŁU LUDZKIEGO PRZEDSIĘBIORSTW BADANIE SATYSFAKCJI KLIENTA I ZARZĄDZANIE SATYSFAKCJĄ KLIENTA W WPROWADZENIE W dobie silnej konkurencji oraz wzrastającej świadomości

Bardziej szczegółowo

Jakość przed jakością

Jakość przed jakością Jakość przed jakością Oprogramowanie naprawdę przydatne (2) Robert Ganowski II Krajowa Konferencja Jakości Systemów Informatycznych, Warszawa, 21-22 czerwca 2005 r. 1 Teoria prawdy*

Bardziej szczegółowo

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

Bardziej szczegółowo

Certyfikowane szkolenia testerzy.pl to uznana ścieżka szkoleniowa ISTQB dla testerów.

Certyfikowane szkolenia testerzy.pl to uznana ścieżka szkoleniowa ISTQB dla testerów. Szanowni Państwo Certyfikowane szkolenia testerzy.pl to uznana ścieżka szkoleniowa ISTQB dla testerów. Dostarczamy pełny zakres usług w procesie odpowiedniego przygotowania uczestników do egzaminów. Dostarczamy

Bardziej szczegółowo

Techniki (automatyzacji) projektowania testów. Adam Roman WarszawQA, 24 II 2016

Techniki (automatyzacji) projektowania testów. Adam Roman WarszawQA, 24 II 2016 Techniki (automatyzacji) projektowania testów Adam Roman WarszawQA, 24 II 2016 Prelegent Quality Assurance R&D Lead, Rivet Group Adiunkt w Instytucie Informatyki i Matematyki Komputerowej UJ Członek Stowarzyszenia

Bardziej szczegółowo

Firmowe Call Center krok po kroku

Firmowe Call Center krok po kroku OFERTA SZKOLENIOWA Firmowe Call Center krok po kroku TELEAKADEMIA to profesjonalne centrum szkoleniowe mające swoją siedzibę w Pomorskim Parku Naukowo-Technologicznym w Gdyni. TELEAKADEMIA realizuje szkolenia

Bardziej szczegółowo

ANALIZA ANKIET SATYSFAKCJI KLIENTA

ANALIZA ANKIET SATYSFAKCJI KLIENTA Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego ANALIZA ANKIET SATYSFAKCJI KLIENTA OCENIAJĄCYCH JAKOŚĆ OBSŁUGI KLIENTA ORAZ STOPIEŃ ZADOWOLENIA Z

Bardziej szczegółowo

Zarządzanie projektów

Zarządzanie projektów Zarządzanie projektów Część 3 Etapy projektów Rozpoczęcie projektu Planowanie projektu Współpraca z zarządem Tworzenie budżetu Organizacja zespołu projektowego Tworzenie planu projektu Optymalizacja projektu

Bardziej szczegółowo

HP HW/SW + HP Proactive Care = Duet doskonały!!!

HP HW/SW + HP Proactive Care = Duet doskonały!!! HP HW/SW + HP Proactive Care = Duet doskonały!!! Copyright 2012 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. Agenda HP Proactive

Bardziej szczegółowo

Oprogramowanie dla biznesu Numer 11 (69) Listopad 2009 JAK SZYBKO I SKUTECZNIE ZAMKNĄĆ ROK?

Oprogramowanie dla biznesu Numer 11 (69) Listopad 2009 JAK SZYBKO I SKUTECZNIE ZAMKNĄĆ ROK? Oprogramowanie dla biznesu Numer 11 (69) Listopad 2009 JAK SZYBKO I SKUTECZNIE ZAMKNĄĆ ROK? CZY TO MOśLIWE, ABY PRZEZ PROCES ZAMKNIĘCIA ROKU W DUśEJ FIRMIE LEASINGOWEJ PRZEJŚĆ SZYBKO I BEZBOLEŚNIE? MY

Bardziej szczegółowo

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie oprogramowania w środowisku IBM Rational Software Architect Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze

Bardziej szczegółowo

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Wdrożenie systemu planowania zasobów przedsiębiorstwa pomimo wielu korzyści często też wiąże się

Bardziej szczegółowo

Udane wdrożenie systemu IT

Udane wdrożenie systemu IT Udane wdrożenie systemu IT Maciej Guzek CMMS Department Marketing & Sales Manager mguzek@aiut.com.pl To nie takie proste Czego klient potrzebował Co klient zamówił Co zrozumiał analityk Co opisywał projekt

Bardziej szczegółowo

XII. Warunek wielokrotnego wyboru switch... case

XII. Warunek wielokrotnego wyboru switch... case XII. Warunek wielokrotnego wyboru switch... case 12.1. Gdy mamy więcej niŝ dwie moŝliwości Do tej pory poznaliśmy warunek if... else... Po co nam kolejny? Trudno powiedzieć, ale na pewno nie po to, Ŝeby

Bardziej szczegółowo

EGZAMIN MATURALNY 2012 JĘZYK ANGIELSKI

EGZAMIN MATURALNY 2012 JĘZYK ANGIELSKI Centralna Komisja Egzaminacyjna EGZAMIN MATURALNY 2012 JĘZYK ANGIELSKI POZIOM PODSTAWOWY Kryteria oceniania odpowiedzi SIERPIEŃ 2012 ZADANIA ZAMKNIĘTE Zadanie 1. Egzamin maturalny z języka angielskiego

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

Idealna strona internetowa dla Twojej firmy

Idealna strona internetowa dla Twojej firmy Katowice, 25.11.2010 r. Idealna strona internetowa dla Twojej firmy Warsztaty prowadzenie Zofia Oslislo 1 Czy potrzebuję (nowej) strony internetowej? mogę zwiększyć sprzedaż, gdy pozwolę klientom kupować

Bardziej szczegółowo

Dlaczego outsourcing informatyczny? Jakie korzyści zapewnia outsourcing informatyczny? Pełny czy częściowy?

Dlaczego outsourcing informatyczny? Jakie korzyści zapewnia outsourcing informatyczny? Pełny czy częściowy? Dlaczego outsourcing informatyczny? Przeciętny informatyk firmowy musi skupić w sobie umiejętności i specjalizacje z wielu dziedzin informatyki. Równocześnie musi być administratorem, specjalistą od sieci

Bardziej szczegółowo

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

Launch. przygotowanie i wprowadzanie nowych produktów na rynek Z przyjemnością odpowiemy na wszystkie pytania. Prosimy o kontakt: e-mail: kontakt@mr-db.pl tel. +48 606 356 999 www.mr-db.pl MRDB Szkolenie otwarte: Launch przygotowanie i wprowadzanie nowych produktów

Bardziej szczegółowo