TESTER.PL. Z pozdrowieniami. Zarząd Stowarzyszenia Jakości Systemów Informatycznych. Strona 1 z 34

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

Download "TESTER.PL. Z pozdrowieniami. Zarząd Stowarzyszenia Jakości Systemów Informatycznych. Strona 1 z 34"

Transkrypt

1 Równo rok temu, 26 czerwca 2003, odbył się zjazd założycielski naszego Stowarzyszenia Stowarzyszenia Jakości Systemów Informatycznych SJSI. Zebrało się wówczas 27 osób. Dzisiaj jednym z namacalnych dowodów działalności SJSI jest pierwszy numer kwartalnika Tester.pl, który właśnie oddajemy do rąk czytelników Po roku nasze szeregi liczą ponad 70 członków i wielu, wielu sympatyków. Rozpoczęliśmy współpracę z firmami komercyjnymi: producentami narzędzi, organizatorami szkoleń. Uruchomiliśmy stronę www naszego Stowarzyszenia. Przez cały rok odbywały się spotkania cykliczne, na których omawialiśmy zagadnienia z obszaru zapewnienia jakości oprogramowania. SJSI było patronem merytorycznym lub organizacją wspierającą dla kilku konferencji, w tym międzynarodowych. Nawiązaliśmy współpracę z ISTQB International Software Testing Qualifications Board. Co dalej? Przede wszystkim zamierzamy przeprowadzić pierwsze egzaminy Foundation Certificate in Software Testing w języku polskim oraz wprowadzić kurs i egzamin na poziom Advanced. Będziemy aktywnie współorganizować kolejne konferencje, również międzynarodowe. We wrześniu, po przerwie wakacyjnej, wznowimy cykl naszych comiesięcznych spotkań, organizując je równolegle w Warszawie na Politechnice Warszawskiej i w Krakowie, na Akademii Ekonomicznej. W październiku zamierzamy sami zorganizować konferencję. Okazją jest pierwsza rocznica powstania Stowarzyszenia. Konferencji będzie towarzyszył drugi numer kwartalnika Tester.pl Plany są ambitne. Aby je zrealizować, potrzebna jest współpraca wszystkich członków Stowarzyszenia. Osoby, które chciałyby się aktywniej włączyć w prace (redakcja strony www, kwartalnika, współpraca z ISTQB, współorganizacja konferencji, pozyskiwanie nowych członków, w tym również firm) prosimy o kontakt z Zarządem. Pracy jest wiele, ale niewątpliwie satysfakcja z współtworzenia pierwszego w Polsce i Europie środkowowschodniej stowarzyszenia testersko jakościowego może być duża. Razem kształtujemy oblicze Stowarzyszenia, a każdy dokładając cegiełkę swojej pracy sprawia, że jego idea jest żywa. Życząc miłej lektury dziękujemy wszystkim tym, którzy przyczynili się do powstania tego kwartalnika, a także wszystkim, dzięki którym SJSI się rozwija. Z pozdrowieniami Zarząd Stowarzyszenia Jakości Systemów Informatycznych Strona 1 z 34

2 Od redaktora Oddajemy do Waszych rąk, Drodzy Czytelnicy, pierwszy numer kwartalnika TESTER.PL. Zgodnie z zamierzeniami jest to pismo dla ludzi zajmujących się głównie, ale nie tylko, testowaniem oprogramowania. Powstało wraz z naszą organizacją Stowarzyszeniem Jakości Systemów Informatycznych i jak ta organizacja, służyć ma przede wszystkim rozpowszechnianiu wiedzy o zasadach testowania oprogramowania i różnym metodo, temu służącym. W tym numerze cztery pozycje: 1. Bogdan Bereza Jarociński o potrzebie testowaniu, lekko i dowcipnie, 2. Lucjan Stapp o wpływie lekkiej metodyki XP na testowanie, 3. Piotr Kałuski o swoich doświadczeniach z kilku lat walki z papierkami, 4. Robert Rzeszotek o PureTest - shareware owym narzędziu do testowaniu. Ponieważ, chcemy tego czy nie, roboty testowe staja się teraźniejszością, a na pewno będą przyszłością branży zajmującej się zapewnieniem jakości oprogramowania (patrz np. felieton Bogdana Berezy Jarocińskiego), ostatni artykuł to początek planowanej serii o różnych automatach testowych. Równocześnie chciałbym gorąco zachęcić wszystkich czytelników tego periodyku do aktywnej współpracy. Z przyjemnością zamieścimy Wasze uwagi, artykuły, felietony mieszczące się w spektrum naszych zainteresowań. Redaktor Strona 2 z 34

3 Tekst sponsorowany Software-Konferencje Sp. z o.o. ul. Lewartowskiego Warszawa tel.+ 48 (22) fax.+ 48 (22) Firma Software Konferencje, dostawca profesjonalnych szkoleń i konferencji dla branży IT zaprasza wszystkich, którym tematyka jakości oprogramowania jest szczególnie bliska do wzięcia udziału w szkoleniach poświęconych właśnie tym zagadnieniom. W naszej ofercie znajdą Państwo miedzy innymi: Podstawy Testowania Oprogramowania Trzydniowy kurs posiadający akredytację ISEB i kończący się egzaminem na certyfikat ISEB SW Foundation Certificate Techniki Testowania Oprogramowania Zarządzanie Testowaniem Oprogramowania. Narzędzia wspierające zarządzanie testowaniem Pozyskiwanie i zarządzanie wymaganiami w projekcie informatycznym Dwudniowy kurs posiadający akredytację IEEE Computer Society. Kurs przygotowuje do egzaminu na Certified Software Development Professional, który można zdać w Polsce za pośrednictwem naszej firmy. Software Quality Assurance Management. Testowanie i zarządzanie jakością w procesie tworzenia oprogramowania. Doroczne spotkanie osób zarządzających testowaniem, kierowników projektów i testerów, osób oceniających wymagania projektów informatycznych. Strona 3 z 34

4 Szczegółowe informacje na temat organizowanych szkoleń znajdą Państwo na stronie: Informacje o firmie: Software-Konferencje Sp. z o.o. działa na rynku od sześciu lat. Organizujemy konferencje, seminaria i warsztaty dotyczące wiedzy i technologii IT. Nasza oferta kierowana jest do osób i instytucji zajmującym się profesjonalnie informatyką. Podczas organizacji imprez współpracujemy z funkcjonującymi na polskim rynku IT organizacjami i instytucjami, wiodącymi polskimi i zagranicznymi firmami informatycznymi, firmami doradczymi oraz grupą niezależnych specjalistów i konsultantów. Strona 4 z 34

5 Test w banku Bogdan Bereza-Jarociński bbjtest Bogdan Bereza-Jarociński Psycholog z Uniwersytetu Warszawskiego i Londyńskiego, informatyk z uniwersytetu w Lund. Testował, zarządzał, automatyzował, koordynował lub ulepszał procesy testowe zarówno w zastosowaniach wbudowanych (telekomunikacja Ericsson, sygnalizacja kolejowa Bombardier) jak i otwartych (bazodanowe, Java). Lubi udzielać się na międzynarodowych konferencjach i prowadzic szkolenia z dziedziny testowania. Od 2002 roku prowadzi w Polsce szkolenia m. in. na certyfikat ISEB. Strona 5 z 34

6 Test w banku Bogdan Bereza-Jarociński bbjtest Komputery to czarodziejskie urządzenia robią za nas automatycznie to, co wcześniej musieliśmy mozolnie wykonywać ręcznie. Co więcej, projektowanie i budowa nowych komputerowych robotów nie wymaga mozolnej pracy zespołów architektów, stolarzy, murarzy i mechaników. Wszystko daje się szybko i sprawnie wymodelować i zrealizować w jednym, magicznym tworzywie oprogramowaniu komputera. Nikt lepiej niż banki nie docenia możliwości, jakie daje zastąpienie wielkiej sali pełnej sfrustrowanych, omylnych urzędników cierpliwym i usłużnym komputerem, a kosztownej sieci bankowych oddziałów dostępną w trybie 24 * 365 aplikacją internetową. Zarazem jednak nikt lepiej niż banki nie zdaje sobie sprawy, jakie straty może spowodować jeden na pozór niegroźny błąd w obliczeniach, chwilowe nawet ograniczenie dostępności banku internetowego czy wreszcie włamanie się hackera do systemu. Pisanie o testowaniu i zapewnieniu jakości systemów informatycznych przypomina często żmudną pracę misyjną: przekonywanie niewiernych, że test naprawdę nie jest kosztownym luksusem, że się opłaca, ba jest konieczny! Wobec banków mam nadzieję nie ma takiej potrzeby. Można od razu przejść do tematów zaawansowanych. Praca żmudna, mozolna, ale za to jaka jałowa! Testowanie polega bardzo często na tym, że sprawdza się ponownie wielokrotnie, obsesyjnie to, co działało wcześniej. Osobę, która przemalowawszy sufit w łazience, sprawdza, czy nadal funkcjonuje kuchenka w kuchni, uznalibyśmy za nieco zneurotyzowaną. Niestety, własnością magicznego tworzywa zwanego oprogramowaniem jest to, że takie właśnie zależności mogą zaistnieć liczne przykłady zna każdy programista, użytkownik czy administrator systemu z własnego doświadczenia. Dlatego nawet zmiany pozornie niewinne: dodanie jednej nowej funkcji, inna konfiguracja, nowa platforma sprzętowa, instalacja systemu w innym środowisku wymagają ponownego przetestowania całości systemu. Ta czynność, zwana w dialekcie branżowym funkcjonalnym testowaniem regresyjnym, jest piętą achillesową wielu projektów informatycznych. Sprzymierzeńcem mogą być narzędzia. Tak jak istnieje oprogramowanie automatyzujące żmudną pracę urzędnika bankowego, tak istnieją też narzędzia automatyzujące żmudną pracę testera. Szczególną popularnością cieszą się od kilku lat programy typu zarejestruj odtwórz (capture - playback), pozwalające na automatyczne testowanie poprzez interfejs użytkownika. Takie narzędzia potrafią m.in. symulować pracę klawiatury i myszki, kontrolować poprawność tego, co pojawia się na ekranie. Nietrudno wyobrazić sobie, jakim usprawnieniem może być automatyczne wykonanie szeregu testów na przykład przy wdrożeniu nowej wersji systemu bankowego lub podczas instalacji aplikacji w wielu oddziałach tego samego banku. Kontrola instalacji wodnej pod ciśnieniem Oprogramowanie stosowane przez banki zwykle jest wykorzystywane przez wiele osób jednocześnie. W szczególnym przypadku banku internetowego można mieć do Strona 6 z 34

