specyfika pracy projektowanie, wykonywanie i utrzymywanie testów podejście i metodyka realizacji zadań.

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

Download "specyfika pracy projektowanie, wykonywanie i utrzymywanie testów podejście i metodyka realizacji zadań."

Transkrypt

1 Testowanie określane jest jako proces sprawdzania oprogramowania w celu zweryfikowania, czy spełnia ono określone wymagania. Jest to również działanie zmierzające do wykrywania błędów. Zgodnie z tą definicją, testowanie ma na celu wspomóc udoskonalanie produktu informatycznego. Co jednak dzieje się w przypadku, gdy sam proces testowania jest daleki od doskonałości i występują w nim błędy? Jak przekłada się to na jakość pracy i wyniki testów? W praktyce okazuje się, że bardzo łatwo jest popełnić błędy podczas organizacji lub samego wykonywania testów. Niektóre z owych błędów pojawiają się tak często, są powtarzane tak wiele razy przez różnych ludzi, że można określić je mianem klasycznych. Błędy popełniane przez testerów najczęściej wiążą się z następującymi kwestiami: rola i cel testowania komu ma służyć testowanie i jak je wykonywać, jakie cele stawiać przed testami; planowanie testowania organizacja pracy zespołu testowego, wybór technik, metod i podstaw (test basis); kwestie personalne kto powinien, a kto nie, testować oprogramowanie? Cechy osobowości, umiejętności i predyspozycje osób wykonujących prace związane z QA; specyfika pracy projektowanie, wykonywanie i utrzymywanie testów podejście i metodyka realizacji zadań. Niniejszy artykuł przedstawia subiektywną listę 10 najczęściej popełnianych przez testerów błędów, prowadzących do spadku efektywności procesu testowego, otrzymywania nieprawdziwych lub mylących rezultatów testów oraz pojawiania się sytuacji konfliktowych i niepewności w projekcie. Podejmując się organizacji i planowania procesu testowego, należy odpowiedzieć w pierwszej kolejności na pytanie jaka ma być rola i cel naszego procesu? Komu testowanie ma służyć i jak je wykonywać? W wielu firmach informatycznych pokutuje błędne przekonanie, że do testowania nadaje się każdy nie jest wszak niczym szczególnie trudnym sprawdzenie, czy oprogramowanie działa w taki sposób, jak to opisuje dokumentacja (specyfikacja). Tymczasem jest wręcz odwrotnie nie każdy ma predyspozycje do tego, aby być dobrym testerem. Dobry tester zaś to taki, który nie tylko potrafi zweryfikować poprawność oprogramowania z projektem, ale i znaleźć błędy wynikające z niewłaściwej specyfikacji (np. niespójnych wymagań) czy wręcz braku specyfikacji (brak opisu fragmentu systemu). Dobry tester powinien być mądrzejszy zarówno od programisty jako, że ma znaleźć błędy przeoczone podczas implementacji systemu jak i od analityka biznesowego (projektanta) żeby, gdzie trzeba udowodnić, że analityk pomylił się dokumentując wymagania i projektując aplikację. Często popełnianym błędem jest wykonywanie testów w sposób powierzchowny i niedo- 1

2 kładny. Jest to szczególnie widoczne w przypadku testów opartych na specyfikacji funkcjonalnej lub innej dokumentacji wymagań. Niekiedy testerzy wychodzą z założenia, iż sprawdzą tylko to, co jest wyraźnie udokumentowane, bez wgłębiania się w szczegóły i wyszukiwania luk czy niespójności w opisie. Jeśli dokumentacja nie precyzuje wszystkich możliwych ścieżek przebiegu procesu, sprawdzą tylko te, które opisano przykładowo, jeśli specyfikacja nie obejmuje walidacji danych wejściowych, a dotyczy tylko scenariuszy pozytywnych, tester sprawdzi tylko te pozytywne. Nie przetestuje wprowadzania danych niewłaściwego formatu, błędnych z punktu widzenia biznesowego (np. wykonywanie transferów pieniężnych na kwotę większą niż dostępna na koncie testowym), nie sprawdzi zależności między polami. Dobry tester to taki, który działa: metodycznie i systematycznie; dyplomatycznie ale i stanowczo w razie potrzeby, aby udowodnić swoje racje; z dużą dozą ostrożności i sceptycyzmu, szczególnie w przypadku wszelkiego typu założeń, i chce widzieć konkretne dowody działania danej funkcji. Tester powinien też: mieć szczególny zmysł obserwacji i zauważania szczegółów; charakteryzować się znakomitymi umiejętnościami werbalnymi i komunikacyjnymi a to w celu informowania innych członków zespołu projektowego o znalezionych problemach i wyjaśniania istoty problemu w sposób jasny i jednoznaczny. Nawet najbardziej dokładny i spostrzegawczy tester z dogłębną znajomością testowanej aplikacji nie zdziała wiele, jeśli nie będzie w stanie przekazać swoich spostrzeżeń i uwag; wyczuwać sytuacje, czy funkcje aplikacji, które mogą nie być zrozumiałe dla innych (tj. programistów) i gdzie wręcz należy spodziewać się błędów; tester może też przewidywać pojawianie się problemów, opierając się na swoim dotychczasowym doświadczeniu; być ciekawy (-ski) i eksperymentować próbować rozmaitych kombinacji działań i scenariuszy, aby zobaczyć co się stanie. Osoba, której głównym dążeniem jest jedynie szybkie wykonywanie powierzonych jej zadań od do, nie nadaje się na testera ponieważ zrealizuje w 100% swoją pracę, ale nie pomoże aktywnie ulepszyć aplikacji. Dość często zdarza się, że dokumentacja projektowa, stanowiąca podstawę do testowania, nie jest najlepszej jakości. Funkcjonalność nie jest opisana wystarczająco dokładnie, nie obejmuje wszystkich możliwych przebiegów procesu, specyfikacja nie uwzględnia opisów danych lub wyjątków. Jak w takiej sytuacji zaplanować i realizować testy? Uboga dokumentacja analityczna (specyfikacja) nie pomaga w wystarczającym zrozumieniu działania aplikacji. Tester przygotowujący się do pracy często musi domyślać się, jak aplikacja ma działać i interpretuje funkcjonalność według własnego rozumienia. Czasami zdarza się też tak, że tester nie potrafi wczuć się w rolę użytkownika systemu i nie wyobraża sobie celu działania aplikacji. Nie potrafi odtworzyć scenariuszy użytkowania systemu, ponieważ nie rozumie, po co ów system istnieje. W takich przypadkach nie da się przecenić doświadczenia i wiedzy w danym obszarze przykładowo, testerzy posiadający szeroką wiedzę z zakresu finansów czy bankowości, mają doskonałe wyniki pod względem efektywności testowania i wykrywania krytycznych błędów w systemach produkowanych dla tych właśnie branż. Programiści pytani o najbardziej irytujące zwroty w raportach błędów często wymieniają następujące: dokumentacja sugeruje; wydaje się, że; prawdopodobnie; przypuszczalnie. Takie sformułowania skutecznie odstraszają programistów od rozpoczynania prac nad danym błędem. Dlaczego? Ponieważ wskazują, że sam tester nie jest pewien, czy opisuje błąd, a w takim wypadku nie warto się owym zgłoszeniem zajmować. 2