7 czynienia z dziesiątkami czy wręcz setkami tysięcy jednoczesnych użytkowników systemu. Każdy klient banku zna sytuację, kiedy załatwianie sprawy trwało dłużej, niż by się chciało, bo pracownik banku kilkakrotnie długo oczekiwał na odpowiedź komputera. Każdy menedżer banku dobrze wie, jakie są koszty sytuacji, gdy niedostateczne osiągi (czasy odpowiedzi) systemu powodują, że jego pracownicy są w stanie obsłużyć, dajmy na to, tylko połowę liczby transakcji, jaką mogliby załatwić mając do dyspozycji szybszy system. Jakie znaczenie ma dostępność i czasy odpowiedzi dla aplikacji internetowej, nikomu nie trzeba tłumaczyć. Co grosza, każda efektowna awaria serwera dużego systemu internetowego zwykle stanowi wydarzenie na tyle medialne, że pisze o nim prasa. Dlatego tak zwane testy wydajnościowe (testy osiągów, testy przepustowości) systemów bankowych są szczególnie ważne właśnie dla aplikacji bankowych. Czy można je wykonywać bez użycia narzędzi? Niełatwo - wyobraźmy sobie scenę, gdy np. 500 pracowników firmy zostaje w nadgodzinach, kierownik testów zamawia 500 pizz i cocacoli, po czym pada komenda wszyscy się wlogowują! Koszt mimo wszystko spory, precyzja wątpliwa, kontrola wyników dyskusyjna, powtarzalność zerowa. Nic dziwnego, że narzędzia do testów wydajnościowych sprzedają się jak ciepłe bułeczki. Według Annual Load Test Market Summary and Analysis 2003 (Newport Group, Inc.) rynek na tego typu narzędzia wynosił w 2003 roku 750 milionów dolarów, a jego wzrost w latach ponad 30% rocznie! Pozazdrościć, a kto wie, czy nie uwzględnić tego faktu przy podejmowaniu decyzji o lokacie oszczędności? Testy wydajnościowe pozwalają nie tylko stwierdzić, czy system spełnia wymagania, ale przede wszystkim umożliwiają poprawę osiągów, kiedy nie są spełnione. Znaczne oszczędności można osiągnąć, jeśli zastosować narzędzia ułatwiające dostrajanie systemu. Zamiast poprawiać osiągi poprzez kosztowne zakupy sprzętu (takie rozwiązanie wystarcza zresztą tylko na pewien czas), można zwykle uzyskać nawet wielokrotną poprawę osiągów odpowiednią konfiguracją systemu i serwerów. Pociągi pod specjalnym nadzorem Główną cechą Internetu jest zmienność i niepewność. System, nawet starannie przetestowany dla przewidywanego poziomu obciążenia, może zacząć zdradzać nieoczekiwane słabości, kiedy obciążenie wzrośnie ponad pewną granicę. Czas odpowiedzi systemu może nieoczekiwanie zacząć wzrastać nawet wykładniczo po przekroczeniu pewnego progu obciążenia. Aby mieć kontrolę obciążenia i osiągów używanego systemu i móc na czas reagować, gdy przestaje spełniać wymagania dostępności, konieczne jest monitorowanie systemów. Straty, bezpośrednie i pośrednie, jakie może spowodować choćby kilkugodzinna awaria systemu bankowego, trudno przecenić. Zapobiec im można, monitorując najważniejsze parametry systemu i uruchamiając automatyczne alarmy, gdy pojawiają się zwiastuny kłopotów. Ma to również znaczenie dla zapewnienia bezpieczeństwa systemu, o czym niżej. Szukanie dziury w całym Nie każdy się do tego przyznaje, ale zwykle jakość przelicza się na pieniądze. Znamy wszyscy firmy, które znakomicie prosperują mimo nie najwyższej jakości i niezawodności swych produktów. Oznacza to, że w tym segmencie rynku, gdzie działają, koszty bezpośrednie i pośrednie ewentualnych awarii są względnie niskie. Inaczej wygląda sytuacja w sektorze finansowym. Tutaj awarie zwykle kosztują tak dużo, że warto zainwestować w zapobieganie.. Strona 7 z 34

8 Szczególnie istotne jest zagadnienie bezpieczeństwa (security) systemu. Pod tym pojęciem rozumiemy zdefiniowanie poziomu ryzyka sytuacji, że osoba niepowołana może się do niego dostać, lub że użytkownik może dokonywać przy pomocy systemu operacji, do których nie ma uprawnień. Testowanie bezpieczeństwa to trudna sztuka, polegająca m.in. na szukaniu nadmiarowej funkcjonalności, czyli tego, co system robi, choć w świetle wymagań nie musi, a co często jest wykorzystywane jako nielegalne boczne wejście do systemu. Narzędzia nie zrobią za nas testów bezpieczeństwa, ale potrafią je ułatwić. Na przykład pełne przetestowanie wszelkich kombinacji identyfikatorów i haseł użytkowników, możliwe przy użyciu narzędzi nagraj-odegraj, pozwala zlikwidować wiele typowych błędów bezpieczeństwa. Wiele błędów bezpieczeństwa ujawnia się, gdy system jest przeciążony. Błędy te również łatwiej odkryć, gdy dysponujemy narzędziami pozwalającymi zarówno obciążyć system, jak i monitorować w tym czasie działanie jego poszczególnych elementów. Czego użytkownik nie lubi najbardziej? Nie lubimy (bo przecież każdy z nas jest od czasu do czasu użytkownikiem!), gdy programy traktują nas źle, arogancko, nie informują o swoim działaniu, gdy są nadmiernie gadatliwe lub przeciwnie gdy potrzebną nam informację skrzętnie ukrywają. Innymi słowami, gdy są nieprzyjazne użytkownikowi, niewygodne w użytkowaniu. Tradycyjnie systemy informatyczne lekceważyły użytkowników, a ci z pokorą przyjmowali niewygodę. Od kilku lat sytuacja zmienia się, zaś systemy internetowe wręcz ją odwróciły. Niekiedy ocenia się, że dla systemów internetowych użyteczność i osiągi są ważniejsze, niż funkcjonalność! Łatwość posługiwania się bankiem internetowym może już wkrótce dla pewnych grup klientów stać się kryterium wyboru banku. Użyteczność systemów ma także wpływ na ich bezpieczeństwo. Wyobraźmy sobie np. system, wymagający tylu różnych haseł, że zmusza prawie użytkowników do notowania ich na przylepianych do monitora karteczkach... Jakość jest za darmo Już w latach 70-ych napisano, że jakość jest za darmo w tym sensie, że koszty zapewnienia jakości w tym testowania są zwykle znacznie niższe niż koszty awarii spowodowanych brakiem testowania. Tam gdzie koszty awarii są szczególnie wysokie, nakłady na jakość i testowanie powinny być odpowiednio wyższe w przeciwnym razie oszczędności w projektach okażą się pozorne. Systemy informatyczne w bankowości zarządzają naszymi pieniędzmi, a chyba nikt nie chce, by jego pieniądze były zarządzane i pilnowane niedbale, wadliwie i nieskutecznie. Strona 8 z 34