3 Dość często praktykowanym zwyczajem jest odkładanie zgłaszania błędów na później. Niektórzy testerzy organizują sobie pracę w taki sposób, że realizują w całości pewien etap testów, notują znalezione przypadki, a dopiero po zakończeniu cyklu raportują wyniki w systemie śledzenia błędów. Przykładem niech będzie następująca organizacja testów (rysunek 1). Jak widać na schemacie, zgłaszanie błędów rozpoczyna się dopiero po czwartym dniu realizacji testów. W tym czasie cały zespół deweloperski jest bezczynny natomiast piątego dnia zaczynają napływać zgłoszenia błędów od wszystkich testerów. Na naprawę owych błędów programiści mają 4 dni wliczając w to analizę i reprodukcję problemu, implementację i przetestowanie poprawki oraz zatwierdzenie kodu w przygotowaniu do nowej wersji systemu. Nie pozostaje więc zbyt dużo czasu na efektywne zaplanowanie prac i przydział zadań deweloperom. W przypadku otrzymania dużej liczby zgłoszeń błędów, pojawia się ryzyko niedotrzymania terminu i opóźnienia przygotowania następnej, poprawionej, wersji systemu. Organizacja testów w ten sposób nie jest ani efektywna, ani praktyczna w pierwszym tygodniu programiści są bezczynni, w drugim testerzy. Gdyby testerzy zgłaszali problem bezpośrednio po ich znalezieniu, umożliwiliby programistom natychmiastowe podjęcie prac naprawczych i tym samym oszczędzenie czasu. Dodatkowo programiści mogliby w każdej chwili poprosić testerów o zaprezentowanie sposobu reprodukcji błędu ponieważ ci ostatni byliby akurat w trakcie weryfikacji systemu. Z praktyki wiem, że odkładanie zgłaszania błędów jest samo w sobie jednym z największych błędów. Z jednej strony, przez połowę czasu część zespołu projektowego jest niemal bezczynna, z drugiej ani programiści, ani testerzy nie współpracują ze sobą, ponieważ ich cykle pracy mijają się w czasie. Podczas gdy zespół testerów pracował, programiści wykonywali swoje zadania np. rozbudowywanie funkcjonalności czy implementację nowych modułów nie interesując się kondycją aplikacji poddanej testom. Natomiast po ukończeniu testowania role się odwróciły zespół QA zakończył prace związane z wykonywaniem przypadków testowych i podjął inne, dotyczące głównie aktualizacji i dodawania scenariuszy dla następnego cyklu testów. W tym czasie nie mogli, ani nie wykazywali chęci powracania do sprawdzonej już wersji systemu celem ponownej reprodukcji błędu, o którą prosił zdezorientowany programista. To jeden z najbardziej irytujących nawyków testerów. Błędy, które w rzeczywistości nie są błędami, z reguły dotyczą: braku wiedzy testera odnośnie funkcjonalności; 3

4 braku wiedzy technicznej; niewłaściwego zarządzania zmianami. Czasami tester nie zrozumie do końca logiki aplikacji, nie orientuje się zbyt dobrze w regułach biznesowych lub nie ma wystarczającego doświadczenia i każdą swoją wątpliwość zgłasza jako błąd. Jeśli na przykład tester nie zna reguł obowiązujących w bankowości i procedur instytucji, której oprogramowanie testuje, może traktować jako błąd sytuacje całkowicie poprawne z punktu widzenia biznesu. Innego rodzaju problemem jest zgłaszanie zmian jako błędów. Źródła takiej sytuacji są dwa: zgłaszanie zmian na życzenie klienta; zgłaszanie zmian jako inicjatywa własna testera - w celu udoskonalenia aplikacji lub poprawienia niedoskonałej dokumentacji analitycznej. Czasami kierownictwo projektu godzi się na praktykę zgłaszania zmian w systemie śledzenia błędów pod odpowiednią kategorią (CR). Z reguły nie jest to jednak właściwa metoda ponieważ po pierwsze psuje statystyki błędów i może dawać złudzenie, że jest ich o wiele więcej, niż w rzeczywistości; po drugie zaś, każda zmiana powinna być zgłaszana jako Change Request i poddana procesowi zarządzania zmianami. Zarządzanie zmianami umożliwia analizę wpływu zmiany na dotychczasowy system, pozwala zaplanować wdrożenie zasoby, terminy, koszty w optymalny sposób. Ponadto należy pamiętać, że każda zmiana systemu wymaga akceptacji kierownictwa projektu i biznesu jako że ingeruje w zaakceptowany już projekt oprogramowania. Nie wystarcza więc fakt, iż np.klient, czy też jakikolwiek inny członek projektu, zgłosi prośbę o zmianę. Konieczna jest również analiza, akceptacja i zaplanowanie wdrożenia i weryfikacji zmiany a najlepiej dokonać tego formalną ścieżką procedury zgłaszania zmian. Zgłaszanie zmian jako zwykłych błędów jest jedną z praktyk najbardziej irytującą programistów z tej prostej przyczyny, iż implementacja zrealizowana przez nich jest zgodna z dokumentacją systemu, jakiekolwiek więc zmiany i poprawki do dokumentacji powinny być komunikowane analitykom twórcom dokumentacji. Zdarza się, iż tester interpretuje specyfikację systemu według własnego rozumienia i zgłasza błędy tam, gdzie ich nie ma. Sytuacja taka ma miejsce szczególnie w przypadku, gdy dokumentacja jest na tyle niedokładna i niejednoznaczna, że dopuszcza wiele możliwości rozwiązań. Przykład dokumentacja opisuje możliwość dodawania, edycji i usuwania rekordu z tabeli. Niektórych rekordów (np. aktywnych kont użytkownika) nie można usuwać. Dokumentacja nie mówi jednak nic o tym, że dla takich rekordów nie powinna być dostępna opcja usuwa- 4

5 nia walidacja odbywa się już po próbie wykasowania, za pomocą komunikatu błędu. Tester zakłada, że oczywiste jest zablokowanie możliwości usuwania takich pozycji (czyli np. brak przycisku usuń w tabeli) i zgłasza odpowiedni błąd. Programista odrzuca błąd, gdyż implementacja jest zgodna z wymaganiami nie ma zapisu mówiącego o tym, że dla określonych danych nie powinno być opcji usuwania. Testerzy próbują też ulepszać aplikację i wprowadzać własne poprawki tam, gdzie wydają się im one konieczne. O ile działania takie mają sens i są wysoce wskazane na etapie przeglądu dokumentacji, o tyle mogą wprowadzać niepotrzebne zamieszanie już po akceptacji i podpisaniu specyfikacji. Na etapie implementacji i testowania, każda, najwet najmniejsza zmiana kodu mająca na celu poprawienie wyglądu aplikacji, może mieć negatywny wpływ na stabilność i niezawodność systemu. Należy pamiętać o tym, iż nigdy nie da się wyeliminować ryzyka regresji i pojawienia się nowych błędów. Innego rodzaju kwestią jest interpretacja wyników testów. Zdarzają się sytuacje, w którch tester zgłasza błąd, ponieważ według niego rezultat wykonania procedury testowej powinien różnić się od obecnego. Przykład w przypadku błędu walidacji danych wejściowych system wyświetla komunikaty informujące o rodzaju nieprawidłowości. Komunikaty wyświetlane są w górnej części ekranu aż do momentu, w którym użytkownik systemu poda prawidłowe dane. Tester zgłasza błąd polegający na tym, że nie da się zamknąć wiadomości o błędzie klikając na znak X, będący pierwszym znakiem w każdym komunikacie. W jego opinii, możliwość zamknięcia błędu usprawniłaby działanie aplikacji w znaczący sposób mimo, że działanie takie jest standardowym sposobem walidacji danych w danej technologii i nie może być zmienione. Najbardziej lakoniczny opis błędu, z jakim się spotkałam to: this button doesn't work. Wyrażenie to opisywało wszystko lokalizację błędu, procedurę odtworzenia, etc. Dla zgłaszającego problem był oczywisty, ponieważ widział ów button na ekranie przed oczyma i ewidentnie mógł stwierdzić błędne działanie. Odbierający to zgłoszenie nie był już taki pewien, o co chodzi brakowało opisu modułu i strony w aplikacji, na której miał być umiejscowiony przycisk, nie wyjaśniono, w jaki sposób przycisk funkcjonuje obecnie, a jak powinien zgodnie ze specyfikacją. Proste stwierdzenie nie działa miało wyjaśniać wszystko. Opisywany przypadek jest jednym z najbardziej drastycznych, lecz doskonale wyjaśnia, dlaczego zgłaszanie błędów z odpowiednio dokładnym opisem jest tak istotne. W mojej opinii, brak wystarczającej informacji przy zgłaszaniu błędów jest jednym z najważniejszych problemów występujących w procesie testowania. Nie tylko drastycznie zmniejsza efektywność testowania i wydłuża proces naprawiania błędu, ale i w wyraźny sposób wpływa na pogorszenie atmosfery panującej pomiędzy zespołami testerów a deweloperów. nazwa (tytuł) błędu jest mylący, nie dotyczy problemu bezpośrednio lub wskazuje na wystąpienie problemu w zupełnie innej części aplikacji. Tytuł nie mówi więc, gdzie jest błąd i czego ogólnie dotyczy, a powinien dawać pewien pogląd na istotę sprawy. Niektórzy testerzy praktykują zasadę umieszczania w tytule błędu jedynie nazwy strony lub modułu, w którym znaleziono problem. Tym sposobem w systemie śledzenia błędów może pojawić się kilkadziesiąt zgłoszeń o tej samej nazwie, a każdy będzie dotyczył czego innego. Jest to nie tylko mylące i dezorientuje programistów, ale i innych członków projektu w tym i testerów, którzy będą zmuszeni za każdym razem czytać szczegóły zgłoszenia, aby przypomnieć sobie, o co chodziło w danym przypadku; brak opisu, jak zreprodukować problem. Testerzy nie dostarczają procedury (kroków) użytych do uzyskania błędu, lub opisana procedura nie działa np. nie zawiera danych wejściowych, niezbędnych do reprodukcji problemu (z innymi danymi scenariusz testowy może działać prawidłowo); brak wyjaśnienia, jaki jest problem. Opis 5

6 błędu często zawiera sekwencję kroków oraz rezultat ich wykonania, bez oczekiwanego rezulatu. Czasem opis błędu przedstawia tylko kroki bez określenia, w którym momencie wystąpił problem, na czym polegał i dlaczego jest to błąd w jaki sposób system powinien się zachować; niewłaściwe i nieracjonalne ustalanie priorytetu błędu. Dla niektórych testerów każdy problem ma najwyższy priorytet niezależnie od tego, czy jest to kwestia błędu w działaniu krytycznej ścieżki, czy literówka w nazwie pola. Prawidłowe określanie priorytetów jest dość istotną kwestią, jako że większość team leaderów zespołów programistycznych planuje implementację poprawek, kierując się właśnie priorytetami błędów (wysokie priorytety rozwiązywane są w pierwszej kolejności). Innego rodzaju problemem związanym z nadawaniem priorytetów jest pomniejszanie wagi problemu czasami testerzy ulegają presji; brak określenia wersji systemu, w której znaleziono błąd. Bez tej informacji zgłoszenie nie powinno być w ogóle przyjmowane, ponieważ nie daje żadnego punktu odniesienia, która z wersji kodu zawiera błąd. Nie wszystkie błędy pochodzą od testerów niektóre zgłaszają sami klienci (użytkownicy systemu). W większości przypadków takie zgłoszenia opisane są nie dość dokładnie, by umożliwić programistom zrozumienie problemu i opracowanie poprawki. Użytkownik nie ma ani odpowiedniego przygotowania testerskiego, ani wiedzy pozwalającej odpisywać problemy tak jak zawodowy tester. Nie powinno się też tego od niego wymagać jednym z obowiązków testerów producenta oprogramowania jest wspieranie rozwiązywania problemów zgłoszonych przez klienta poprzez analizę takich zgłoszeń, reprodukowanie ich w środowisku testowym i dostarczanie programistom dokładnego opisu i procedury odtworzenia błędu. Tester powinien też przyjąć do wiadomości dwa podstawowe fakty związane z otrzymaniem zgłoszenia od klienta: Obszar aplikacji działa nieprawidłowo. Wiadomo, iż błędy mają tendencję do występowania grupami. Jeśli w danym module systemu pojawia się problem, istnieje duże prawdopodobieństwo, że błędów jest więcej. Tester powinien dokładnie sprawdzić moduł, by wykluczyć lub znaleźć pozostałe problemy. Aplikacja nie została wystarczająco przetestowana. Błąd znaleziony dopiero przez klienta to ostatnia rzecz, jakiej może sobie życzyć producent oprogramowania, gdyż jednoznacznie świadczy o niskiej efektywności testów wewnętrznych. Pojawia się pytanie, jakim sposobem testerzy nie znaleźli problemu wcześniej, skoro jest na tyle widoczny, że zauważył go klient? Odpowiedź jest prosta ponieważ testy wykonano nie dość dokładnie. Dobrą praktyką jest przetestowanie poprawki przed udostępnieniem jej na produkcji. Pozwala to zminimalizować ryzyko, że owa poprawka nie zadziała lub wywoła błędy regresji. Ewentualne awarie wywołane zmianą w kodzie mogą być znalezione i naprawione przed wydaniem klientowi nowej wersji systemu. Testowanie zbyt często rozumiane jest jako sprawdzenie, czy produkt informatyczny działa tak, jak powinien działać, a nie czy nie robi czegoś, czego w żadnym wypadku nie powinien. Zbyt często zdarza się podejście polegające na wykonywaniu jedynie testów pozytywnych czyli sprawdzania, czy aplikacja daje oczekiwane wyniki w przypadku wykonywania oczekiwanych i przewidzianych czynności. Tester może wychodzić z założenia, że skoro aplikację zaprojektowano do realizowania pewnych ściśle określonych zadań, należy sprawdzić tylko ścieżki realizujące owe zadania i nic ponadto ponieważ użytkownik będzie używał systemu zgodnie z przeznaczeniem. Tymczasem bardzo często jakakolwiek próba wykonania czynności nieprzewidzianej w specyfikacji wymagań kończy się błędem oprogramowania. Typowe zaniedbania to brak testów dla: niepoprawnych danych wejściowych (brak wymaganych informacji, niewłaściwy format danych np. wartość string w polu numerycznym, zakres danych, dane niepoprawne z punktu widzenia biznesowego, np. podanie kwoty operacji większej niż dostępny limit itp.); przerwań standardowego przebiegu procesu (np. wywołanie awarii w trakcie wykonywania operacji, anulowanie transakcji); operacji na bazie danych np. sprawdzenie, czy zmiana dokonana w jednym rekordzie ma wpływ na inne rekordy; czy dodanie rekordu nie usuwa przypadkiem innego itp.; podobnych lub wzajemnie zależnych operacji wykonywanych równolegle przez operatorów systemu, np. jednoczesne edytowanie tych samych danych przez różne osoby; prób używania urządzeń niekompatybilnych z systemem (np. innych modeli drukarek niż zalecane) lub wywoływania sztucznych awarii podczas używania urządzeń. Innego rodzaju problemem jest brak planu testów podziału testów na mniej i bardziej ważne, ustalenia porządku i priorytetów zadań. Zdarza się, iż testerzy sprawdzają funk- 6