9 Tekst sponsorowany OPTANE DLA ROZWIĄZAŃ SAP Optymalizacja rozwiązań SAP Aby sprostać unikalnym potrzebom przedsiębiorstw, każde wdrożenie zawiera własną kombinację procesów biznesowych i wymagań odnośnie infrastruktury. Aby uniknąć takich problemów, jak niemożność współdziałania architektur, ograniczona skalowalność, słaba wydajność serwera aplikacji i zakłócenia funkcjonalności, należy starannie przetestować aplikacje przed ich wdrożeniem, a następnie dostrajać i monitorować ich pracę w środowisku produkcyjnym. Setki klientów SAP z powodzeniem stosują rozwiązania BTO firmy Mercury do wdrażania, modernizacji i utrzymania swoich aplikacji. Ponadto, SAP stosuje pakiet Optane wraz z innymi rozwiązaniami do wewnętrznych testów swojego oprogramowania. W skład Optane for SAP Solutions wchodzą następujące moduły: TestDirector, QuickTest Professional, LoadRunner, ProTune oraz Topaz. JAK DZIAŁA OPTANE FOR SAP SOLUTIONS Optymalizacja aplikacji pod kątem ich gotowości do pracy, wydajności i dostępności ma podstawowe znaczenie, jeżeli mają one spełniać surowe i zmieniające się wymagania biznesowe. Optane Suite zapewnia wszystko, co jest potrzebne do zintegrowanego zarządzania fazą testową, wszechstronnych testów funkcjonalnych, testów pod obciążeniem, wdrożenia i zarządzania nieprzerwaną dostępnością. WSZECHSTRONNE TESTY GOTOWOŚCI APLIKACJI TestDirector tworzy i nadzoruje proces testowy, który umożliwia podjęcie decyzji, czy aplikacja SAP jest gotowa do wdrożenia. Szybko przekłada analizę procesu biznesowego na obszerny zestaw testów, składający się z ręcznych i zautomatyzowanych testów funkcjonalnych i testów regresywnych, a także ze scenariuszy pracy pod obciążeniem. Wszystkie wyniki testów związanych z projektem gromadzone są w jednym miejscu. Dzięki swojej otwartej architekturze TestDirector płynnie integruje się z aplikacjami do zarządzania cyklem eksploatacji od narzędzi do zarządzania konfiguracją po systemy pomocy. QuickTest Professional automatycznie przechwytuje i odtwarza interakcje użytkowników. W ten sposób umożliwia wychwycenie błędów, a procesy biznesowe przebiegają płynnie od samego początku. QuickTest Professional został zaprojektowany z myślą o takich rozwiązaniach, jak mysap Enterprise Portal, które integrują w sobie rozwiązania SAP z aplikacjami firm trzecich. QuickTest Professional może rejestrować, odtwarzać i weryfikować procesy biznesowe z wykorzystaniem interfejsu graficznego SAP do Windows lub za pomocą klientów HTML z możliwością personalizacji na bazie Javy Strona 9 z 34

10 i Microsoft.NET. Tak szerokie możliwości umożliwiają przedsiębiorstwom testowanie dowolnych połączeń różnych komponentów lub rozwiązań przemysłowych. Tekst sponsorowany Po zakończeniu fazy weryfikacji procesów biznesowych o krytycznym znaczeniu i stwierdzeniu, że pracują prawidłowo należy użyć modułu LoadRunner do testów obciążeniowych, wydajnościowych i testów skalowalności. LoadRunner to narzędzie testowe, które prognozuje zachowanie i wydajność systemu. Z poziomu pojedynczego punktu kontrolnego LoadRunner obejmuje swoim działaniem całą infrastrukturę, łącznie z graficznym interfejsem SAP do Windows lub klientami HTML, serwerami aplikacyjnymi i bazodanowymi oraz serwerami internetowymi. Emulując tysiące wirtualnych użytkowników LoadRunner mierzy wydajność transakcyjną systemów i prowadzi testy rozproszonych scenariuszy. DOSTRAJANIE APLIKACJI DO OPTYMALNEJ WYDAJNOŚCI Rozwiązanie ProTune umożliwia optymalizację aplikacji zarówno w fazie przygotowania, jak i w czasie eksploatacji. Dział informatyki może ocenić konfigurację aplikacji, a także dokonać kwantyfikacji ogólnej wydajności systemu. ProTune zawiera specyficzne dla aplikacji biblioteki komponentów testowych, monitory i tunery, które automatycznie dostosowują się do rzeczywistych środowisk biznesowych, takich jak mysap Enterprise Portal. Korzyść polega na zmniejszeniu całkowitego kosztu posiadania poprzez eliminację niepotrzebnych zakupów sprzętu i oprogramowania. PROAKTYWNE MONITOROWANIE DOSTĘPNOŚCI 24/7 Rozwiązanie Topaz umożliwia zarządzanie wszystkimi procesami biznesowymi o krytycznym znaczeniu w celu uzyskania maksymalnej i nieprzerwanej wydajności. Topaz zapewnia podgląd aplikacji w czasie rzeczywistym zarówno z punktu widzenia użytkownika, jak i informatyka. Definiując alarmy bazujące na procesach biznesowych informatycy mogą nadać działaniom naprawczym zróżnicowane priorytety, zależnie od tego, jakie grupy użytkowników zostały dotknięte awarią lub jaki jest wpływ awarii na ogólne działanie przedsiębiorstwa. INFORMACJE O FIRMIE MERCURY Mercury jest światowym liderem w zakresie optymalizacji technologii biznesowych (BTO). Pakiet rozwiązań Optane pomaga poprawiać jakość, obniżać koszty i dostosowywać technologię IT do wymagań biznesowych. Kontakt: Lubomir Stojek, Mercury, Strona 10 z 34

11 extreme TESTING (TESTOWANIE EKSTREMALNE) Lucjan Stapp Wydział Matematyki i Nauk Informacyjnych Politechnika Warszawska Lucjan Stapp Doktor nauk matematycznych (bo gdy robił doktorat nie było jeszcze doktoratów z informatyki). Wieloletni pracownik naukowy Politechniki Warszawskiej Wielokrotnie pracował też jako kierownik zespołów projektowych i zespołów zapewnienie jakości w dużych i małych projektach. Zwolennik lekkich metodyk, także w testowaniu. Strona 11 z 34

12 extreme TESTING (TESTOWANIE EKSTREMALNE) Lucjan Stapp Wydział Matematyki i Nauk Informacyjnych Politechnika Warszawska W ciągu ostatnich kilku lat metodologia extreme Programming (XP) zrobiła oszałamiająca karierę w inżynierii oprogramowania. Metodologia ta zaproponowana prawie pięć lat temu [1] dorobiła się własnej konferencji (już czwarta konferencja poświęcona tej metodologii odbyła się w maju 2003 w Genui). Zwolennicy tej metodologii wykorzystują też własną stronę internetową [5]. Jakie są podstawowe zasady extreme Programming? Każdy analityk wymieni bez namysłu kilka haseł: write test first: najpierw twórz testy. Zasada ta ma uzmysłowić programistom, że przed przystąpieniem do tworzenia fragmentu oprogramowania (klasy) należy przygotować sobie testy weryfikujące poprawność interfejsu dla projektowanej klasy pair programming : pisanie w parach. Jedna osoba w parze tworzy kod, druga ją wspomaga, zwracając szczególna uwagę na poprawność tworzonego kodu ścisła współpraca z odbiorcą: przez cały czas tworzenia aplikacji istnieje możliwość zweryfikowania założeń analitycznych przez uprawnionego przedstawiciela zleceniodawcy częste tworzenie kolejnych wersji aplikacji: po sprawdzeniu poprawności nowego fragmentu oprogramowania należy go dołączyć do tworzonego oprogramowania i sprawdzić działanie. Ken Beck ojciec metodologii XP w [2] proponuje jednak nieco inne podstawowe zasady tworzenia oprogramowania w metodologii XP: simplicity(prostota): eliminowanie wszystkiego co niepotrzebne przy produkcji oprogramowania, Tym samym przepływ informacji należy w maksymalnym stopniu na oprzeć na: communication (komunikacja): współpracy oparta o bezpośrednią wymianę informacji między programistami, analitykami i testerami, Musimy też zapewnić feedback (sprzężenie zwrotne): maksymalnie szybkie uwzględnianie uwag odbiorcy. Zapewni to: aggressiveness (ofensywność, przebojowość): szybka realizacja oprogramowania I te zasady są też podstawą extreme Testing (XT). XT jest pochodną XP, ma ułatwić i przyspieszyć testy przygodo-wywanej aplikacji. Jest to metodologia testów dla aplikacji przygotowywanych wg metodologii XP. Pierwsze pytanie, które należy w tym momencie postawić to pytanie o potrzebę testów aplikacji przygotowywanych w tej metodologii: przecież były one już sprawdzane ( write test first ). Rzeczywistość pokazuje, że programiści ograniczają się głównie do testowania poprawności tworzonych klas (np. przy użycie JUnit [6]). Testy integracyjne, akceptacyjne, nie wspominając już o testach wydajnościowych i testach bezpieczeństwa, pozostają w dalszym ciągu zadaniem zespołu testerów. Tym samym podstawowym zadaniem testera w XP są testy akceptacyjne odbiorcze dla kolejnej iteracji. Zgodnie z metodyką XP testowanie kodu modułów to zajęcie Strona 12 z 34