7 cjonalności po kolei, bez uwzględnienia krytyczności i ważności poszczególnych funkcji. Wyniki takich praktyk to: brak informacji o rzeczywistej kondycji aplikacji które pozwalają ocenić wyniki testów ścieżek krytycznych; wysokie prawdopodobieństwo niedotrzymania terminów i powstawania opóźnień ponieważ taka metoda prowadzenia testów nie pozwala znaleźć błędów w krytycznych funkcjach czy procesach aplikacji na względnie wczesnym etapie. Dokumentacja, czy to specyfikacja funkcjonalna, model danych, dokumentacja przypadków użycia, czy przepływ procesu, jest produktem procesu wytwarzania oprogramowania i w związku z tym powinna podlegać testowaniu (czy też przeglądowi) na podobnych zasadach, jak produkowany system informatyczny. Analitycy biznesowi również popełniają pomyłki, skutkiem czego pisana przez nich dokumentacja może zawierać błędy i luki. Testerzy często zakładają, iż specyfikacja jest jedyną wyrocznią i podstawą procesu testowania i jej zawartość nie podlega dyskusji. Ewentualne niejasności i luki w opisie są pomijane, a testy przeprowadzane według własnego uznania i rozumienia testera. Dobry proces testowy zakłada przegląd i poprawę dokumentacji projektowej. Produkty każdej iteracji analizy biznesowej powinny być poddane kontroli zarówno poprzez samych analityków, jak i zespół QA. Wyniki przeglądu przekazane analitykom często umożliwiają wykrycie i szybką poprawę błędów, które w przeciwnym wypadku mogą skutkować implementacją funkcji niepoprawnych z biznesowego punktu widzenia. Często powtarzaną i prawdziwą opinią jest, iż błąd w wymaganiach (które są reprezentowane przez dokumentację) kosztuje więcej w miarę postępu projektu. Naturalne jest więc stwierdzenie, że im szybciej odkryje się i naprawi takie błędy, tym lepiej i taniej. Przeszkodą we wdrożeniu takiego podejścia jest często nastawienie samych analityków i testerów, którzy zgodnie uważają, że analityk zna wymagania najlepiej (co z reguły jest prawdą) i nigdy się nie myli. Również Project Managerowie wolą wierzyć w zapewnienia analityków o wysokiej jakości dokumentacji, niż w krytyczne uwagi zespołu QA. Nierzadko potrzeba wielu wysiłków, by udowodnić swoje racje i przekonać resztę zespołu projektowego, że tester też może rozumieć wymagania klienta i wspomóc udoskonalanie projektu systemu swoimi uwagami. W projekcie dla instytucji bankowej, w którym pracowałam jako QA team leader, mój zespół doświadczył problemu braku zaufania do naszej wiedzy analitycznej i wyczucia. Przez stosunkowo długi czas wszelkie nasze krytyczne uwagi i prośby o uszczegółowienie czy poprawienie specyfikacji były zbywane stwierdzeniem, iż dokumentacja już została sprawdzona, zaakceptowana i klient nie wnosił żadnych uwag. Nie przyjmowaliśmy takiego wyjaśnienia do wiadomości i praktycznie codziennie atakowaliśmy zespół analityczny dziesiątkami maili z pytaniami i uwagami. Sytuacja odwróciła się po tym, jak zgłosiliśmy błąd dotyczący braku możliwości korzystania z klawiatury numerycznej system nie pozwalał wpisać żadnej cyfry. Programiści odrzucili nasze zgłoszenie, ponieważ w specyfikacji nie było wymagania, aby umożliwiać korzystanie z klawiatury numerycznej. Zgłoszenie to spowodowało istną burzę, ponieważ w ślad za naszym zespołem QA taką samą uwagę z priorytetem krytyczny wniósł klient. Dopiero po tym okazało się, jak wiele uwag i wniosków komunikowanych analitykom przez testerów w początkowych cyklach testowania wewnętrznego jest później zgłaszane przez zespół klienta i zaczęto traktować QA poważnie. Dzięki naszej determinacji, by przekonać resztę zespołu o naszych racjach, udało się wyeliminować wiele potencjalnych problemów i udoskonalić jakość dokumentacji. Korzyści z tego odnieśli również programiści, ponieważ mogli tworzyć kod opierając się o dokładniejszą, bardziej spójną i przejrzystą dokumentację. Audyt dokumentacji nie jest więc zachcianką testerów przynosi wymierne korzyści także pozostałym członkom zespołu projektowego. Nieprawidłowości w zarządzaniu błędami głównie dotyczą: braku zainteresowania zgłoszonym problemem; nieznajomości podstawowego cyklu życia defektu. Pierwszy problem najkrócej obrazuje stwierdzenie: Znalazłem buga, zgłosiłem i reszta mnie nie interesuje. Czekam na poprawkę. To dość często występujące podejście do zarządzania błędami. Tester uważa, że wykonuje swoją pracę realizując zaplanowane scenariusze testowe i raportując ich wyniki. Z analizą odpowiedzi na zgłoszenia czeka do następnego cyklu testów. Tymczasem w bardzo wielu przypadkach otrzymujący błąd do naprawy programista: nie potrafi odtworzyć problemu; nie wie, na czym polega błąd; nie wie, jak go naprawić. Wtedy zdarza się, że odrzuca zgłoszenie z prośbą o dodatkowe informacje lub pomoc. Jeśli tester nie przegląda swoich błędów, nie zauważy tego i nie udzieli informacji niezbędnych do zaplanowania i wdrożenia poprawki. Zorientuje się w kolejnym cyklu te- 7

8 stowym, uzupełni informacje i będzie czekał do następnego cyklu, aby sprawdzić, czy rozwiązanie problemu go satysfakcjonuje. I straci na tym czas ponieważ zamiast zareagować szybko, pomóc programiście i w zamian dostać poprawiony kod w najbliższej nowej wersji systemu, dostanie poprawkę w drugiej wersji aplikacji. Problem numer 2, czyli nieznajomość podstawowego cyklu życia błędu, również powoduje wiele problemów, a nawet chaos w projekcie. Sposób obsługi błędu musi być zgodny z pewnymi ustalonymi regułami, aby zarządzanie defektami było efektywne i spełniało swoją rolę. W przeciwnym wypadku co najmniej utrudnia pracę programistom i pozostałym testerom (ponieważ prowadzi do wyciągania mylnych wniosków), a w najgorszym wypadku do chaosu organizacyjnego, a nawet konieczności powtarzania całego cyklu testów. Ogólny cykl życia błędu przedstawia rysunek 2. Czasami testerzy ustalają własny porządek pracy i obsługują błędy niezgodnie z ustalonymi regułami: testowanie poprawek w nieodpowiedniej wersji systemu nie zwracają uwagi na to, jaki numer wersji aplikacji ustawił programista naprawiając problem, i w której wersji poprawka jest dostępna; ponowne otwieranie błędów bez określenia przyczyny bez opisu, co działa nieprawidłowo, co jeszcze należy poprawić; ponowne otwieranie zgłoszenia w sytuacji, gdzie błąd dotyczy czego innego np. problem opisany w zgłoszeniu błędu został naprawiony, lecz pojawił się nowy, w innej części funkcjonalności. Takie problemy powinny być raportowane jako osobne zgłoszenia w innym przypadku może dojść do sytuacji, kiedy poprawianie i otwieranie tego samego defektu będzie się ciągnąć w nieskończoność bo każda poprawka spowoduje inny problem, w innych modułach, o innym priorytecie. Śledzenie historii takiego błędu nie będzie miało najmniejszego sensu; zapominanie o weryfikacji poprawek w odpowiedniej wersji aplikacji lub odkładanie sprawdzenia na później, z racji innych, pilniejszych zadań. Skutek programiści i sami testerzy nie wiedzą, czy błędy zostały poprawione, czy zmiany w kodzie nie spowodowały innych problemów itp. Testowanie poprawek powinno być zawsze pierwszą czynnością po wykonaniu testów dymnych. zgłaszanie duplikatów raportowanie problemu bez upewnienia się, czy ktoś inny nie zgłosił już podobnego, lub otwieranie zgłoszenia tego samego problemu w trakcie testów kolejnej wersji aplikacji tj.bez uzyskania poprawki do błędu już zgłoszonego. Wrogość pomiędzy testerami a programistami występuje dość często jest przejawem pewnej rywalizacji oraz faktu, iż nikt nie lubi przyznawać się do pomyłki a zgłaszanie błędów jest nieraz traktowane przez programistę jako atak na jego umiejętności. Zdarza się też, że komunikacja pomiędzy zespołami ogranicza się do wymiany informacji w systemie śledzenia błędów, a obie strony nie są zainteresowane nawiązaniem bardziej bezpośredniego kontaktu. Tymczasem utrzymywanie dobrych relacji może obu stronom przynieść korzyści: lepsza komunikacja zwiększa szanse na szybkie rozwiązywanie problemów i naprawianie błędów zamiast kontaktować się jedynie poprzez zmiany statusu zgłoszenia w systemie śledzenia błędów, obie strony mogą na bieżąco wyjaśniać wątpliwości i uzgadniać pożądane rozwiązanie; programista inaczej podchodzi do problemu, jeśli ma świadomość, że tester nie obwinia go o wadliwą implementację i nie czyni personalnych uwag co do jakości kodu traktuje zgłoszenie jako zwykłe zadanie do wykonania, a nie poddawanie w wątpliwość jego kwalifikacji; możliwość przetestowania poprawki przed jej wdrożeniem w środowisko testowe dobre relacje z programistami często pozwalają na wgląd w poprawiony kod jeszcze przed tym, jak programista zatwierdzi zmiany do SVNa. Tym sposobem tester może sprawdzić rozwiązanie problemu przed oficjalnym wdrożeniem zmiany i upewnić się, czy działa tak, jak powinien. Co równie istotne, może również sprawdzić, czy poprawka nie spowodowała innych błędów; programista może pomóc testerowi w jego pracy zwracając uwagę na potrzebę dokładniejszego przetestowania pewnych obszarów czy scenariuszy, o ile ma podejrzenia co do jakości aplikacji we wskazanych miejscach. Wiele razy doświadczałam sytuacji, w których programiści prosili o sprawdzenie kilku funkcji, które rzeczywiście okazywały się wadliwe. Obie strony miały z tego korzyści tester, ponieważ znalazł błędy, które w przeciwnym wypadku odkryłby zespół klienta; programista ponieważ po naprawieniu usterek i ich weryfikacji mógł mieć pewność co do jakości systemu. Pracując w zespole, jakim jest personel projektu, należy pamiętać o jednym działamy zespołowo mając na względzie wspólny cel i jednym z naszych zadań jest wspieranie pozostałych członków grupy - czy to innych testerów, czy programistów lub analityków. Nie jest możliwe prowadzenie projektu informatycznego w pojedynkę, ani też prowadzenie projektu w sytuacji, gdy część zespołu walczy z drugą grupą. Testowanie nie jest czynnością tak prostą, jak się na pierwszy rzut oka może wydawać. Jednym z głównych celów prac QA jest wynajdywanie błędów i nieprawidłowości, dążenie do doskonalenia systemu informatycznego oraz dokumentacji analitycznej. Jakość testowania obniża się jednak znacząco w przypadku, gdy sam proces realizowany jest w niewłaściwy sposób lub przez osoby o niewystarczających kwalifikacjach i predyspozycjach. Niniejszy artykuł przybliżył klika podstawowych pomyłek, występujących w planowaniu oraz realizacji testowania. Analiza owych nieprawidłowości oraz zapoznanie się z przytoczonymi wskazówkami może pomóc wyeliminować pewne podstawowe błędy zarządzania i organizacji pracy oraz uczynić proces testowy bardziej efektywnym. 8

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

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

Normalizacja baz danych

Normalizacja baz danych Normalizacja baz danych Definicja 1 1 Normalizacja to proces organizowania danych w bazie danych. Obejmuje to tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi

Bardziej szczegółowo

Sukces vs porażka. Sukces. Porażka

Sukces vs porażka. Sukces. Porażka Wstęp Cytaty Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program, to jest drobiazg. Często po awarii pojawia się komunikat typu ID 02. ID to skrót od idiotyczny drobiazg,

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

Najwyżej ocenione raporty dla Mr Buggy 4

Najwyżej ocenione raporty dla Mr Buggy 4 Najwyżej ocenione raporty dla Mr Buggy 4 Uwagi Komisji: 1. Żaden z raportów nie otrzymał maksymalnej liczby punktów. 2. Poniżej prezentowane są oryginalne wersje raportów z usuniętymi danymi mogącymi identyfikować

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

Czym jest jakość? Według najbardziej

Czym jest jakość? Według najbardziej Są to cechy istotne z punktu widzenia konsumenta. Producent musi oprócz tego brać pod uwagę zyskowność i działalność konkurencji, co często jest w konflikcie z jakością technologiczną produktu. Bardzo

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Spis treści. 1. Utworzenie konta...3. 2. Dodanie zgłoszenia...5. 3. Realizacja zgłoszenia...7

Spis treści. 1. Utworzenie konta...3. 2. Dodanie zgłoszenia...5. 3. Realizacja zgłoszenia...7 0 Spis treści 1. Utworzenie konta...3 2. Dodanie zgłoszenia...5 3. Realizacja zgłoszenia...7 1 System wsparcia technicznego pozwala na szybką reakcję zespołu specjalistów oraz pełne udokumentowanie historii

Bardziej szczegółowo

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10.

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10. Bez celu ani rusz Karolina Zmitrowicz Niepowodzenia projektów informatycznych to nieustannie wdzięczny temat pojawia się na konferencjach, szkoleniach, w prasie i innych publikacjach. Badaniem przyczyn

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2 Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja

Bardziej szczegółowo

Nazwa Projektu. Plan testów. Wersja N.NN

Nazwa Projektu. Plan testów. Wersja N.NN Nazwa Projektu Plan testów Wersja N.NN Projekt realizowany jest w ramach Programu e-cło współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna

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

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

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

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

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

CROSS-COACHING NOWOCZESNE NARZĘDZIE ROZWOJU W ORGANIZACJI