13 deweloperów, nie należy pozwolić, by zadanie to zostało przerzucone na testerów. Testerzy testują testy funkcjonalne (oraz wydajnościowe, integracyjne itp.). Są to testy typu grey box (pomiędzy white box i black box ). Innymi słowy tester XP głównie sprawdza zachowanie się całej aplikacji (jej kolejnej iteracji) metodą czarnej skrzynki, jednak przy wykryciu błędu stara się go zlokalizować analizując fragmenty kodu (testowanie typu white box ). Podstawowe zasady XT to: 1. najpierw należy stworzyć (zaprojektować) testy (I) należy zacząć jak najwcześniej (najpóźniej równolegle z deweloperami), lepiej, gdy można to zrobić podczas odbioru prac analitycznych (II) dążymy do maksymalnego zrozumienia testów nie należy zakładać wzajemnego zrozumienia się, w przypadku jakichkolwiek niejasności należy uszczegółowić problem 2. testy mają równy priorytet z tworzeniem kodu (I) w większości przypadków testy są spychane na sam koniec procesu produkcji oprogramowania, wielu projekt menadżerów zgadza się na skrócenie czasu poświęconego na testy. W XT ta zasada ma nie mieć zastosowania, bez pozytywnego przejścia wskazanych testów nie ma odbioru aplikacji (jej kolejnej iteracji) 3. dążenie do 100% pokrycie przypadkami testowymi (TC) wszystkich warstw systemu. 4. jasno określony cel testowania (I) pożądana jakość produktu; ponieważ nie można przetestować wszystkich możliwych przebiegów aplikacji, należy z góry określić te przebiegi które muszą bezwzględnie zachowywać się poprawnie; co więcej dopuszczamy nieprawidłowe zachowanie się aplikacji w pewnych sytuacjach. Przykładem może tu być układ klawiszy CTRL+ALT+DEL we wczesnych wersjach systemu Windows; użytkownicy zostali nauczeni, że po naciśnięciu tego układu klawiszy Windows zachowuje się niepoprawnie (kończy działanie). Tak więc czasem łatwiej jest nauczyć użytkownika końcowego odpowiedniego działania niż zbudować dostateczne zabezpieczenia w systemie. (II) satysfakcja odbiorcy (III) minimalizacja zmian w przeciwieństwie do XP nie należy codziennie testować przygotowywanej aplikacji, tu należy dążyć do otrzymywania z produkcji wersji pełnej (oczywiście ze względu na wskazaną funkcjonalność). (IV) akceptacja na podstawie z góry ustalonych funkcjonalnych testów akceptacyjnych w przypadku stwierdzenia innych błędów iteracja jest akceptowana, poprawianie to kolejna iteracja 5. testowanie parami (I) co dwie pary oczu to nie jedna (II) zwiększenie bezpieczeństwa testów a). mamy tu możliwość tworzenia różnych par testerów np. doświadczony niedoświadczony, znający problem biznesowy nowicjusz itp. b). należy zapewnić rotację testerów w parach, będzie to skutkowało zmniejszeniem zarządzania ryzykiem odejście dobrego testera nie skutkuje dużymi stratami w projekcie 6. dążenie do maksymalnego uproszczenia dokumentacji testowej (I) (II) podstawowymi metodami komunikacji i to zarówno w zespole testowym jak i między zespołem testowym a programistami ma być komunikacja werbalna i poglądowa. By to osiągnąć, należy wzmocnić współpracę testerów i deweloperów. Osiągnąć to można poprzez Strona 13 z 34