CROSS-COACHING NOWOCZESNE NARZĘDZIE ROZWOJU W ORGANIZACJI CROSS-COACHING NOWOCZESNE NARZĘDZIE ROZWOJU W ORGANIZACJI BARBARA KUBICKA - KLUCZNY Cross-coaching nowoczesne narzędzie rozwoju w organizacji Zarówno o coachingu indywidualnym jak i zespołowym powiedziano

Bardziej szczegółowo

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka Zmiany w standardzie ISO 9001 dr inż. Ilona Błaszczyk Politechnika Łódzka 1 W prezentacji przedstawiono zmiany w normie ISO 9001 w oparciu o projekt komitetu. 2 3 4 5 6 Zmiany w zakresie terminów używanych

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

Bardziej szczegółowo

Metoda 5-WHY. Metoda 5-WHY. Wydanie 1. Zbigniew Huber. Maj 2006. Artykuł dostępny na stronie autora: http://www.huber.pl.

Metoda 5-WHY. Metoda 5-WHY. Wydanie 1. Zbigniew Huber. Maj 2006. Artykuł dostępny na stronie autora: http://www.huber.pl. Metoda 5-WHY Wydanie 1 Zbigniew Huber Maj 2006 Artykuł dostępny na stronie autora: http://www.huber.pl Copyright by Zbigniew Huber Strona 1 z 6 Wstęp Rozwiązanie jakiegoś problemu i wprowadzenie skutecznego

Bardziej szczegółowo

Overlord - Software Development Plan

Overlord - Software Development Plan Overlord - Software Development Plan Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej 5 czerwca 2006 Spis treści 0.1 Cel.......................................... 4 0.2 Zakres........................................

Bardziej szczegółowo

PROBLEMY TECHNICZNE. Co zrobić, gdy natrafię na problemy związane z użytkowaniem programu DYSONANS

PROBLEMY TECHNICZNE. Co zrobić, gdy natrafię na problemy związane z użytkowaniem programu DYSONANS PROBLEMY TECHNICZNE Co zrobić, gdy natrafię na problemy związane z użytkowaniem programu DYSONANS Jeżeli stwierdziłeś występowanie błędów lub problemów podczas pracy z programem DYSONANS możesz skorzystać

Bardziej szczegółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

Bardziej szczegółowo

Czym są pliki cookies?

Czym są pliki cookies? Czym są pliki cookies? Poprzez pliki cookies należy rozumieć dane informatyczne, w szczególności pliki tekstowe, przechowywane w urządzeniach końcowych użytkowników przeznaczone do korzystania ze stron

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

Podstawowe zagadnienia opracowane na podstawie wniosków z analizy nadzorczej

Podstawowe zagadnienia opracowane na podstawie wniosków z analizy nadzorczej Stanowisko UKNF w sprawie dobrych praktyk w zakresie walutowych transakcji pochodnych - podstawowe zagadnienia opracowane na podstawie wniosków z analizy nadzorczej Zgromadzony w toku czynności nadzorczych

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

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

Rozwiązania CAD/CAM/CAE/PDM. esupport. System wsparcia technicznego firmy Premium Solutions Polska. Autoryzowany Dystrybutor:

Rozwiązania CAD/CAM/CAE/PDM. esupport. System wsparcia technicznego firmy Premium Solutions Polska. Autoryzowany Dystrybutor: Rozwiązania CAD/CAM/CAE/PDM esupport System wsparcia technicznego firmy Premium Solutions Polska Autoryzowany Dystrybutor: Spis treści: 1. Wstęp... 3 2. Uruchomienie... 4 3. Rejestracja Użytkownika...

Bardziej szczegółowo

Bezpieczeństwo i koszty wdrażania Informatycznych Systemów Zarządzania Hubert Szczepaniuk Wojskowa Akademia Techniczna im. Jarosława Dąbrowskiego

Bezpieczeństwo i koszty wdrażania Informatycznych Systemów Zarządzania Hubert Szczepaniuk Wojskowa Akademia Techniczna im. Jarosława Dąbrowskiego Bezpieczeństwo i koszty wdrażania Informatycznych Systemów Zarządzania Hubert Szczepaniuk Wojskowa Akademia Techniczna im. Jarosława Dąbrowskiego Problem wdrażania IT w organizacji Wskaźnik powodzeń dużych

Bardziej szczegółowo

którego nie stosuje się przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych na:

którego nie stosuje się przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych na: GŁÓWNY URZĄD GEODEZJI I KARTOGRAFII Warszawa, 2 października 2015 r. DEPARTAMENT NADZORU, KONTROLI I ORGANIZACJI SŁUŻBY GEODEZYJNEJ I KARTOGRAFICZNEJ NG-KiSZ.2611.6.2015 Do wszystkich Wykonawców Dotyczy:

Bardziej szczegółowo

PRZEWODNIK TECHNICZNY DLA KART PŁATNICZYCH

PRZEWODNIK TECHNICZNY DLA KART PŁATNICZYCH PRZEWODNIK TECHNICZNY DLA KART PŁATNICZYCH 1 SPIS TREŚCI 1. WSTĘP... 3 2. ZMIANA LIMITÓW TRANSAKCJI INTERNETOWYCH... 3 2.1 WPROWADZANIE WNIOSKU O LIMIT DLA TRANSAKCJI INTERNETOWYCH W SYSTEMIE VISIONA...

Bardziej szczegółowo

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert Sygnatura postępowania: BZP/31/DRI/2015 BGK BANK GOSPODARSTWA KRAJOWEGO Warszawa, 8 lipiec 2015 r. Zamawiający: Bank Gospodarstwa Krajowego Al. Jerozolimskie 7 00-955 Warszawa Biuro Zamówień Publicznych

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

Modelowanie testów. czyli po co testerowi znajomość UML

Modelowanie testów. czyli po co testerowi znajomość UML Modelowanie testów czyli po co testerowi znajomość UML Paweł Dudzik październik 2015 Naturalny opis świata Powstaje pytanie, jak opisać ten świat, aby opis był jak najbardziej zbliżony do rzeczywistości,

Bardziej szczegółowo

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

Wprowadzenie do systemów informacyjnych

Wprowadzenie do systemów informacyjnych Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj

Bardziej szczegółowo

Strona tytułowa, zgodnie z wymaganiami zamieszczonymi na stronie www uczelni. Wzór strony dostępny jest w dzienniku wirtualnym - 1 -

Strona tytułowa, zgodnie z wymaganiami zamieszczonymi na stronie www uczelni. Wzór strony dostępny jest w dzienniku wirtualnym - 1 - Strona tytułowa, zgodnie z wymaganiami zamieszczonymi na stronie www uczelni. Wzór strony dostępny jest w dzienniku wirtualnym - 1 - Spis treści 1 Wstęp... 3 1.1 Cel pracy... 3 1.2 Układ pracy... 4 2 Podstawy

Bardziej szczegółowo

WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA

WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA WSTĘP... 2 1 UWARUNKOWANIA TECHNICZNE... 2 2 UWARUNKOWANIA FORMALNE... 2 3 LOGOWANIE DO SERWISU... 2 4 WIDOK STRONY GŁÓWNEJ...

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

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

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Opis Progress Project zaprasza do zapoznania się z programem szkolenia organizowanego przez partnera szkoleniowego,

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

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

INSTRUKCJA OTWARCIA RACHUNKU ALIOR TRADER PRZEZ INTERNET