14 a). integracja zespołu poprzez częste spotkania (np. 2 razy w tygodniu lub krótka 5 10 minut odprawa raz dziennie) b). wzajemne przeglądy testów (testerzy sprawdzają testy deweloperów, deweloperzy uczestniczą w przygotowywaniu testów akceptacyjnych 7. automatyzacja testów: należy dążyć do maksymalnej automatyzacji testów. Ułatwia to i zdecydowanie przyspiesza testy regresji, które należy wykonać przy odbiorze kolejnej iteracji powstającej aplikacji. Należy jednak pamiętać o tym, by myśleć już o tworzeniu skryptów testowych już na etapie projektowania testów, jak najwcześniej należy też przystąpić do tworzenia tych skryptów. Ponieważ testy rozpoczynają się równocześnie z tworzeniem, więc początkowy okres nim zostaną wyprodukowane pierwsze fragmenty nadające się do testowania poświęcić na projektowanie i tworzenie skryptów testowych. Należy też zdawać sobie sprawę z faktu, że pomimo dość wysokiej ceny profesjonalnych automatów testowych wydatek ten zwraca się stosunkowo szybko. Przy niedużych projektach można stosować shareware owe lub freeware owe automaty testowe. Ich możliwości są zdecydowanie słabsze, ale i tak zdecydowanie przyspieszają proces testowania. 8. codzienne raportowanie stanu testów: (I) Zalecane jest stworzenie codziennie odświeżanej i dostępnej dla wszystkich prezentacji bieżącego stanu testów, najlepiej w postaci graficznej. Na tej prezentacji należy wskazać, które testy już przeszły (oznaczamy je np. kolorem zielonym),, które się zawaliły (na czerwono), których jeszcze nie można sprawdzać (na żółto). Zwiększanie się liczby zielonych wpływa mobilizująco także na zespól wykonawców. Prócz powyższych zasad obowiązują standardowe zasady tworzenia testów wydajnościowych. Należy tworzyć i uruchamiać je w najwcześniejszych możliwych fazach testowania. Należy także pamiętać o ciągłym refactoringu skryptów testowych i dodawaniu nowych TC zwłaszcza związanych z sytuacjami, gdy wykryto błąd spoza zakresu testów akceptacyjnych aktualnej iteracji. Czy XT jest uniwersalną metodologią testowania aplikacji? Odpowiedź brzmi zdecydowanie nie. By móc ją stosować należy sobie zapewnić co najmniej stosowanie podstawowych zasad XP przez zespól programistów. Co więcej, konieczny jest bezpośredni kontakt z odbiorcą aplikacji umożliwi to budowę rzeczywiście interesujących testów akceptacyjnych. Nawet przy najpełniejszej analizie zadania zawsze pozostają niedomówienia i niedookreślenia, które należy wyjaśnić na jak najwcześniejszym etapie prac. Wydaje się także, że metodologia ta ma zdecydowanie lepsze zastosowania przy tworzeniu programów o krótkich cyklach produkcyjnych (kilku lub kilkunastotygodniowych). Przy dłuższych cyklach produkcji zatraca się jasność sytuacji i bez bogatej dokumentacji (a tej w XT nie ma) trudno jest osiągnąć zamierzony cel. XT nie jest metodologią pozbawioną wad. W szczególności trudno się zgodzić z pkt. 5 nakazującym testowanie parami. Zwiększa to koszty testów, a wszystkie zalety można osiągnąć przez wymianę scenariuszy testowych między testerami ścisłą integrację zespołu testerów. Zdecydowanie trudno stosować też XT przy geograficznym rozproszeniu zespołu. Oczywiście współczesne środki komunikacji ułatwiają komunikację pomiędzy członkami zespołu, ale jednak nie jest to współpraca bezpośrednia. Strona 14 z 34

15 Niepokój budzi też akceptacja iteracji mimo znalezionych błędów. Każdy tester będzie starał się podciągnąć taki błąd pod istniejące scenariusze i wykazać jego istotność, bojąc się podejrzenia o niekompletność testów. Natomiast ciekawym pomysłem wydaje się określenie z góry jakości produktu i nie testowanie ścieżek wykraczających poza przyjęte kryterium. Wydaje się jednak, ze metodologia XT umożliwia przynajmniej częściowo realizację standardowego problemu testów: Które dwa z trzech czynników brać pod uwagę w procesie testowania: koszt czas jakość i jej dalszy rozwój powinien usprawnić i ułatwić proces testowania nowotworzonych aplikacji. Przy pisaniu powyższego artykułu korzystałem z następujących źródel: [1]. Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley Publish Co; 1999 [2]. Beck, K., Fowler, M., Planning Extreme Programming, Addison -Wesley Publishing Co; 2001 [3]. Berbet, T., Extreme testing, [4]. Jeffries, R., Anderson, A., Hendrickson, C., Extreme Programming Installed, Addison -Wesley Pub Co; 2001 [5]. [6]. [7]. Strona 15 z 34

16 Strona 16 z 34

17 Jakościowe pułapki Piotr Kałuski CGI Piotr Kałuski Jest absolwentem Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, kierunek informatyka. Od 1995 uczestniczył w wielu projektach informatycznych jako programista analityk, projektant i kierownik zespołu. Obecnie jest pracownikiem firmy CGI i jako konsultant jest członkiem zespołu System Test w firmie Polkomtel. Dziedzina jego zainteresowań to sposoby usprawnienia procesu testowania i wykorzystanie narzędzi Open Source w procesie wytwarzania i testowania oprogramowania. Szczegóły można znaleźć pod adresem Strona 17 z 34

18 Jakościowe pułapki Piotr Kałuski CGI 1. Wstęp nikt nie chce pisać złego kodu Są wśród informatyków tacy, których świadomość w kwestii jakości oprogramowania jest niska. Z drugiej strony nikt nie siada do klawiatury z intencją napisania złego kodu. Niestabilność i nieczytelność kodu, brak jasnej dokumentacji u większości informatyków wywołuje frustrację. Wszyscy chcemy pisać dobre oprogramowanie z dobrą dokumentacją. Jednak pomimo szczerych chęci osób zaangażowanych w projekty informatyczne, niezadowalająca jakość kodu i dokumentacji jest wciąż zmorą wielu firm. Przyczyn na pewno jest wiele i jest to temat godzien opasłego tomiska. Ja skupiam się na jednej, moim zdaniem, dość ważnej przyczynie. Odnoszę wrażenie, że wiele osób nie zdaje sobie sprawy z rzeczywistych kosztów związanych z implementacją procedur zapewnienia jakości powszechnie obecnych w opracowaniach na temat jakości oprogramowania. Świadomość rzeczywistych kosztów przychodzi dopiero w trakcie projektu, kiedy większość procedur jest już wdrożonych. Wycofanie się z nich i wdrożenie innych jest wtedy zbyt kosztowne. Z drugiej strony budżet projektu nie zawsze jest w stanie udźwignąć całego narzutu wnoszonego przez wybrane przez nas metody zapewnienia jakości. W efekcie zasady, których przestrzeganie jest fundamentem zapewnienia jakości, są przestrzegane połowicznie (bo na pełne przestrzeganie nie ma czasu ani pieniędzy), co prowadzi czasami do większego chaosu niż gdyby tych zasad nie było. Chcę być dobrze zrozumiany. Projekt, w którym nie ma żadnego systematycznego podejścia do zagadnienia jakości, jest z góry skazany na zagładę. Z drugiej strony procedury i narzędzia zapewnienia jakości podlegają tym samym podstawowym prawom, co inne narzędzia ich eksploatacja kosztuje. Kosztuje ich zakup (w przypadku oprogramowania niekoniecznie. Dla niektórych narzędzi istnieją nie gorsze, darmowe odpowiedniki), kosztuje ich utrzymanie, kosztuje ich eksploatacja, kosztuje czas potrzebny do przyuczenia innych jak tych narzędzi używać. Jako homo sapiens, potrafimy i powinniśmy korzystać z narzędzi. Ważne jest byśmy potrafili dobrać narzędzia na miarę naszych potrzeb i możliwości. Pozwolę sobie użyć porównania z usługami transportowymi. Nie każda firma świadcząca usługi transportowe może sobie pozwolić na zakup najnowocześniejszych samochodów. Jeżeli nie ma odpowiedniej bazy klientów to cena eksploatacji i ubezpieczenie może przekroczyć jej możliwości finansowe. Tego typu pułapek jest przy wytwarzaniu oprogramowania kilka. Ja chcę się skupić na niektórych aspektach dokumentacji, procedur i aplikacji narzędziowych. Następnie postaram się zasygnalizować, że nawet przy ograniczonym budżecie można odnieść sukces. Trzeba po prostu narzucić sobie pewne reguły, które oceniamy jako realistyczne i twardo się tych reguł trzymać. 2. Dokumentacja Temat rzeka. Właściwie, to w dużym uproszczeniu, można powiedzieć, że procedury zapewnienia jakości określają głównie: kto, kiedy i jaki ma napisać dokument. Ale, nawet bez czytania norm ISO przeciętny programista wie, jak ważna jest poprawnie spisana specyfikacja wymagań i dokumentacja implementacji z diagramami modułów. Trochę mniej programistów zdaje sobie sprawę z tego jak ważne jest, aby ta dokumentacja była napisana prostym i Strona 18 z 34

19 zrozumiałym językiem. Nie zmienia to faktu, że świadomość wagi dobrej dokumentacji jest powszechna. Dużo mniej powszechna jest świadomość, co tak naprawdę oznacza dobre, porządne wykonanie danego dokumentu. I jakie są związane koszty ze zrobieniem tego naprawdę dobrze. Oraz jakie są skutki zrobienia tego byle jak. Chcę tu zwrócić uwagę na kilka niebezpieczeństw. Ostrożnie z diagramami Doczesne miejsce w dokumentacji technicznej zajmują diagramy. Diagramy modułów w systemie jako całości, diagramy interakcji między obiektami, diagramy hierarchii klas, scenariusze itd. W niektórych sytuacjach kilka czytelnych diagramów potrafi przekazać więcej niż kilkanaście stron tekstu. Dlatego, przy tworzeniu czytelnej i zrozumiałej dokumentacji, diagramy są niezastąpione. Istnieje co najmniej kilka programów ułatwiających tworzenie prostych i czytelnych diagramów (włączając w to narzędzia do rysowania dostępne w Wordzie). Warto wybrać sobie narzędzie, które najbardziej nam pasuje i go używać. Podkreślam nic nie zastąpi czytelnego diagramu. Przy podejmowaniu decyzji o tworzeniu diagramu powinniśmy kierować się zdrowym rozsądkiem. Przestrzegam przed postanowieniami typu diagram dla każdego scenariusza, diagram dla każdego obiektu. Przyjęcie takich zasad spowoduje, że będą tracone godziny lub dni na diagramy ilustrujące rzeczy na tyle proste, że można je opisać w kilku linijkach tekstu. Diagram nie jest celem samym w sobie. Celem rysowania diagramu jest ilustracja rzeczy trudniejszych do opisania słowami. Nowoczesne narzędzia wychodzą nam tu naprzeciw, automatyzując tworzenie niektórych diagramów na podstawie definicji obiektów. Jednak opierając tworzoną dokumentację na dużej ilości diagramów (a będzie ich dużo, jeśli będziemy je tworzyć, dla np. każdego obiektu) musimy być świadomi kosztów ich wykonania oraz kosztów dbania o to, by były aktualne. Możemy skorzystać z programu, który bardzo pomaga przy rysowaniu takich obiektów. Takie programy nie tylko same rysują klocki z odpowiednimi atrybutami. Dają one możliwości tworzenia repozytorium obiektów i odwoływania się do diagramów danych obiektów z różnych dokumentów. Mówiąc ogólnie - pomagają zarządzać zagadnieniami i obiektami, które występują w projekcie. Musimy mieć jednak na uwadze kilka czynników. Trzeba pamiętać, że repozytorium obiektów w dużym projekcie często się zmienia. W związku z tym, ktoś musi tym administrować. Musi też istnieć jakiś sposób określania, które repozytorium odpowiada danej wersji oprogramowania. Wyobraźmy sobie następujący przykład. Mamy obiekt, który jest obecny na wielu diagramach. I ten obiekt się zmienia. Dochodzi nowa ważna metoda, bądź usuniętych jest 5 atrybutów. W związku z tym każdy dokument, który ma w sobie diagram z tym obiektem, musi zostać uaktualniony lub powinna zostać stworzona nowa wersja tego dokumentu. Już samo to zajmuje czas. A jak jeszcze są diagramy, które importują inne diagramy (np. za pomocą OLE) to uchowaj Boże. Używałem takiego narzędzia ze 4 lata temu. Zmiana głupiego obiektu zajmowała mi kilka dni, bo program działał wolno i się sypał. Ale 4 lata to dużo czasu. Dzisiaj takie rzeczy są bardziej stabilne. Jednakże narzut administracyjny pozostaje. I zależności między wersjami też. Pamiętajmy, że jeżeli bawimy się w repozytoria obiektów, to musimy się też bawić w administrowanie wersjami tych obiektów. W przeciwnym razie, będzie to bezwartościowe, bo każdy programista czy analityk, będzie się głowił, czy diagram, który widzi to jest akurat aktualna wersja. Oczywiście, są obiekty, których ilustracje, ze względu na ważność tych obiektów, muszą pojawić się w wielu dokumentach. Jeżeli zmieni się obiekt, który jest bardzo ważny w architekturze systemu, to wtedy nie ma wyjścia dokumentacja musi być uaktualniona. Jeżeli jednak w dokumentacji Strona 19 z 34

20 umieścimy szczegółowe diagramy obiektów poślednich, to skazujemy się na pracochłonne uaktualnianie prawie wszystkich dokumentów po każdym cyklu rozwoju oprogramowania. Dokumentacja użytkownika W bardzo wielu projektach dokumentację użytkownika piszą programiści. Nie piszą jej dlatego, że mają żyłkę do znajdowania najbardziej prostych opisów złożonych zjawisk. Ani nie piszą jej dlatego, że rozkoszują się zabawą słowem. Najczęściej, programiści piszą dokumentację, bo muszą. Jeżeli oczarowuje nas jakość dokumentacji tworzonej przez renomowane firmy, to proszę pozwolić, że opiszę jak wygląda proces jej wytwarzania. Zajmuje się tym osobny dział, składający się z ludzi, którzy potrafią dobrze pisać (pisać teksty do czytania a nie oprogramowanie). Ponieważ takim ludziom zdarza się nie znać od środka zagadnienia, o którym piszą, robią tak: na podstawie wymagań piszą pierwszą wersję. Potem dają tę wersję do przejrzenia programistom i testerom, którzy opisywaną funkcjonalność implementowali i testowali. Nanoszą oni uwagi i dokument jest poprawiany. Jeżeli trzeba, cykl jest powtarzany. A pod sam koniec, dokumentacja jest testowana (tzn. próbuje się wykonywać poszczególne funkcje programu kierując się instrukcjami z dokumentacji). Sami musimy ocenić czy nasz projekt na to stać czy nie (dotyczy to zwłaszcza niedużych projektów tworzonych przez małe i średnie firmy). 3. Narzędzia Po pierwsze narzędzia wspomagające proces testowania i zarządzania nim są drogie. Istnieją oczywiście darmowe narzędzia (Open Source) i wiele z nich ma bardzo dobrą reputację. Jednak wciąż pokutuje mit (moim zdaniem - fałszywy), że dla narzędzi Open Source nie ma wsparcia. Mit wzmocniony jeszcze propagandą firm komercyjnych (patrz FUD, Odstrasza to skutecznie wielu managerów. Po drugie musimy mieć na uwadze, że wbrew temu, co mówią często materiały marketingowe, korzystanie z narzędzi komercyjnych wcale nie jest proste. Nie jest proste skonfigurowanie ich w sposób w pełni odpowiadający naszym potrzebom. Nie jest także proste nauczyć się nimi efektywnie posługiwać. Każdy projekt ma swoje niuansiki i przystosowanie narzędzia do tych niuansików wymaga dużej wiedzy i czasu (albo pieniędzy na konsultanta, który to zrobi, (jeżeli to możliwe) i wystawi rachunek nie za rozwiązanie, lecz za spędzony w projekcie czas). Pamiętajmy, że znane pakiety dają nie tylko oprogramowanie narzędziowe. Dają one też metodologię, którą do jakiegoś stopnia będziemy musieli wdrożyć w projekcie. Uwzględnijmy to i dodajmy do kosztów licencji i wsparcia technicznego. Weźmy też pod uwagę, że wdrożenie nowego narzędzia w jednym departamencie, może za sobą pociągnąć konieczność wdrożenia tego narzędzia w departamentach współpracujących. Wtedy suma cen licencji zaczyna gwałtownie rosnąć. Komercyjne narzędzia nęcą też bardzo ciekawymi funkcjami, które zaimplementowane w projekcie, mogą rzeczywiście wnieść nową jakość do procesu. Bądźmy jednak czujni. Często się okazuje, że skorzystanie z tej funkcjonalności wymaga podporządkowania się pewnym regułom, które mogą być trudne lub prawie niemożliwe do spełnienia (przynajmniej w naszym projekcie). Ale tak nie musi być zawsze. Jeżeli uznamy jakąś funkcjonalność za pociągającą, sprawdźmy, co dokładnie musimy zrobić, aby móc z niej skorzystać. Może akurat w przypadku naszego projektu nie będzie trzeba zrobić wiele a zyski będą znaczące. Musimy to sami ocenić. 4. Zapewnianie jakości kodu Poza dbaniem o dobrą dokumentację, jakość można też podnieść wdrażając procedury polepszające proces kodowania. Chyba we wszystkich poważnych tekstach na temat tworzenia dobrego kodu jest jasno powiedziane, że najlepszą metodą jego weryfikacji, jest przejrzenie go przez innych. Nazywa Strona 20 z 34

21 się to code walkthrough lub code review (code walkthrough to analiza programu przez wykonanie go w myśli linia po linii). Bez wątpienia jest to metoda skuteczna, ale bardzo droga. Kod nie przejrzy się sam. Muszą na to poświęcić czas inni programiści. Żeby ich komentarze były coś warte, muszą mieć oni czas, aby "wgryźć" się w kod. W przeciwnym razie nie będą mieli do powiedzenia nic bardziej odkrywczego ponad to, że wcięcia im się nie podobają lub, że nazwa zmiennej jest myląca. Są też narzędzia typu Bounds Checker, które pozwalają badać kod w trakcie uruchomienia. Sprawdzają na przykład czy nie ma jakichś dziwnych alokacji lub dealokacji pamięci. Z cenami takich narzędzi jest różnie. BoundsChecker CompuWare kosztuje 800$. Nie mam doświadczenia z tym narzędziem, ale opinie, które znalazłem na jego temat są w przeważającej mierze pozytywne. Ja korzystałem z Rational Purify. Są też narzędzia Open Sourcowe tu też nie mam doświadczenia. Z tego co wiem nowe wersje kompilatorów i środowisk deweloperskich mają wbudowane tego typu narzędzia. Ogólnie oceniam, że nie jest to zła rzecz. Uruchomienie tego nie zajmuje znowuż tak dużo czasu, a uzyskane informacje są cenne. Należy jednak pamiętać o tym, że kod uruchamiany w takim trybie potrzebuje więcej zasobów komputera. Te jednak są tanie, więc warto się tym tematem zainteresować. 5. Planujmy uwzględniając nasze realne możliwości Zanim zaplanujemy, co będzie robione w projekcie, aby polepszyć jakość, zastanówmy się, na co nas stać. Weźmy pod uwagę budżet, ilość ludzi i terminy. Musimy też sobie uczciwie odpowiedzieć na pytanie czy implementujemy procedury zapewnienia jakości, bo chcemy być kryci przed zwierzchnikami lub czy dlatego że chcemy zwiększyć prawdopodobieństwo produkcji lepszego kodu. Jeżeli tylko chcemy być kryci, to właściwie nie widzę jakiś konkretnych barier dla naszej kreatywności. Możemy wymyślać, jakie tylko chcemy procedury. Programiści zapewnią, że to wszystko będzie działać. Będą tworzone na czas odpowiednie dokumenty, rysowane diagramiki, dostarczane będą rezultaty testów. To nic, że dokumentacja będzie bezwartościowa i niezrozumiała. To nic, że diagramy będą nieaktualne. To nic, że jak się przyjrzymy testom, to stwierdzimy, że są napisane tak, żeby zawsze przechodziły. I to nic, że oprogramowanie nie będzie działać. Przecież to nie o to w tym chodzi. Chodzi o możliwość wykazania, że trzymaliśmy się procedur. A programiści chętnie pomogą, bo zawsze znajdą sposób, żeby spełnić wymogi procedury. Każdej. Pamiętajmy: W obliczu deadline-u, wszystkie procedury mogą zostać ominięte i oszukane. Programista musi być tylko wystarczająco inteligentny i chcieć. A chcieć znaczy móc. A w obliczy perspektywy pracy w wariackich nadgodzinach, chęć pojawi się sama. Jeżeli jednak chcemy zrobić coś żeby produkt był lepszy to starajmy się unikać tworzenia zasad, które raczej na pewno będą łamane, bo będą nierealistyczne. Prawo, które musi być łamane jest demoralizujące. Starajmy się utworzyć zbiór zasad, które będę możliwe do spełnienia. Stawiajmy realistyczne wymagania i wtedy egzekwujmy je z całą bezwzględnością. 6. Sugerowane minimum Oto moje realistyczne minimum, będące wynikiem moich obserwacji w trakcie 8 lat pracy przy wytwarzaniu oprogramowania: Dobrze spisane wymagania Z biznesowego punktu widzenia, jest to jeden z najważniejszych dokumentów. To on opisuje, jaką funkcjonalność ma program zawierać. Powyżej przekonywałem, że niektóre rzeczy można sobie darować, bo są za drogie i nie wnoszą aż tyle, aby warto było ponosić koszty z nimi związane. Ale dobrze spisanych wymagań nie możemy sobie darować. I jeżeli zamierzamy oszczędzać na tworzeniu dokumentacji, to na tworzeniu wymagań powinniśmy starać się oszczędzić jak najmniej. Dobrze spisane wymagania mogą nas obronić przed Strona 21 z 34

22 żądaniami klienta, który twierdzi, że zrozumiał, że funkcjonalności będzie dwa razy więcej od tej, którą mu dostarczono. Źle spisane - są w statystykach źródłem największych strat finansowych w informatyce. Pisanie dobrych wymagań to bezcenna umiejętność i wielka sztuka, którą się zgłębia przez całe życie. Komentarze w kodzie Każda funkcja w kodzie powinna zawierać krótki opis co dana funkcja robi. Każdy moduł powinien mieć nagłówek, z krótkim opisem co dany moduł robi. (Wiem, wiem - to oczywiste. Wciąż jednak ta reguła nie jest przestrzegana, nawet w firmach przez duże F). Zrozumiała, krótka dokumentacja techniczna Do każdego większego modułu powinien istnieć odpowiedni, co najwyżej kilkustronicowy dokument. Powinien on przedstawiać - możliwie najprostszym językiem i używając klarownych ilustracji - funkcjonalność modułu. Stylem powinien bardziej przypominać opowiadanie niż specyfikację techniczną. Celem tego dokumentu jest danie osobie czytającej wyobrażenia do czego moduł tak naprawdę służy i na jakiej zasadzie działa. Jeżeli dokumentację czyta osoba nietechniczna, to ten poziom szczegółowości jest z zasady wystarczający. Jeżeli czyta ją programista i potrzebuje więcej szczegółów, może ich poszukać w kodzie źródłowym modułu. Jeżeli kod będzie miał te minimum komentarzy, o których mówię powyżej i programista będzie znał przeznaczenie i ogólne zasady działania modułu wtedy poruszanie się po kodzie będzie dużo łatwiejsze. System kontroli wersji. Istnieją co najmniej 2 darmowe, sprawdzone przez rzesze informatyków, narzędzia do kontroli wersji RCS i CVS. Nie znam żadnego racjonalnego powodu, żeby systemu kontroli wersji nie stosować. Znam za to szereg kataklizmów, jakie mogą być efektem nieużywania takich systemów. Stosujmy kontrolę wersji zarówno do kodu programu jak i do dokumentacji. Tylko po wdrożeniu tego minimum możemy zacząć myśleć o czymś bardziej zaawansowanym jak na przykład tworzenie szczegółowej dokumentacji technicznej czy też wdrożenie systemu zarządzania testami, automatyzacji testów etc. Jeżeli nie mamy zasobów do wdrożenia tego minimum to nasz projekt można porównać do spaceru po linie na przepaścią. Widzę 3 wytłumaczenia takiej sytuacji: Znaczny rozrost wymagań w trakcie projektu (scope creep) Ktoś planujący budżet projektu nie za bardzo się na planowaniu znał Ktoś planujący budżet projektu znał się na tym, ale planowane zyski ze zrealizowania projektu są tak wysokie, że zaakceptowano tak wysokie ryzyko. Warto mieć świadomość, że brak tego minimum jakości, czyni projekt misją wysoce ryzykowną wtedy, gdy w projekcie pracuje 4-5 osób. Dla projektów 10 i więcej osobowych jest to już po prostu misja samobójcza. Na koniec jeszcze drobna sugestia: Preferujmy komunikację ustną nad pisemną przy przekazywaniu wiedzy Nie utrudniajmy testerom dostępu do programistów. Żaden dokument nie zastąpi rozmowy ze specjalistą/autorem modułu, który odpowie nam na nasze pytania. Jeżeli jest Strona 22 z 34

23 dostępna zarówno dokumentacja jak i programista modułu, nie skazujmy testera na czytanie dokumentacji pisanej przez programistów, którzy traktują dokumentację jako dopust boży. Pozwólmy testerowi porozmawiać z programistą. 7. Życie nie jest takie proste... Dla większości uogólniających tez i rad istnieją kontrprzykłady i dziedziny gdzie te tezy są fałszywe a rady się nie stosują. Mój artykuł nie jest tu wyjątkiem. I to jest nieuniknione. Jak już zaznaczyłem, zagadnienia zapewnienia jakości są zbyt złożone, żeby je podsumować na kilku stronach. Zdaję sobie sprawę, że to co piszę może nie przystawać (przynajmniej wprost) do rzeczywistości niektórych projektów. Niestety, nie tylko my (wytwórcy oprogramowania) decydujemy o tym, jaka ma być dokumentacja. Czasami klient narzuca nam, co ma być tworzone. Warto mieć przynajmniej świadomość, jakie koszty pociąga za sobą tworzenie dokumentacji. Może jak się to uświadomi klientowi, to zrezygnuje on z części dokumentów. Niektórzy są na wyrafinowane procedury zapewnienia jakości skazani z definicji - systemy sterowania elektrownią jądrową, systemy wojskowe, NASA (której próby oszczędzania nie wyszły na dobre). Dla tych firm dokumentacja jest nie tylko informacją techniczną. Jest też dowodem przy wystąpieniu jakichkolwiek problemów. A koszty ewentualnej awarii są tak wysokie, że wielokrotnie przewyższają ogromne nakłady na zapewnienie jakości. Pomimo to wciąż jest wiele projektów, gdzie takich odgórnych wymogów nie ma. I wtedy warto mieć świadomość, jakie dana procedura zapewniania jakości niesie ze sobą narzuty. Czasami są one tak duże, że lepiej ją sobie darować, bo jej wdrożenie zje czas i budżet naszego projektu. Strona 23 z 34

Jakościowe pułapki. 1. Wstęp nikt nie chce pisać złego kodu. 2. Dokumentacja

Jakościowe pułapki. 1. Wstęp nikt nie chce pisać złego kodu. 2. Dokumentacja Jakościowe pułapki 1. Wstęp nikt nie chce pisać złego kodu Są wśród informatyków tacy, których świadomość w kwestii jakości oprogramowania jest niska. Z drugiej strony nikt nie siada do klawiatury z intencją

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

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

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

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

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

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

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

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

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

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

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

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

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

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

Zwrot z inwestycji w IT: prawda czy mity

Zwrot z inwestycji w IT: prawda czy mity Zwrot z inwestycji w IT: prawda czy mity Inwestycje w technologie IT 1 muszą podlegać takim samym regułom oceny, jak wszystkie inne: muszą mieć ekonomiczne uzasadnienie. Stanowią one koszty i jako takie

Bardziej szczegółowo

dr inŝ. Michał Tomaszewski Wydział Elektrotechniki, Automatyki i Informatyki Politechnika Opolska

dr inŝ. Michał Tomaszewski Wydział Elektrotechniki, Automatyki i Informatyki Politechnika Opolska dr inŝ. Michał Tomaszewski Wydział Elektrotechniki, Automatyki i Informatyki Politechnika Opolska Definicje Rola administratora w firmie Zadania administratora Szkolenia Rady, wskazówki Programiści ABAP

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

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl Testowanie według modelu (MBT) Bogdan Bereza, Victo MBT testowanie z modelu wersja 2.1 A 1 (48) Pozdrawiam Best regards Med vänliga hälsningar Bogdan Bereza bogdan.bereza@victo.eu +48 519 152 106 Skype:

Bardziej szczegółowo

Galileo - encyklopedia internetowa Plan testów

Galileo - encyklopedia internetowa Plan testów Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

KATALOG SZKOLEŃ CERTYFIKOWANYCH 2014

KATALOG SZKOLEŃ CERTYFIKOWANYCH 2014 KATALOG SZKOLEŃ CERTYFIKOWANYCH 2014 Szanowni Państwo! Misją testerzy.pl jest propagowanie testowania oprogramowania i zapewnienia jakości. Dostarczamy najwyższej jakości usługi i szkolenia dedykowane

Bardziej szczegółowo

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r. ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego

Bardziej szczegółowo

Inwestycja w robotyzację

Inwestycja w robotyzację ASTOR WHITEPAPER Inwestycja w robotyzację Analiza Przygotowanie inwestycji Realizacja inwestycji Wykorzystanie inwestycji krok po kroku 2 ASTOR WHITEPAPER INWESTYCJA W ROBOTYZACJĘ Jak efektywnie zainwestować

Bardziej szczegółowo

Myślicie Państwo o inwestycji w zakup nowej obrabiarki? Najbliższe 60 sekund może dać oszczędność sporej sumy pieniędzy!

Myślicie Państwo o inwestycji w zakup nowej obrabiarki? Najbliższe 60 sekund może dać oszczędność sporej sumy pieniędzy! Myślicie Państwo o inwestycji w zakup nowej obrabiarki? Najbliższe 60 sekund może dać oszczędność sporej sumy pieniędzy! Dobrze od samego początku Inteligentna praca to wielka różnica Dobry początek to

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

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

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

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

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

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

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

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

JAK TO DOBRZE ZROBIĆ 5-06-2013

JAK TO DOBRZE ZROBIĆ 5-06-2013 WDROŻENIA ROZWIĄZAŃ PROCESOWYCH: JAK TO DOBRZE ZROBIĆ 5-06-2013 Syndatis 2013 PLAN PREZENTACJI Trochę o Syndatis. Intensywność występujących zagrożeń w projekcie Wdrożenie rozwiązań procesowych - to nie

Bardziej szczegółowo

REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI

REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI WYTYCZNE DO MODELU DANIEL WOJEWÓDZKI Rekomendacje dotyczące Platformy Zarządzania Kompetencjami System adresowany do małych przedsiębiorstw do

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

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

Wdrożenie technologii procesowej IBM BPM w EFL

Wdrożenie technologii procesowej IBM BPM w EFL Wdrożenie technologii procesowej IBM BPM w EFL Marcin Naliwajko Z-ca dyrektora Departamentu Technologii Dominik Lisowski Starszy Architekt Systemów IT Grupy EFL WebSphere Message Broker 2008 r. Wdrożenie

Bardziej szczegółowo

Informatyka w kontroli i audycie

Informatyka w kontroli i audycie Informatyka w kontroli i audycie Informatyka w kontroli i audycie Wstęp Terminy zajęć 30.11.2013 - godzina 8:00-9:30 ; 9:45-11:15 15.12.2013 - godzina 8:00-9:30 ; 9:45-11:15 05.04.2014 - godzina 15:45-17:15

Bardziej szczegółowo

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl .firma Dostarczamy profesjonalne usługi oparte o nowoczesne technologie internetowe Na wstępie Wszystko dla naszych Klientów Jesteśmy świadomi, że strona internetowa to niezastąpione źródło informacji,

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

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

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

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

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

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

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) 1. Wstęp: 1.1. Cel. Niniejszy dokument przestawia specyfikację wymagań systemowych (zarówno funkcjonalnych jak i niefunkcjonalnych)

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

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Przyszłość to technologia

Przyszłość to technologia Przyszłość to technologia - twórz ją z nami Innowacyjne projekty dla prestiżowych klientów Wdrażamy jedne z największych w kraju projekty z dziedziny informatyki i nowoczesnych technologii. Realizujemy

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

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

Case studies - doświadczenia, dobre praktyki. Jarosław Żeliński analityk biznesowy, projektant systemów

Case studies - doświadczenia, dobre praktyki. Jarosław Żeliński analityk biznesowy, projektant systemów Case studies - doświadczenia, dobre praktyki Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań Od 1998 2004 doradca

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Informacje o wybranych funkcjach systemu klasy ERP Realizacja procedur ISO 9001

Informacje o wybranych funkcjach systemu klasy ERP Realizacja procedur ISO 9001 iscala Informacje o wybranych funkcjach systemu klasy ERP Realizacja procedur ISO 9001 Opracował: Grzegorz Kawaler SCALA Certified Consultant Realizacja procedur ISO 9001 1. Wstęp. Wzrastająca konkurencja

Bardziej szczegółowo

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów

Bardziej szczegółowo

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych

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

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

Scala Business Solutions Polska Sp. z o.o. Signature metodologia wdrażania Scali. Czego użytkownik potrzebuje najbardziej?

Scala Business Solutions Polska Sp. z o.o. Signature metodologia wdrażania Scali. Czego użytkownik potrzebuje najbardziej? Signature metodologia wdrażania Scali Scala to zintegrowany pakiet do zarządzania przedsiębiorstwem. O efektywności jego działania decyduje sposób właściwego wdrożenia, toteż gorąco zachęcamy wszystkich

Bardziej szczegółowo

Projektowanie systemu krok po kroku

Projektowanie systemu krok po kroku Rozdział jedenast y Projektowanie systemu krok po kroku Projektowanie systemu transakcyjnego jest ciągłym szeregiem wzajemnie powiązanych decyzji, z których każda oferuje pewien zysk i pewien koszt. Twórca

Bardziej szczegółowo

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan testów M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Zakres testów 3 2.1 Integration testing - Testy spójnosci.............. 3 2.2

Bardziej szczegółowo

Proces projektowania i wdrożenia serwisu internetowego

Proces projektowania i wdrożenia serwisu internetowego Proces projektowania i wdrożenia serwisu internetowego Kluczowe etapy projektu 9 1 Rozwój i optymalizacja Analiza celów, potrzeb i konkurencji 8 Szkolenie IMPROVE THINK Wireframe i prototyp (UX) 2 7 Testy

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

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

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

Kompleksowe wspieranie procesów zarządzania

Kompleksowe wspieranie procesów zarządzania Kompleksowe wspieranie procesów zarządzania Raport z badania przeprowadzonego w sierpniu 2007 roku O badaniu Badanie zostało przeprowadzone w sierpniu bieżącego roku na podstawie ankiety internetowej Ankieta

Bardziej szczegółowo

Darmowy fragment www.bezkartek.pl

Darmowy fragment www.bezkartek.pl Wszelkie prawa zastrzeżone. Rozpowszechnianie całości lub fragmentów niniejszej publikacji w jakiejkolwiek postaci bez zgody wydawcy zabronione. Autor oraz wydawca dołożyli wszelkich starań aby zawarte

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

Modele sprzedaży i dystrybucji oprogramowania Teoria a praktyka SaaS vs. BOX. Bartosz Marciniak. Actuality Sp. z o.o.

Modele sprzedaży i dystrybucji oprogramowania Teoria a praktyka SaaS vs. BOX. Bartosz Marciniak. Actuality Sp. z o.o. Modele sprzedaży i dystrybucji oprogramowania Teoria a praktyka SaaS vs. BOX Bartosz Marciniak Actuality Sp. z o.o. Prezes Zarządu Społeczeństwo informacyjne społeczeństwo, które znalazło zastosowanie

Bardziej szczegółowo

Dane Klienta: Staples Polska Sp. z o.o. Bysewska 18 80-298 Gdańsk www.staplesadvantage.pl

Dane Klienta: Staples Polska Sp. z o.o. Bysewska 18 80-298 Gdańsk www.staplesadvantage.pl Dane Klienta: Staples Polska Sp. z o.o. Bysewska 18 80-298 Gdańsk www.staplesadvantage.pl Staples Polska Sp. z o.o. (dawniej Corporate Express Polska Sp. z o.o.) to jeden z największych na świecie dostawców

Bardziej szczegółowo

Idea Bezpiecznej Maszyny w prostym podejściu. użyj Safety Evaluation Tool. Safety Integrated. www.siemens.pl/safety-evaluation-tool

Idea Bezpiecznej Maszyny w prostym podejściu. użyj Safety Evaluation Tool. Safety Integrated. www.siemens.pl/safety-evaluation-tool Idea Bezpiecznej Maszyny w prostym podejściu użyj Safety Evaluation Tool Safety Integrated www.siemens.pl/safety-evaluation-tool Safety Evaluation Tool jest częścią programu Safety Integrated opracowanego

Bardziej szczegółowo

Session Based Testing Czyli eksploracyjne testowanie w sesjach. Karolina Bilewska PapryQArz 16.09.2015

Session Based Testing Czyli eksploracyjne testowanie w sesjach. Karolina Bilewska PapryQArz 16.09.2015 Session Based Testing Czyli eksploracyjne testowanie w sesjach Karolina Bilewska PapryQArz 16.09.2015 AGENDA 1. Geneza SBT 2. Pojęcie SBT, zasady testów w sesjach 3. Jak zarządzać testami w sesjach? 4.

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

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

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

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

Komentarz. Pieniądze wielkie pieniądze

Komentarz. Pieniądze wielkie pieniądze Komentarz Pieniądze wielkie pieniądze Pieniądze wielkie pieniądze Jak donosi prasa branżowa, w pierwszym dniu po wdrożeniu nowego systemu bankomatów, akcje Kupakasi Bank na nowojorskiej giełdzie zyskały

Bardziej szczegółowo

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Małgorzata Barańska Wydział Informatyki i Zarządzania, Politechnika Wrocławska Beata Laszkiewicz Wydział

Bardziej szczegółowo

3 marca 2015 godz. 14:00 Buchalter Skłodowscy ul. Kościuszki 43, 05-270 Marki

3 marca 2015 godz. 14:00 Buchalter Skłodowscy ul. Kościuszki 43, 05-270 Marki 3 marca 2015 godz. 14:00 Buchalter Skłodowscy ul. Kościuszki 43, 05-270 Marki PATRONAT MERYTORYCZNY PATRONAT ORGANIZACYJNY Każda firma jest inna. Każdy zespół handlowy jest inny. Problemy w sprzedaży bardzo

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

Ś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

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Szkolenia Systemy Krytyczne. www.cts.com.pl

Szkolenia Systemy Krytyczne. www.cts.com.pl Szkolenia Systemy Krytyczne www.cts.com.pl CO TO SĄ SYSTEMY KRYTYCZNE? Systemy wbudowane (albo: systemy kontrolne) = embedded systems (control systems), systemy krytyczne dla bezpieczeństwa = safety-critical

Bardziej szczegółowo

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji 2012 Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji Niniejszy przewodnik dostarcza praktycznych informacji związanych z wdrożeniem metodyki zarządzania ryzykiem w obszarze bezpieczeństwa

Bardziej szczegółowo

mtim Dedykowane aplikacje mobilne dla TIM S.A.

mtim Dedykowane aplikacje mobilne dla TIM S.A. mtim Dedykowane aplikacje mobilne dla TIM S.A. O TIM TIM S.A. jest jednym z największych dystrybutorów artykułów elektrotechnicznych w Polsce. 25 lat w branży, z czego 17 lat na Giełdzie Papierów Wartościowych

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

TELEMEETING ZAMAWIANY BLISKI KONTAKT NA ODLEGŁOŚĆ PROFESJONALNE ROZWIĄZANIE TELEKONFERENCYJNE

TELEMEETING ZAMAWIANY BLISKI KONTAKT NA ODLEGŁOŚĆ PROFESJONALNE ROZWIĄZANIE TELEKONFERENCYJNE TELEMEETING ZAMAWIANY BLISKI KONTAKT NA ODLEGŁOŚĆ PROFESJONALNE ROZWIĄZANIE TELEKONFERENCYJNE CZYM JEST TELEMEETING? Telemeeting to innowacyjna usługa telekonferencyjna, która umożliwia prostą, szybką

Bardziej szczegółowo

BAKER TILLY POLAND CONSULTING

BAKER TILLY POLAND CONSULTING BAKER TILLY POLAND CONSULTING Wytyczne KNF dla firm ubezpieczeniowych i towarzystw reasekuracyjnych w obszarze bezpieczeństwa informatycznego An independent member of Baker Tilly International Objaśnienie

Bardziej szczegółowo

GLOBAL4NET Agencja interaktywna

GLOBAL4NET Agencja interaktywna Sklep internetowy Magento dla Rotom Polska Strona1 System B2B dla Rotom Polska Rotom jest jednym z czołowych dystrybutorów palet drewnianych, opakowań oraz nośników logistycznych dla przedsiębiorstw w

Bardziej szczegółowo

REUSPro SYSTEM MONITORUJĄCY ZUŻYTE MEDIA. REUS Polska Sp. z o.o. Naszą misją jest poprawianie. efektywności użytkowania energii

REUSPro SYSTEM MONITORUJĄCY ZUŻYTE MEDIA. REUS Polska Sp. z o.o. Naszą misją jest poprawianie. efektywności użytkowania energii REUSPro SYSTEM MONITORUJĄCY ZUŻYTE MEDIA REUS Polska Sp. z o.o. Naszą misją jest poprawianie efektywności użytkowania energii w obiektach naszych klientów poprzez zastosowanie ekonomicznie dochodowych

Bardziej szczegółowo

WYJAŚNIENIA NR 2 TREŚCI SIWZ

WYJAŚNIENIA NR 2 TREŚCI SIWZ CPI-ZZP-2244-40-495/13 Warszawa, dnia 24 stycznia 2013 roku Wykonawcy, którzy pobrali SIWZ w postępowaniu nr 40-CPI-ZZP-2244/12 Działając na podstawie art. 38 ust. 1a, ust. 2 i ust. 4 w zw. z art. 12a

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

Zwiększenie efektywności Działu Ekspedycji

Zwiększenie efektywności Działu Ekspedycji Zwiększenie efektywności Działu Ekspedycji Analiza na przykładzie Spółdzielni Piekarsko Ciastkarskiej w Warszawie Warszawa, Lipiec 2013 Spółdzielnia Piekarsko Ciastkarska w Warszawie SPC to największy

Bardziej szczegółowo

System CMMS Profesal Maintenance wspiera prace UR w firmie MC Bauchemie

System CMMS Profesal Maintenance wspiera prace UR w firmie MC Bauchemie System CMMS Profesal Maintenance wspiera prace UR w firmie MC Bauchemie Firma MC Bauchemie Firma MC Bauchemie w Środzie Wielkopolskiej to wyspecjalizowany zakład produkcyjny dodatków do betonu, produktów

Bardziej szczegółowo

Do kogo skierowany jest system obiegu dokumentów?

Do kogo skierowany jest system obiegu dokumentów? 9 Obieg dokumentów Do kogo skierowany jest system obiegu dokumentów? Dla kogo? Obsługa rosnącej liczby faktur, umów, czy korespondencji wymaga coraz większych nakładów pracy. Dzięki wdrożeniu sprawnego

Bardziej szczegółowo

Referat pracy dyplomowej

Referat pracy dyplomowej Referat pracy dyplomowej Temat pracy: Wdrożenie intranetowej platformy zapewniającej organizację danych w dużej firmie na bazie oprogramowania Microsoft SharePoint Autor: Bartosz Lipiec Promotor: dr inż.

Bardziej szczegółowo