INSTRUKCJA OTWARCIA RACHUNKU ALIOR TRADER PRZEZ INTERNET INSTRUKCJA OTWARCIA RACHUNKU ALIOR TRADER PRZEZ INTERNET OTWARCIE RACHUNKU ROR PRZEZ INTERNET Aby otworzyć rachunek ROR przez Internet należy, uruchomić portal Alior Banku i przejść do sekcji Klienci Indywidualni/Konta

Bardziej szczegółowo

System magazynowy małego sklepu.

System magazynowy małego sklepu. System magazynowy małego sklepu. dokumentacja użytkownika. Mariusz Grabowski e-mail: mariosh@interia.pl Jabber ID: mariosh@jabber.autocom.pl Spis treści 1 Wstęp. 2 2 Przed uruchomieniem. 3 3 Korzystanie

Bardziej szczegółowo

Podręcznik użytkownika Publikujący aplikacji Wykaz2

Podręcznik użytkownika Publikujący aplikacji Wykaz2 Podręcznik użytkownika Publikujący aplikacji Wykaz2 TiMSI Sp z o o ul Czapli 63, 02-781 Warszawa tel : +48 22 644 86 76, fax: +48 22 644 78 52 NIP: 951-19-39-800 Sąd Rejonowy dla mst Warszawy w Warszawie,

Bardziej szczegółowo

Pytania i wyjaśnienia treści Specyfikacji Istotnych Warunków Zamówienia

Pytania i wyjaśnienia treści Specyfikacji Istotnych Warunków Zamówienia Warszawa, 11 kwietnia 2013 r. Dotyczy: postępowania prowadzonego w trybie przetargu nieograniczonego na Usługi wsparcia technicznego, utrzymania oraz rozwoju systemu Soprano, Phoenix oraz Register Plus

Bardziej szczegółowo

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Zarządzanie projektami. Sylabus opisuje zakres wiedzy

Bardziej szczegółowo

Szkoła Podstawowa nr 336 im. Janka Bytnara Rudego - Ursynów

Szkoła Podstawowa nr 336 im. Janka Bytnara Rudego - Ursynów RAPORT OCENA KONTROLI ZARZĄDCZEJ Szkoła Podstawowa nr 336 im. Janka Bytnara Rudego - Ursynów raport za rok: 2015 Strona 1 z 12 I. WSTĘP: Kontrolę zarządczą w jednostkach sektora finansów publicznych stanowi

Bardziej szczegółowo

Instrukcja dla Uczelnianego Administratora Systemu Antyplagiatowego Plagiat.pl

Instrukcja dla Uczelnianego Administratora Systemu Antyplagiatowego Plagiat.pl Instrukcja dla Uczelnianego Administratora Systemu Antyplagiatowego Plagiat.pl Materiały przeznaczone wyłącznie dla UASA. Plagiat.pl 1/15 Spis treści: I. Logowanie II. Menu konta UASA III. Konto IV. Administratorzy

Bardziej szczegółowo

MECHANIZM WYMIANY DANYCH ORAZ ROZLICZEŃ APTEKA NFZ

MECHANIZM WYMIANY DANYCH ORAZ ROZLICZEŃ APTEKA NFZ MECHANIZM WYMIANY DANYCH ORAZ ROZLICZEŃ APTEKA NFZ Stan na dzień 12.01.2012 Najnowszej wersji tej instrukcji szukaj pod adresem: http://www.kamsoft.pl/prod/aow/ustawa_2012.htm I. Wstęp. Od 1 stycznia 2012

Bardziej szczegółowo

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

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

USTALENIE SYSTEMU WYNAGRODZEŃ

USTALENIE SYSTEMU WYNAGRODZEŃ USTALENIE SYSTEMU WYNAGRODZEŃ Administracja systemu wynagrodzeń jest ważnym elementem prowadzenia biznesu. Gdy mamy działający formalny system płac, pomaga to w kontrolowaniu kosztów personelu, podnosi

Bardziej szczegółowo

OPIEKUN DORADCY: KONTO FIRMY - PIERWSZE KROKI

OPIEKUN DORADCY: KONTO FIRMY - PIERWSZE KROKI Portalami Opiekun Doradcy / Opiekun Zysku zarządza firma Opiekun Inwestora z siedzibą w Poznaniu, NIP: 972 117 04 29 KONTAKT W SPRAWIE WSPÓŁPRACY W RAMACH PROJEKTU OPIEKUN DORADCY pomoc@opiekundoradcy.pl,

Bardziej szczegółowo

Raport oceny kompetencji

Raport oceny kompetencji Symulacje oceniające kompetencje Raport oceny kompetencji Rut Paweł 08-01-2015 Kompetencje sprzedażowe dla efactor Sp. z o.o. Dane osobowe Rut Paweł CEO pawel.rut@efactor.pl more-than-manager.com 2 z 13

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się

Bardziej szczegółowo

Pytania w ramach opublikowania postępowania znak postępowania: WORD/D/23/144/W/2015.

Pytania w ramach opublikowania postępowania znak postępowania: WORD/D/23/144/W/2015. Pytania w ramach opublikowania postępowania znak postępowania: WORD/D/23/144/W/2015. 1. Załącznik 2 - Warunki Gwarancji i Utrzymania czy linia Awaria powinna być również dostępna w dniu ustawowo wolnym

Bardziej szczegółowo

1. LOGOWANIE DO SYSTEMU

1. LOGOWANIE DO SYSTEMU 1. LOGOWANIE DO SYSTEMU Aby zalogować się do systemu należy do okna przeglądarki internetowej wpisać adres: mindstormlab.com/cms Należy upewnić się, że w pasku adresu przeglądarki po wprowadzeniu poprawnego

Bardziej szczegółowo

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

Instrukcja wczytywania i przekazywania zbiorów centralnych w Centralnej Aplikacji Statystycznej (CAS) przez użytkowników podobszaru PS

Instrukcja wczytywania i przekazywania zbiorów centralnych w Centralnej Aplikacji Statystycznej (CAS) przez użytkowników podobszaru PS Instrukcja wczytywania i przekazywania zbiorów centralnych w Centralnej Aplikacji Statystycznej (CAS) przez użytkowników podobszaru PS Uwaga! Opisane w niniejszej instrukcji funkcje Centralnej Aplikacji

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

OPIEKUN DORADCY: KONTO FIRMY ZARZĄDZANIE KLIENTAMI

OPIEKUN DORADCY: KONTO FIRMY ZARZĄDZANIE KLIENTAMI Portalami Opiekun Doradcy / Opiekun Zysku zarządza firma Opiekun Inwestora z siedzibą w Poznaniu, NIP: 972 117 04 29 KONTAKT W SPRAWIE WSPÓŁPRACY W RAMACH PROJEKTU OPIEKUN DORADCY pomoc@opiekundoradcy.pl,

Bardziej szczegółowo

ERP przyspiesza Kontrolę Jakości

ERP przyspiesza Kontrolę Jakości ERP przyspiesza Kontrolę Jakości Jedną z priorytetowych wartości, najszybciej rozwijających się przedsiębiorstw produkcyjnych jest: Kontrola Jakości. Przedsiębiorcy zwiększają konkurencyjność swoich firm,

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

aplikacja akcyzattor

aplikacja akcyzattor Wdrożenie systemu służącego do prowadzenia ewidencji energii elektrycznej w formie elektronicznej dla potrzeb rozliczeń podatku akcyzowego aplikacja akcyzattor Klient: KGHM Polska Miedź S.A. Klient KGHM

Bardziej szczegółowo

Agencja interaktywna. InterActive. Strona WWW + system obsługi klientów

Agencja interaktywna. InterActive. Strona WWW + system obsługi klientów Agencja interaktywna InterActive Strona WWW + system obsługi klientów Na wstępie chcemy Państwu serdecznie podziękować za zainteresowanie naszą ofertą. Jesteśmy bardzo dumni z możliwości nawiązania współpracy

Bardziej szczegółowo

ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0

ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0 ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Użytkowanie baz danych. Sylabus opisuje zakres wiedzy

Bardziej szczegółowo

Zarządzanie projektami IT

Zarządzanie projektami IT Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie

Bardziej szczegółowo

Zmiany wymagań normy ISO 14001

Zmiany wymagań normy ISO 14001 Zmiany wymagań normy ISO 14001 Międzynarodowa Organizacja Normalizacyjna (ISO) opublikowała 15 listopada br. zweryfikowane i poprawione wersje norm ISO 14001 i ISO 14004. Od tego dnia są one wersjami obowiązującymi.

Bardziej szczegółowo

Compuware Changepoint. Portfolio Management Tool

Compuware Changepoint. Portfolio Management Tool Compuware Changepoint Portfolio Management Tool Compuware Changepoint Zintegrowane Zarządzanie Portfelem IT W dzisiejszym świecie czołowi użytkownicy IT podejmują inicjatywy dopasowania IT do strategii

Bardziej szczegółowo

Instrukcja dla użytkowników serwisu internetowego

Instrukcja dla użytkowników serwisu internetowego Instrukcja dla użytkowników serwisu internetowego 1 2 Spis treści SPIS TREŚCI... 2 I WSTĘP... 3 II OPIS FUNKCJONALNOŚCI... 3 1. LOGOWANIE DO SERWISU INTERNETOWEGO... 3 1.1 Reguły bezpieczeństwa... 3 2.

Bardziej szczegółowo

Instrukcja zgłaszania błędu

Instrukcja zgłaszania błędu Instrukcja zgłaszania błędu 1 Kanały zgłaszania Do dyspozycji są trzy kanały zgłoszeń: A. AnswerTrack 2 aby skorzystać z tego kanału należy posiadać założone konto użytkowania AT2 (pkt.3), wypełnić formularz

Bardziej szczegółowo

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV Metodyka wdrożenia Bartosz Szczęch Starszy Konsultant MS Dynamics NAV bartosz.szczech@it.integro.pl Wyróżniamy następujące etapy wdrożenia rozwiązania ERP: Analiza Projekt Budowa Uruchomienie Działanie

Bardziej szczegółowo

SCENARIUSZE ĆWICZEŃ DLA UŻYTKOWNIKÓW WEWNĘTRZNYCH SYSTEMU INFORMATYCZNEGO NAWIKUS

SCENARIUSZE ĆWICZEŃ DLA UŻYTKOWNIKÓW WEWNĘTRZNYCH SYSTEMU INFORMATYCZNEGO NAWIKUS PAKIET EDUKACYJNY SCENARIUSZE ĆWICZEŃ DLA UŻYTKOWNIKÓW WEWNĘTRZNYCH SYSTEMU INFORMATYCZNEGO NAWIKUS Kraków, grudzień 2014 r. Pro j e k t P I N A W I K U S i n n o w a c y j n a m e t o d a m o n i t o

Bardziej szczegółowo

RAPORT Z TESTOWANIA USŁUG NA PLATFORMIE ELA-ENT

RAPORT Z TESTOWANIA USŁUG NA PLATFORMIE ELA-ENT Miejscowość Lublin, dnia 17.12.2009 RAPORT Z TESTOWANIA USŁUG NA PLATFORMIE ELA-ENT 1. Dane podstawowe W poniższych polach należy wpisać informacje o testującym, szkolącym, sprawdzanych przez niego usługach,

Bardziej szczegółowo

ELEKTRONICZNA SKRZYNKA PODAWCZA CYFROWY URZĄD Województwa Warmińsko Mazurskiego Część użytkownika

ELEKTRONICZNA SKRZYNKA PODAWCZA CYFROWY URZĄD Województwa Warmińsko Mazurskiego Część użytkownika ELEKTRONICZNA SKRZYNKA PODAWCZA CYFROWY URZĄD Województwa Warmińsko Mazurskiego Część użytkownika WERSJA 1.0 Twórca oprogramowania: Województwo Warmińsko Mazurskie Olsztyn, 28 lipca 2011r. Spis treści

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji na przedmiot Umowy i zobowiązuje

Bardziej szczegółowo

System epon Dokumentacja użytkownika

System epon Dokumentacja użytkownika System epon Dokumentacja użytkownika Prawa autorskie tego opracowania należą do MakoLab S.A. Dokument ten, jako całość, ani żadna jego część, nie może być reprodukowana lub rozpowszechniana w jakiejkolwiek

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona

Bardziej szczegółowo

WellCommerce Poradnik: Sprzedaż

WellCommerce Poradnik: Sprzedaż WellCommerce Poradnik: Sprzedaż Spis treści well W tej części poradnika poznasz funkcje WellCommerce odpowiedzialne za obsługę sprzedaży. 2 Spis treści... 2 Wstęp... 3 Logowanie do panelu administratora...

Bardziej szczegółowo

Wzmocnienie potencjału analitycznego administracji publicznej przedsięwzięcie podjęte przez Szefa Służby Cywilnej

Wzmocnienie potencjału analitycznego administracji publicznej przedsięwzięcie podjęte przez Szefa Służby Cywilnej Wzmocnienie potencjału analitycznego administracji publicznej przedsięwzięcie podjęte przez Szefa Służby Cywilnej Warszawa, czerwiec 2014 r. Dotychczas podjęte inicjatywy Szefa Służby Cywilnej W latach

Bardziej szczegółowo

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków

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

Podręcznik użytkownika Obieg dokumentów

Podręcznik użytkownika Obieg dokumentów Podręcznik użytkownika Obieg dokumentów Opracowany na potrzeby wdrożenia dla Akademii Wychowania Fizycznego im. Eugeniusza Piaseckiego w Poznaniu W ramach realizacji projektu: Uczelnia jutra wdrożenie

Bardziej szczegółowo

Skuteczność => Efekty => Sukces

Skuteczność => Efekty => Sukces O HBC Współczesne otoczenie biznesowe jest wyjątkowo nieprzewidywalne. Stała w nim jest tylko nieustająca zmiana. Ciągłe doskonalenie się poprzez reorganizację procesów to podstawy współczesnego zarządzania.

Bardziej szczegółowo

Testy automatyczne. Korzystające z junit

Testy automatyczne. Korzystające z junit Testy automatyczne Korzystające z junit Cytaty Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program, to jest drobiazg. Często po awarii pojawia się komunikat typu ID

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

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających

Bardziej szczegółowo

B A N K S P Ó Ł D Z I E L C Z Y W L I M A N O W E J

B A N K S P Ó Ł D Z I E L C Z Y W L I M A N O W E J Załącznik nr 1 do Uchwały Nr 3/10/2004 Zarządu BS w Limanowej z dnia 19.10.2004r. I zm. 9/05/2007 z 31.05.2007 II zm. 5/07/2007 z 12.07.2007r. III zm.6/06/2008 z 12.06.2008r B A N K S P Ó Ł D Z I E L C

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo