Program Konferencji Testwarez 2012

Transkrypt

1 CORE Nº Jak zaprogramować bota? Poradnik dla początkujących Marcin Mrowiński Ocena procesów testowych z wykorzystaniem modelu TMMi Piotr Piotrowski Tester w projektach metodologii Agile 10 przykazań testera Program Konferencji Testwarez październik, Poznań Tomasz Olszewski

2

3 Wprowadzenie Testowanie oprogramowania INDEX 04 Redakcja Od redakcji Inżynieria oprogramowania 05 Ocena procesów testowych z wykorzystaniem modelu TMMi Piotr Piotrowski Jak zaprogramować bota? Poradnik dla początkujących Marcin Mrowiński Zaproszenie do udziału w V edycji cyklu wydarzenia BAF, Warszawa, grudnia Wirtualizacja aplikacji zwiększa produktywność oraz ułatwia testowanie i wdrażanie współczesnych systemów IT Marek Kucharski 24 Tester w projektach metodologii Agile 10 przykazań testera Tomasz Olszewski Program konferencji Testwarez Proces wyboru narzędzia do zarządzania testowaniem Radosław Smilgin Numer specjalny c0re

4 Wprowadzenie Redakcja Kwartalnik c0re (4 numery w roku) jest wydawany przez gasq Service GmbH. Od redakcji Redaktor naczelny: Karolina Zmitrowicz karolina.zmitrowicz@coremag.eu Witamy w nowym numerze magazynu c0re. Ponadto, zapraszamy do udziału w tegorocznej edycji Redakcja w składzie: Bartłomiej Prędki bartłomiej.predki@coremag.eu Krzysztof Chytła krzysztof.chytla@coremag.eu W tym numerze polecamy: Tester w projektach metodologii Agile. 10 przykazań testera - konferencji Testwarez - liczymy na Waszą obecność w Poznaniu! Uczestników konferencji, oraz Współpraca: Dariusz Paczewski dariusz.paczewski@coremag.eu Michał Figarski Robert Kuźmiak Piotr Piotrowski Tomasz Olszewski o zasadach obowiązujących w testowaniu w projektach zwinnych. Ocena procesów testowych z wykorzystaniem modelu TMMi osoby zainteresowane, informujemy również, że pod koniec października przedstawimy Wam numer specjalny c0re, poświęcony Testwarez - a w nim artykuły na bazie prelekcji. 04 Adres korespondencyjny: C0RE Magazine c/o gasq Service GmbH Kronacher Straße Bamberg Germany Piotr Piotrowski w kontynuacji tematyki o modelu dojrzałości procesu testowego. Życzymy miłej lektury! Redakcja Dział reklamy: info@coremag.eu WWW: Wszystkie znaki firmowe zawarte w piśmie są własnością odpowiednich firm. Prawa autorskie: Wszystkie opublikowane artykuły są objęte prawem autorskim autora lub przedsiębiorstwa. Wykorzystywanie w innych publikacjach, kopiowanie lub modyfikowanie zawartości artykułu bez pisemnego upoważnienia autora jest zabronione. Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: redakcja@coremag.eu

5 Inżynieria oprogramowania Ocena procesów testowych z wykorzystaniem modelu TMMi Autor: Piotr Piotrowski O Autorze: Pracownik wiedzy, Inżynier, Badacz, Działacz. Inżynier Testów w przedsiębiorstwie Tieto Poland, gdzie zajmuje się m. in. czynnościami testowymi w przemyśle motoryzacyjnym. Posiada doświadczenie głównie w dziedzinie: badań i rozwoju, telekomunikacji, informatyki, jakości i samoprzywództwa. Jest członkiem i/lub wspiera około czterech organizacji non-profit. Uczestniczył w rozmaitych projektach i przedsięwzięciach, głównie międzynarodowych, w tym naukowych. Posiada zaawansowany stopień rozwoju osobistego należy do górnych 21% populacji. Uzyskał bardzo wysokie miejsce w krajowym programie edukacyjnym dla kadry menedżerskiej i wygrał jedną z edycji krajowego konkursu o prestiżową praktykę. Zdobył łącznie około czterdziestu certyfikatów z: zarządzania, angielskiego oraz testowania oprogramowania. Jest autorem pewnych rozwiązań wdrożonych w biznesie, dwóch zgłoszeń patentowych, ponad 25 artykułów i 1 monografii. Posiada wykształcenie w: zarządzaniu (niezależne opanowanie programu doktoratu z administracji biznesu), technologii (zaliczone trzy lata doktoratu z telekomunikacji). Zainteresowania to: rozwój osobisty, działalność naukowa i wiele innych. Singiel, dwie siostry. Autor pragnie podziękować organizacji TMMi Foundation za zgodę na nieodpłatne użycie dokumentów pochodzących z tejże organizacji, wykorzystanych przy pracy nad artykułem. Streszczenie Artykuł dostarcza odpowiedzi, jak zorganizować, przeprowadzić i udokumentować ocenę procesów testowych według modelu TMMi, dostępnego wraz z towarzyszącymi dokumentami i innymi informacjami do pobrania ze strony organizacji TMMi Foundation ( której celem jest usprawnianie procesów testowych. Typy oceny procesów testowych Wynik oceny (ang. assessment) procesów testowych jest jedną z danych źródłowych wykorzystywanych przy usprawnianiu tychże procesów. Ocenę przeprowadza się względem określonego modelu procesów testowych. Modele tego typu są wypracowywane przez organizacje, które korzystają z dorobku wielu firm, instytucji naukowych i indywidualnych ekspertów. Zakres przeprowadzanej oceny można rozpatrywać 05

6 06 Inżynieria oprogramowania dwuwymiarowo - jako liczbę jednostek organizacyjnych danego przedsiębiorstwa podlegających ocenie oraz zastosowany w ocenie fragment modelu procesów testowych. Po ustaleniu zakresu oceny ustala się, kto poniesie jej koszty. Jednym z modeli procesów testowych jest TMMi (ang. Test Maturity Model integration), w którym na podstawie wytycznych organizacji TMMi Foundation [TAM09 - Zgoda na wykorzystanie dokumentu [TAM09] od TMMi Foundation.] istnieją dwa typy oceny procesów testowych z wykorzystaniem modelu TMMi: nieformalny, który można nazwać samooceną (ang. self-assessment) dokonywaną przez przedsiębiorstwo własnymi siłami, bez zewnętrznego akredytowanego asesora, przy użyciu niewielkiej liczby zaangażowanych osób. Ma ona charakter szybkiego sprawdzenia bez punktowania względem modelu TMMi. Wykorzystuje się tu wywiady z załogą lub dokumenty organizacyjne albo informacje pochodzące od klientów, formalny, określany, jako ocena z użyciem zewnętrznych przedsiębiorstw, z których pochodzą co najmniej dwaj akredytowani asesorzy oraz środki do oceny w postaci formularzy, czy oprogramowania. Pojawiają się tu także: punktowanie względem modelu TMMi, wykazanie silnych i słabych stron, analiza luk w procesach. Obowiązkowe są także wywiady z załogą oraz użycie dokumentów powstałych w przedsiębiorstwie. W zależności od potrzeb biznesowych danego przedsiębiorstwa można również opracować ocenę mieszaną, stosującą część zasad oceny formalnej i nieformalnej, określonych w dokumencie [TAM09]. Przy podejmowaniu decyzji o typie oceny procesów testowych bierze się pod uwagę czynniki takie jak: cele biznesowe (potrzebę uzyskania oficjalnego certyfikatu zgodności z modelem TMMi, wymagania klientów), zakres i czas oceny (jeden lub więcej całych poziomów dojrzałości TMMi, czy określone Specyficzne Praktyki modelu TMMi), umiejętności przeprowadzania oceny (stopień znajomości modelu TMMi i wytycznych organizacji TMMi Foundation w zakresie przeprowadzania oceny, obiektywizm i dokładność oceny), stopień rozwoju organizacji, w której odbywa się ocena (obecność zarządzania procesowego w organizacji, nastawienie członków organizacji do ocen zgodności z modelami procesów), ryzyko nieefektywności oceny (stopień wykorzystania wyników oceny do późniejszych usprawnień procesów testowych). Podsumowując, ocena formalna oferuje więcej gotowej wiedzy eksperckiej, specjalistycznych narzędzi, oficjalne poświadczenie certyfikatem i jest droższa od oceny nieformalnej, natomiast drugi z wymienionych typów może poprzedzać pierwszy. Przygotowanie do oceny Nazwa poziomu Procentowy zakres punktacji Po pierwszym, krótkim zapoznaniu decyzyjnych członków organizacji z pomysłem dokonania oceny procesów testowych z wykorzystaniem modelu TMMi i uzyskaniu ich wstępnej akceptacji, należy zorganizować dłuższe spotkanie, na którym zostaną przedyskutowane szczegóły związane z wyborem typu i przyjętą postacią oceny. Następnie przygotowuje się plan oceny, który zawiera [TAM09]: cel oceny zawierający odpowiedź na pytanie dlaczego przeprowadza się ocenę? Pomaga on nie zgubić kierunku oceny oraz wpływa na inne elementy planu, zakres oceny można w nim określić, które części modelu TMMi będą Opis poziomu zgodność procesu z modelem TMMi N (Not Achieved) 0 15% Brak zgodności lub niewielka zgodność P (Partially Achieved) 15 50% Częściowa zgodność proces ze znaczącymi słabościami, niekompletny, nierozpowszechniony, niezgodny z przeznaczeniem lub rezultatami L (Largely Achieved) F (Fully Achieved) NA (Not Applicable) 50 85% Znacząca zgodność proces systematyczny i rozpowszechniony. Pewne niewielkie słabości w: upowszechnieniu, zastosowaniu i rezultatach % Jednoznaczna zgodność proces systematyczny i rozpowszechniony. Brak oczywistych słabości w: upowszechnieniu, zastosowaniu i rezultatach. - Proces nie jest do zastosowania w organizacji i jest wyłączony z końcowych wyników oceny NR (Not Rated) - Proces nie jest punktowany z uwagi na brak obiektywnych danych służących do tego celu Tabela 1. Skala pomiarowa punktacji dla oceny z wykorzystaniem modelu TMMi [TAM09].

7 Inżynieria oprogramowania wykorzystywane jako odniesienie, jakie części organizacji zostaną poddane ocenie, ograniczenia oceny wynikają one z dostępności określonych zasobów, np. finansowych do pokrycia kosztów oceny, przewidywanego czasu oceny, poufności określonych informacji, wyłączenia pewnych części przedsiębiorstwa spod oceny, metodę oceny należy tu przemyśleć również techniki najbardziej odpowiadające danej firmie, Punktacja Obszaru Procesu Punktacja Celi Not Rated Cele Ogólne GG1 Fully Achieved GG2 Not Rated Cele Specyficzne SG1 Largely Achieved SG2 Not Achieved SG3 Partially Achieved SG4 Not Applicable NR F NR L N P NA kryteria kompetencji asesora zależne przede wszystkim od obranego typu oceny, czynności spis czynności pozwalający przeprowadzić ocenę w zakładanej formie, osiągnąć pożądany zakres wyników, zasoby - zwyczajowo należy określić zespół biorący udział w procesie oceny, dokonać rezerwacji pokojów, itp., harmonogramy data, czas, lokalizacja, lista uczestników: spotkań, wywiadów, sesji zbierania danych, prezentacji rezultatów, odpowiedzialności dla sponsora oceny, czyli osoby należącej do struktury przedsiębiorstwa, dostarczającej zasobów, lidera wyzwalającego zapał uczestników oceny, weryfikującej kompetencje asesorów, opracowującej harmonogram oceny, głównego punktu kontaktu udzielającego informacji o ocenie, odpowiedzialnej za odebranie rezultatów oceny, będącej właścicielem danych używanych do oceny; dla lidera zespołu oceniającego zajmującego się zarządzaniem pracą zespołu oceniającego, obecnego przy omawianiu kwestii związanych z planowaniem i punktowaniem, prezentującego rezultaty sponsorowi, raporty o asesorach i wyniki formalnej oceny organizacji TMMi Foundation [co określa document TMMi Data Submission Requirements (DSR) [DSR09]], odpowiada za bezpieczne przechowywanie informacji i danych o audycie przez 3 lata; dla członka zespołu oceniającego uczestniczącego w planowaniu, wywiadach z członkami ocenianej organizacji w charakterze prowadzącego wywiad lub skryby, punktowaniu, w tym, dochodząc do konsensusu w kwestii punktowania z co najmniej jednym innym asesorem, GG Generic Goal Cel Ogólny [Cele Ogólne, w przeciwieństwie do Specyficznych, są powtarzane w wielu miejscach modelu TMMi], SG Specific Goal Cel Specyficzny. Tabela 2. Przykład końcowego wyniku punktacji dla Obszaru Procesu wynikającego z punktacji składowych Celi opracowanie własne. kryteria sukcesu odnoszone względem stopnia wykonania planu oceny, zamierzone wyniki oceny muszą zawierać minimalny zbiór określony przez daną metodę oceny. Przykłady danych wyjściowych to: data, dane wejściowe, identyfikacja metody przeprowadzania oceny i procesów poddanych ocenie, wartości punktacji oraz opisy jakościowe. Plan oceny można poddać dyskusji na kolejnym spotkaniu, którego celem jest ostateczne uzgodnienie wszystkich kwestii potrzebnych do przeprowadzenia oceny w formie pożądanej przez dane przedsiębiorstwo. Przeprowadzanie oceny Przed właściwym elementem przeprowadzania oceny, jakim jest punktowanie poszczególnych procesów testowych, zbiera się według ustalonych zasad dane, które będą poddane ocenie. Dane te muszą spełniać dwa podstawowe wymagania być poufne i nie wskazywać na konkretną osobę. Metody pozyskania danych to: poufne dostarczenie dokumentów związanych z danym procesem, poufny wywiad z osobami uczestniczącymi w danym procesie, dystrybucja i poufne zebranie kwestionariuszy od ludzi zaangażowanych w danych proces, poufne zbadanie satysfakcji klientów danych organizacji. Skala pomiarowa punktacji przy ocenie z wykorzystaniem modelu TMMi zawiera kilka poziomów widocznych w Tab. 1 Podstawowe zasady dla agregowanych, końcowych wyników punktacji są następujące: wypadkowa punktacja całego poziomu dojrzałości modelu TMMi jest równa najniższej punktacji jednego ze składowych Obszarów Procesów, wypadkowa punktacja całego Obszaru Procesu TMMi jest równa najniższej punktacji jednego ze składowych Specyficznych lub Ogólnych Celów, wypadkowa punktacja całego Celu modelu TMMi jest oparta na punktacji wszystkich składowych Praktyk, zasady wypadkowego punktowania Praktyki modelu TMMi oraz pozostałe zasady punktacji są określone w przyjętej metodzie oceny. Komentarz do Tab. 2 jest następujący w tabeli zawarto różne oceny Celi modelu TMMi składających się na dany Obszar Procesu. Końcowa punktacja Obszaru Procesu wynosi NR, ponieważ ważne jest to, że cały Obszar Procesu nie może 07

8 Inżynieria oprogramowania 08 być punktowany z uwagi na brak punktacji choćby jednego Celu. Poza tym wynik NA innego z Celów świadczy o wyłączeniu go z oceny i nie służy decyzji o punktacji całego Obszaru Procesu. Załóżmy, że w Tab.2 wykreślamy wiersze z ocenami Celi w postaci NR i NA, wtedy końcowa ocena całego Obszaru Procesu wyniosłaby N. Jedną z kluczowych kwestii jest sumienność punktowania elementów składowych modelu TMMi także przez asesorów pochodzących z wnętrza danego przedsiębiorstwa. Postawa taka jest pomocna przy uzyskiwaniu dokładnych, prawdziwych, końcowych ocen elementów modelu, które służą wyciąganiu realnych wniosków w zakresie późniejszego usprawniania procesów testowych. Poza tym asesor, który sumiennie wykonał swoją pracę, potencjalnie łatwiej obroni jej wyniki, zwłaszcza przed zarzutami o ich zaniżenie. Przykładowo w zakresie części Specyficznych Praktyk odnoszących się do dokumentu strategii testów, należy wziąć pod uwagę nie tylko obecność samego dokumentu i od razu zakładać jednoznaczną zgodność (F), lecz także sprawdzić kompletność tegoż dokumentu w zakresie punktów i ich zawartości, nie wspominając o realnym zastosowaniu dokumentu strategii testów w organizacji i tym, że zapisy w dokumencie w dokumencie powinny być zbieżne z tym, czym się zajmuje w rzeczywistości dane przedsiębiorstwo, a i czy sama firma realizuje zapisy w dokumencie oraz jak te postulaty mają się do modelu TMMi, czy dalej, do innych praktyk wypracowanych przez międzynarodowe środowisko. Opracowanie wyników oceny Zasadniczym wynikiem opracowania wyników oceny jest raport z oceny, który posiada uzgodniony wcześniej format, zawierający: datę oceny, pięć pierwszych, wymienionych powyżej, elementów planu oceny: cel, zakres, ograniczenia, metodę oceny, kryteria kompetencji asesora, listę elementów związanych z pozyskiwaniem danych, takich jak np. użyte kwestionariusze, całe wypracowane punktowanie obowiązkowo dla formalnego typu oceny. Czynności związane z analizą sporządzonego raportu i wyciąganiu wniosków są podwaliną usprawniania procesów testowych. Propozycja podejścia do usprawniania procesów testowych jest opisana w Obszarze Procesu 5.3 modelu TMMi o nazwie Test Process Optimization, należącym na najwyższego poziomu dojrzałości modelu TMMi, czyli 5-tego. Podsumowanie Dane przedsiębiorstwo może spróbować własnych sił w badaniu procesów testowych pod kątem zgodności z modelem TMMi, ponieważ model i metoda badawcza są dostępne nieodpłatnie do użytku wewnętrznego. Formalny typ badania przeprowadzają natomiast akredytowane firmy i aseso- Literatura [DSR09] TMMi Data Submission Requirements (DSR). Version 1.0. Produced by the TMMi Foundation. Copyright TMMi Foundation, Ireland [TAM09] TMMi Assessment Method Application Requirements (TAMAR). Version 2.0. Produced by the TMMi Foundation. Copyright TMMi Foundation, Ireland [TMM12] Test Maturity Model integration. Release 1.0. Produced by the TMMi Foundation. Copyright TMMi Foundation, Ireland. downloads/tmmi/tmmi%20framework. pdf rzy przy użyciu akredytowanych metod, których listę można znaleźć na stronie w sekcji Suppliers (pol. Dostawcy), gdzie widać również, że ocena przedsiębiorstw sięgnęła już 4-tego poziomu dojrzałości modelu TMMi, spośród wszystkich 5-ciu poziomów definiowanych przez model. Podstawowe zasady oceny są podobne jak przy posługiwaniu się innymi modelami procesów, takimi jak CMMi. Stanowi to dobrą opcję dla przedsiębiorstwa, które ma związki z CMMi i chciałoby, dokładniej niż w modelu CMMi, zbadać procesy testowe.

9 Inżynieria oprogramowania Jak zaprogramować bota? Poradnik dla początkujących Autor: Marcin Mrowiński O Autorze: Absolwent Politechniki Szczecińskiej, na Wydziale Elektrycznym. Inżynier oprogramowania z kilkuletnim doświadczeniem, zawodowo zajmujący się tworzeniem aplikacji pod platformy Embedded, przy wykorzystaniu języka C++ 09 Pracownik międzynarodowej firmy IT z branży nowoczesnych technologii, obecnie w roli kierownika technicznego dla domeny Entertainment. Hobby: gry retro, gra na gitarze, język japoński oraz programowanie. Kontakt z autorem: marcin.mrowinski@gmail.com Zamiast wstępu Okres urlopowy dobiega końca i programiści wracają do pracy nad projektami komercyjnymi. Mój artykuł, trochę przewrotnie, ma za zadanie skierować uwagę developerów z powrotem na obszar miły i rozrywkowy, jakim są gry komputerowe. Gry powinny otwierać gracza na różnorodne zadania, zmierzające w rezultacie do osiągania kolejnych etapów. Niestety, wiele z gier oferuje bardzo powtarzalny model rozgrywki, który czyni je zwyczajnie nudnymi. Ostateczny cel stojący przed graczem, jakim jest np. osiągnięcie najwyższego poziomu sprowadza się do mechanicznego wykonywania wciąż tych samych czynności. Wydaje się, że uniknięciem takiej sytuacji jest napisanie bota, czyli programu, który wykonuje zaprogramowane czynności zamiast człowieka. Przykładowy bot opisany poniżej został oparty o bardzo prostą grę SimpleGame stworzoną specjalnie w celach demonstracyjnych. Temat jest obszernie opisany na forach internetowych, co pozwoli na dodatkowe poszerzenie swojej wiedzy w przypadku zainteresowania tą tematyką. Gra SimpleGame pozwala na poruszanie się postacią w lewo/prawo oraz atakowanie. Poniższy artykuł przybliży kolejne etapy powstawania prostego bota, który będzie wykonywał te czynności

10 Inżynieria oprogramowania Elementy potrzebne do napisania bota -Znalezienie adresu pamięci, pod którym zapisane są istotne informacje w poniższym przykładzie będzie to licznik ataków wykonanych przez postać bez poruszania się. -Program bota, pod postacią pliku biblioteki DLL -Injector DLL - program, który pozwoli na wstrzyknięcie bota do obcego procesu, czyli uruchomienie kodu bota w przestrzeni adresowej gry. Znajdowanie adresu pamięci Bot jest programem, którego działanie najczęściej związane jest z monitorowaniem aktualnej wartości zmiennej w grze, a następnie reagowanie na jej zmiany w określony sposób. Jednym z przykładów jest zautomatyzowanie zażywania Rysunek 1. Główny ekran gry mikstur leczenia w celu uniknięcia utraty życia. W przypadku gry SimpleGame bot będzie wykonywać atak określoną ilość razy (monitorując w tym celu stan licznika AttackCount), a następnie przesunąć się o pewną odległość w prawą stronę. Zmienna AttackCount, której wartość zwiększa się po każdym ataku, znajduje się gdzieś w pamięci gry. Podstawowym zadaniem jest znalezienie jej dokładnego adresu. W przypadku dużych gier zadanie to jest zazwyczaj dosyć trudne. Producenci oczywiście nie publikują ich kodu, więc programiści są zmuszeni znaleźć taki adres samodzielnie. Na potrzeby tego artykułu, ujawniłem kod SimpleGame w celu łatwiejszego zrozumienia opisywanego zagadnienia. 10 class CCharBase private: int DummyValue1; int AttackCount; int DummyValue2; public: CCharBase() AttackCount = 0; void inccntr() AttackCount++; void zerocntr() AttackCount = 0; int getattackcntr() return AttackCount; ; //Pointer for CCharBase //located somewhere in memory static CCharBase* CCharBasePtr; //Static function that operates on pointer //Usefull for AoB searching example static CCharBase* getptr() return CCharBasePtr; Kod 1. Fragmenty kodu gry Osobom, które nie są zainteresowane samym poszukiwaniem adresów w poszczególnych grach, z pomocą przychodzą fora internetowe, na których inni użytkownicy publikują wątki zawierające zestawienia tzw. addy (od słowa address ) oraz offset do danej statystyki w grze. W przypadku teoretycznego forum o SimpleGame, możnaby się spotkać z wartościami: #define CharBasePtr 0x #define AttackCountOffset 0x4 CharBasePtr - jest to adres pamięci, pod którym znajduje się wskaźnik. Wskazuje on na miejsce, gdzie alokowany jest obiekt zawierający między innymi dane na temat ilości ataków wykonanych przez postać AttackCount. Zazwyczaj Char- BasePtr itp. nazywane są także addy. AttackCountOffset jest to różnica pomiędzy adresem objektu CCharBase a zmienną AttackCount. Zwykle używa się w stosunku do niej pojęcia offset. W przypadku SimpleGame, istotne fragmenty kodu gry (zawierającego elementy Qt) wyglądają następująco (Kod 1). Konstruktor głównego okna (symulujący alokowanie CCharBase w losowym miejscu przy każdym włączeniu gry) oraz

11 Inżynieria oprogramowania metoda obsługująca zdarzenia klawiatury (Kod 2). Jak wspomniałem, głównym zadaniem jest samodzielne znalezienie danego addy oraz offsetu, które pozwalają na dokładne określenie adresu pod którym można odczytać wartość zmiennej AttackCount. MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) ui->setupui(this); Z pomocą przychodzą programy takie jak CheatEngine, które pozwalają na skanowanie pamięci obcego procesu. Można także pokusić się o samodzielne napisanie takiego skanera. Trzeba pamiętać, że gry alokują pamięć dynamicznie, więc każde włączenie gry od nowa, zmieni adres CCharBaseObj. W przypadku SimpleGame symulację takiego zachowania można zaobserwować w kodzie konstruktora MainWindow(). Całą operację opisaną poniżej kontynuuje się, aż do uzyskania poszukiwanych wartości. Jeżeli postać nie wykonała żadnego ataku, zmienna AttackCount ma wartość 0. Dodatkowo licznik ten jest zerowany w przypadku poruszenia postaci. //Randomize memory mechanism int RANGE = 10; srand(gettickcount()); int randomnr = rand()%range; CCharBase* CCharBaseArray[RANGE]; //Now create CCharBase object for(int i = 0; i<range;++i) CCharBaseArray[i] = new CCharBase(); //allocate 10 CCharBase objects for(int i = 0; i<range;++i) if(i!= randomnr) delete CCharBaseArray[i]; //delete 9 of CCharBase objects //CCharBasePtr points to different memory on every single run CCharBasePtr = CCharBaseArray[randomNr]; 11 void MainWindow::keyPressEvent(QKeyEvent* event) //Keyboard handling if(event->key() == Qt::Key_Right) //Move right, reset AttackCntr ui->warrior->setgeometry(ui->warrior->x()+5,ui->warrior->y(),ui->warrior->width(),ui- >Warrior->height()); CCharBasePtr->zeroCntr(); if(event->key() == Qt::Key_Left) //Move left, reset AttackCntr ui->warrior->setgeometry(ui->warrior->x()-5,ui->warrior->y(),ui->warrior->width(),ui- >Warrior->height()); CCharBasePtr->zeroCntr(); if(event->key() == Qt::Key_Control) //start attack animation, AttackCntr + 1 for(int i=0, h=1; i<20;++i) ui->warrior->setgeometry(ui->warrior->x(),ui->warrior->y()-h,ui->warrior- >width(),ui->warrior->height()); QApplication::processEvents(); Sleep(5); if(i == 9)h = -1; CCharBasePtr->incCntr(); //Debug purpose only, show current AttackCntr setwindowtitle(qstring( ATTACK CNTR: %1 ).arg(ccharbaseptr->getattackcntr())); Kod 2. Konstruktor głównego okna oraz metoda obsługująca zdarzenia klawiatury

12 Inżynieria oprogramowania Głównym celem jest zawężenie poszukiwań do jednego miejsca. W tym momencie wystarczy zaatakować wciskając ponownie klawisz ataku, tym samym stan licznika wzrośnie do 2 (Rys. 4). Z puli adresów, które wcześniej zawierały 1 sprawdzamy, czy któryś z nich przypadkiem nie zmienił się na 2. W poniższym przykładzie pula adresów zmniejszyła się do 2 elementów: Searching for value 2 from 0x0 to 0x6fffeff 2 values found in memory [0] - 0x3eb6c4 [1] - 0x3eb764 Nadal niemożliwe jest dokładne ustalenie poszukiwanego adresu, pod którym znajduje się AttackCount. 12 Rysunek 2. Poszukiwane wartości CharBasePtr oraz AttackCountOffset Pierwszy skan należy wykonać w obszarze całej pamięci gry, przy czym warto pamiętać, że zmienna AttackCount jest zapisana na czterech bajtach. Następnie dokonujemy pierwszego ataku (wciskając określony przycisk na klawiaturze), zwiększając tym samym wartość licznika o 1 i poszukamy wszystkich wartości 1 zapisanych na czterech bajtach (Rys 3). W takim przypadku opisaną czynność powtarzamy, aż do otrzymania jednego adresu. Searching for value 3 from 0x0 to 0x6fffeff Value found at: 0x3eb764 Wynikiem takiego skanowania pamięci w pełnym zakresie jest najczęściej spora liczba adresów, które spełniają powyższy warunek. Rysunek 3. Stan gry po wykonaniu pierwszego ataku Ja, ograniczając ilość pamięci do skanowania, uzyskałem w ten sposób niemal 4000 wyników. Poniżej znajdują się przykładowe z nich: Searching for value 1 from 0x0 to 0x6fffeff 3823 values found in memory [0] - 0x20008 [1] - 0x2293ac [2] - 0x2294fc Rysunek 4. Stan gry po wykonaniu drugiego ataku

13 Inżynieria oprogramowania Jak wspomniałem przy każdym uruchomieniu gry, adres zmiennej AttackCount będzie się różnić, gdyż jest przypisany dynamicznie. Przy kolejnym uruchomieniu gry wartość mogłaby się przykładowo znaleźć pod adresem 0xb Należy więc ustalić jaki jest jej addy oraz offset, które pozwolą na dokładne odnalezienie zmiennej przy każdorazowym włączeniu gry. Rozpoczyna się zatem od poszukiwania addy, czyli wskaźnika, który wskazuje dokładnie na dany adres (bardzo rzadki przypadek) lub adres, który wskazuje na miejsce w pamięci przed tym adresem. Jest to, niestety, z reguły kwestia prób i błędów oraz doświadczenia. Wykonujemy zatem skan pamięci w poszukiwaniu 4-bajtowego adresu, który będzie pokazywał w okolice znalezionego przed chwilą adresu zawierającego AttackCount, czyli np. od 0x3eb750 do 0x3eb764. W przypadku skomplikowanych gier takich adresów jest najczęściej kilka (np. różne obiekty mogą zawierać wskaźnik na ten sam obiekt), jednakże wskaźniki, które są interesujące z reguły znajdują się przy sobie na początku adresu bazowego gry. Wynikiem poszukiwania w przypadku SimpleGame jest 1 wartość: Searching for pointers looking from 0x3eb750 to 0x3eb764 in range from 0x to 0x6fffeff Pointer found at: 0x > 0x3eb760 Znaleziony adres 0x (czyli CCharBasePtr) pokazuje na obiekt CCharBaseObj zaalokowany pod adresem 0x3eb760. Rysunek 5. Wynik deassemblacji od adresu 0x wersji gry i mogą się zmienić dopiero po zmianach dokonanych np. w kolejnym patchu. Array of Bytes W przypadku wielu gier, można co jakiś czas spodziewać się patchy wprowadzających nowe elementy gry, poprawki, mapy, przedmioty i wiele innych. Wiąże się to ze zmianą addy oraz offset. Pierwszym sposobem na zidentyfikowanie nowych wartości jest bazowanie na uprzednio zdobytej wiedzy i poszukiwanie tych wartości tak, jak w przypadku licznika ataków. Bardziej efektywną metodą jest jednak znalezienie tak zwanych AoB (Array of Bytes), czyli tablicy bajtów charakteryzujących dany obszar pamięci. Pozwolą one w prosty sposób znaleźć adres wskaźnika oraz offset. Do ustalenia AoB posłuży nam deassembler. Pierwszym krokiem w tym celu powinno być przeszukanie pamięci procesu, w którym załadowana jest gra, celem znalezienia miejsca zawierającego wcześniej zlokalizowane addy lub offset. Wynikiem poszukiwania 4-bajtowego 0x417038, jest przykładowo adres 0x Pod tym adresem znajduje się wcześniej znaleziony addy, a otaczający kod do- 13 Jest to poszukiwany addy. Jak łatwo się domyślić, offset wyliczamy odejmując adres, w którym naprawdę znajduje się licznik ataków od adresu pokazywanego przez wskaźnik. Tym samym 0x3eb764-0x3eb760 = 0x4 offset. Znając te wartości możemy np. stale monitorować, czy postać nie doszła do ustalonego limitu ataków i resetować licznik poprzez zmianę pozycji bohatera. Znalezione wartości są stałe dla danej Rysunek 6. Wynik deassemblacji od adresu 0x40145c. Widoczny kod funkcji getptr()

14 Inżynieria oprogramowania 14 konuje na nim nieokreślonych operacji. Następnie powinniśmy zdeasemblować pamięć w tym miejscu, uzyskując tym samym kod gry. Wynik tego działania przedstawiam na (Rys. 5). Interpretowanie kodu bezpośrednio od znalezionego adresu jest niepoprawne, gdyż znaleziony adres jest częścią instrukcji: mov [0x417038], eax Cofając się o kilka bajtów można stwierdzić dokładniej, co dzieje się w kodzie (Rys. 6) Na podstawie adresów, które są zmienne, można ustalić Array of Bytes. W tym przypadku byłby to: E5 A1???????? C9 C3 //Static function that operates on pointer //Usefull for AoB searching example static CCharBase* getptr() return CCharBasePtr; Kod 3. Kod statycznej funkcji zwracającej wskaźnik na CCharBase Przy czym ciąg znaków?? oznacza typowy wildcard, czyli jakąkolwiek wartość w pamięci. Jest to oczywiście kod maszynowy statycznej funkcji zwracającej wskaźnik na CCharBase (Kod 3). Dokładnie w ten sam sposób postępuje się w przypadku poszukiwania offsetu. Mając już znalezione AoB charakteryzujące obszar, który zawiera potrzebne adresy, można je wykorzystać w przyszłości. Przykładowo w przypadku spatchowania gry, gdzie większość kodu zostanie taka sama. Metody iniekcji Znając wartości addy i offset wiadomo dokładnie, spod jakiego adresu czytać dane, aby wydobyć ilość ataków. Problemem jest niestety czytanie z pamięci aplikacji. Gry najczęściej chronione są specjalnymi programami, które zabezpieczają je między innymi przed wykonaniem operacji typu OpenProcess, Rysunek 7. Okno bota #include <windows.h> extern int Main(); //tells compiler that function Main is located somewhere else. void WINAPI MainThread( ) //This function will run when DLL will be attached to Game. Main(); //located in ControlDialog.cpp, This will load the form and display it BOOL WINAPI DllMain(HMODULE hmodule, DWORD dwreason, LPVOID lpvreserved) switch(dwreason) //the switch to check for the DLL call reason case DLL_PROCESS_ATTACH: //if the DLL is attached DisableThreadLibraryCalls(hModule); //disable library calls CreateThread(NULL,NULL, (LPTHREAD_START_ROUTINE)MainThread, NULL, NULL, NULL); break; case DLL_PROCESS_DETACH: //when the program exits and the DLL is detached ExitProcess(0); //it exits the process to make a smoother exit break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; return TRUE; Kod 4. MainDLL.cpp #include ControlDialog.h using namespace DemoBOT; int Main() //Enabling Windows XP visual effects before any controls are created Application::EnableVisualStyles(); Application::SetCompatibleTextRenderingDefault(false); //Create the main window and run it Application::Run(gcnew ControlDialog()); //ControlDialog is the name of the form created. return 0; Kod 5. ControlDialog.cpp

15 Kod 6. Odczyt wartości Inżynieria oprogramowania inline ULONG_PTR ReadPointer(ULONG_PTR* ulbase, INT noffset) if (!IsBadReadPtr((VOID*)ulBase, sizeof(ulong_ptr))) if (!IsBadReadPtr((VOID*)((*(ULONG_PTR*)ulBase)+nOffset), sizeof(ulong_ptr))) return(ulong_ptr)((*(ulong_ptr*)ulbase)+noffset); return 0; WriteProcessMemory lub ReadProcessMemory z innego procesu. Rozwiązaniem jest wstrzyknięcie pliku DLL zawierającego program bota, bezpośrednio do procesu gry, który będzie działać w jej obrębie. Dla systemu Windows istnieją 3 techniki iniekcji: - używając metody CreateRemoteThread() - używając metody SetWindowsHookEx() - Caveman code Więcej informacji na ich temat wraz z przykładami użycia można znaleźć w Internecie. Istnieją również uniwersalne injectory (np. Castorama GMMMI). Wymagają one jedynie podania nazwy aplikacji, do której będą wstrzykiwane DLL ki. stawiony poniżej bezpieczny (stosujący funkcję IsBadReadPtr) sposób (Kod 6). Kod bota, znajdujący się w głównym oknie aplikacji, będzie więc następujący (Kod 7). W kodzie można zauważyć zdefiniowane makra GetPointer, NewThread oraz SendKey. Pozwalają one na wywołanie bardziej skomplikowanych funkcji w prosty sposób. Zaznaczenie kontrolki checkbox w głównym oknie bota, wystartuje wątek AutoAttack. Wątek ten sprawdza najpierw stan licznika AttackCount poprzez wywołanie funkcji GetPointer, używając jako parametry wcześniej znalezionych addy oraz offset. Jeżeli stan tego licznika jest większy niż 5 - kilka razy zostanie wciśnięty klawisz klawiatury odpowiadający za ruch postaci w prawo. Następnie bot wykona atak wciskając klawisz CTRL i odczeka jedną sekundę, aby powtórzyć akcję (rys. 8 - rys.11). Jeżeli użytkownik odznaczy checkbox, wątek po chwili zakończy się, a postać przestanie się poruszać. Podsumowanie Program bota przedstawionego powyżej jest oczywiście bardzo prosty, przedstawia jednak zasady czytania pamięci oraz reagowania na jej zmiany. Służą do tego funkcje służące do symulowania wciśnięć przycisków (keybd_event, PostMessage lub mouse_event), co pozwala na symulowanie zachowań prawdziwego gracza. W przypadku rzeczywistych gier, przy odrobinie inwencji można taki program rozwinąć o wyszukiwanie wrogich postaci sterowanych w grze przez komputer, używanie mikstur leczenia, zbierania przedmiotów oraz wiele innych. Należy 15 Kod bota Zakładając, że udało nam się wstrzyknąć przygotowaną DLL kę z programem bota, przy ładowaniu pliku DLL zostanie wywołana metoda DllMain z parametrem DLL_PROCESS_ATTACH. W tym miejscu należałoby stworzyć wątek, który uruchomi główne okno programu, pozwalające użytkownikowi na kontrolę funkcji bota oraz na obsługę czynności takich, jak czytanie pamięci i wydawanie postaci komend (wciśnięcie klawisza odpowiedzialnego za poruszanie). Program bota załadowany w obszarze pamięci gry, ma do niej swobodny dostęp. Tym samym zamiast funkcji ReadProcessMemory można uzywać memcpy lub podobnych. Popularnym sposobem używanym powszechnie przy pisaniu botów do gier jest odczyt wartości w przed-

16 Inżynieria oprogramowania #include windows.h inline ULONG_PTR ReadPointer(ULONG_PTR* ulbase, INT noffset) if (!IsBadReadPtr((VOID*)ulBase, sizeof(ulong_ptr))) if (!IsBadReadPtr((VOID*)((*(ULONG_PTR*)ulBase)+nOffset), sizeof(ulong_ptr))) return *(ULONG_PTR*)((*(ULONG_PTR*)ulBase)+nOffset); return 0; #define GetPointer(Base, Off) ReadPointer((ULONG_PTR*)Base, Off); #define NewThread(name) CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE)&name, NULL, NULL, NULL); //#define SendKey(KeyPress) PostMessage(FindWindow( SimpleGame, 0), WM_KEYDOWN, KeyPress, (MapVirtualKey(KeyPress, 0) << 16) + 1); //useful if game supports WindowProc control #define CharAddy 0x #define AttackOffset 0x4 int CurrentJumpCntr() return (int)getpointer(charaddy, AttackOffset); 16 bool attackactive = false; void AutoAttack() while(attackactive) //If checkbox checked if(currentjumpcntr() >= 5) //If 5 attacks already done move right for(int i=0;i<10;++i) keybd_event(vk_right, 0, 0, 0); //Press -> key keybd_event(vk_right, 0, KEYEVENTF_KEYUP, 0); //and release Sleep(100); keybd_event(vk_control, 0, 0, 0); //Press CTRL key keybd_event(vk_control, 0, KEYEVENTF_KEYUP, 0); //and release Sleep(1000); private: System::Void checkbox1_checkedchanged(system::object^ sender, System::EventArgs^ e) if(this->checkbox1->checked) attackactive = true; NewThread(AutoAttack); else attackactive = false; Kod 7. ControlDialog.h

17 Inżynieria oprogramowania przy tym pamiętać, że twórcy gier z reguły oczywiście nie życzą sobie używania tzw. macro-assisted (auto-hunting) programs, co może doprowadzić do zablokowania konta w przypadku np. wykrycia pewnych regularności w sposobie poruszania się wirtualnej postaci. Napisanie jednak działającego programu, który pozwala na polepszenie poziomu wirtualnego herosa wydaje się być nad wyraz satysfakcjonujące i wynagradzające poświęcony na to czas. W przypadku chęci pogłębienia wiedzy warto zapoznać się również z tematem hacków, czyli bardziej skomplikowanych operacji związanych z modyfikowaniem na żywo pamięci gry, celem np. podmiany adresów wywoływanych funkcji. W tym przypadku zalecam bardzo dużą ostrożność, gdyż właśnie hacki są głównym powodem, dla którego stosuje się programy ochronne gier i to właśnie one w najprostszy sposób mogą doprowadzić do zablokowania konta w grze. Rysunek 8. Stan początkowy gry. Postać w pozycji startowej, AttackCount = 0. Bot nieaktywny Zdobyta wiedza może się także przydać w profesjonalnych zadaniach projektowych. Pozwala ona wpływać na kod programu innej aplikacji w sposób nieprzewidziany przez autorów. Przykładowo mogą być to monitory pewnych wartości, czytanie parametrów wywołań wewnętrznych funkcji lub przekierowanie wywołań w inne miejsca kodu (tzw. hooking). Wiedza ta jest jednak bardziej zaawansowana, a podstawy najlepiej opanować łącząc przyjemne z pożytecznym. Dlatego też napisanie bota wydaje się w tym przypadku trafnym wyborem. Rysunek 9. Postać zaatakowała 5 razy i poruszyła się w prawo. Gra w momencie gdy wykonany był pierwszy atak w nowej pozycji 17 Rysunek 10. Postać zaatakowała po raz kolejny 5 razy, po czym poruszyła się w prawo. Gra w momencie gdy wykonany był 4 atak w drugim cyklu Referencje Forum, bogate w przykłady, skrypty, boty php?p= Wątek na forum poświęcony technikom iniekcji Darmowy program open source. Pomocny w przeszukiwaniu pamięci innych procesów Rysunek 11. Bohater w kolejnym cyklu, AttackCount równy 0, zresetowany przez zmianę pozycji postaci

18 Inżynieria oprogramowania Zaproszenie do udziału w V edycji cyklu wydarzenia Warszawa, grudnia Tytuł warsztatu Architektura Korporacyjna, Analiza Biznesowa i Zarządzanie Procesami Biznesowymi Czas trwania: 2 dni Miejsce spotkania: Sheraton Warsaw Hotel Prowadzący: dr Juergen Pitschke Tematyka Celem warsztatu organizowanego w ramach cyklu Business Analyst Forum jest zaprezentowanie koncepcji Architektury Korporacyjnej w kontekście analizy biznesowej oraz metod zarządzania procesami biznesowymi. Ponadto celem jest wskazanie sposobu usystematyzowanego podejścia do specyfikowania wymagań biznesowych oraz płynnego przejścia od etapu planowania działalności operacyjnej organizacji do planowania zasobów potrzebnych do jej realizacji. Zarządzanie procesami biznesowymi oraz analiza biznesowa są dyscyplinami inżynierskimi, które już na dobre zagościły w codzienności korporacyjnej, stanowiąc bazę oraz często przyczynek do zmian zasad pracy oraz poważniejszych zmian organizacyjnych. Praktyka pokazuje jednak, iż zauważalnie często, próba dokonania zmian w procesach oraz wspierających je systemach informatycznych napotyka na problemy, których źródło może tkwić zarówno w obszarach strategicznych organizacji jak i w niezrozumieniu wzajemnych oczekiwań i potrzeb na poziomach operacyjnych. Systemem oraz instytucją pozwalającą na zarządzanie tego typu sytuacjami jest dyscyplina nazywana Architekturą Korporacyjną (ang. Enterprise Architecture). Rozpatrując organizację w sposób holistyczny, można stwierdzić, iż zarówno analiza biznesowa jak i zarządzanie procesowe, z jednej strony dostarczają danych wymaganych paradygmatem Architektury Korporacyjnej, a z drugiej, są działaniami, które powinny być ograniczane ramami architektonicznymi zdefiniowanymi w ramach tejże Architektury. Prelegent Dr Juergen Pitschke jest założycielem i dyrektorem zarządzającym BCS. Od dawna zajmuje się tematem modelowania i projektowania wizualnego rozwiązań biznesowych. Jest uznanym ekspertem w dziedzinie metodycznego stosowania standardowych notacji modelowania. W swojej karierze zawodowej pomógł wielu organizacjom wprowadzić te standardy i metody w ich codzienną działalność. Jest tłumaczem metodyki RuleSpeak na język niemiecki. Współpracował z takimi firmami jak Kuehne+Nagel (AG & Co.) KG, Class KGaA mbh oraz takimi instytucjami jak Federalne Biuro Policji w Szwajcarii oraz Urząd Hydrograficzny w Wielkiej Brytanii. Jest wykładowcą University of Cooperative Education w Dreźnie, gdzie prowadzi zajęcia z zakresu inżynierii oprogramowania oraz analizy systemowej.

19 Inżynieria oprogramowania Program warsztatu 1. Architektura, metoda i proces. Wykorzystanie podejścia opracowanego przez Ivara Jacobsona do prowadzenia analizy biznesowej w oparciu o ustanowione ramy architektoniczne. 2. Architektura Korporacyjna metoda, dyscyplina zarządcza czy struktura? Czym jest Architektura Korporacyjna? Różni autorzy, konsultanci oraz firmy definiują Architekturę Korporacyjną na różne sposoby. W trakcie warsztatów porównane zostaną te definicje oraz wypracowana zostanie definicja robocza na potrzeby warsztatu. 3. Architektura Korporacyjna jako struktura wprowadzenie do Siatki Zachmana (Zachman Framework). Siatka Zachmana definiuje uniwersalną strukturę informacji dla Architektury Korporacyjnej. W trakcie warsztatów zaprezentowana zostanie koncepcja oraz podstawy Siatki. Dokonane zostanie także porównanie Siatki Zachmana z TOGAFem. 4. Architektura Korporacyjna a BPM. W ramach tego bloku omówione zostaną korzyści jakie można odnieść, odwołując się w ramach inicjatyw związanych z zarządzaniem procesowym do ram architektonicznych. 5. Architektura Korporacyjna jako metoda w jaki sposób tworzyć Architekturę Korporacyjną? W jaki sposób powiązać modele i elementy modeli w Siatce Zachmana? Które elementy muszą być zdefiniowane? Które elementy są opcjonalne? Jakie standardy należy stosować, aby zdefiniować wymagane artefakty? W ramach bloku zostaną wypracowane standardy prezentacji dla wymaganych rodzajów artefaktów ze szczególnym uwzględnieniem podejścia procesowego. Wskazane zostaną zależności łączące procesy biznesowe, pojęcia biznesowe, logikę biznesową oraz wymagania biznesowe Role w zarządzaniu Architekturą Korporacyjną. Jakie role powinny być zdefiniowane w organizacji, aby skutecznie zarządzać Architekturą Korporacyjną? Jakie powinny być kompetencje oraz odpowiedzialności poszczególnych ról? 7. Ograniczenia Architektury Korporacyjnej Nie ma jednej, słusznej metody! Co znajduje się poza Architekturą Korporacyjną? W trakcie bloku wskazane zostaną zależności łączące Architekturę Korporacyjną z takimi dyscyplinami jak Zarządzanie Projektami oraz Zarządzanie Zmianą. Organizator AION firma doradczo - szkoleniowa, specjalizująca się w świadczeniu usług z zakresu analizy biznesowej i systemowej oraz modelowania procesów biznesowych. W obszarze kompetencji AION znajduje się doradztwo, prowadzenie specjalistycznych szkoleń i konferencji, tworzenie systemów IT oraz wdrażanie narzędzi wspomagających modelowanie i usprawnianie procesów biznesowych. Kontakt tel. (71) tel. kom aion@aion.com.pl Serdecznie zapraszamy na warsztaty! Więcej informacji znajdą Państwo na stronie

20 Inżynieria oprogramowania Wirtualizacja aplikacji zwiększa produktywność oraz ułatwia testowanie i wdrażanie współczesnych systemów IT 20 Autor: Marek Kucharski Współczesne systemy IT już dawno przestały być wielką, monolityczną aplikacją. Zastąpił je skomplikowany konglomerat tradycyjnych aplikacji jak CRM czy ERP; mniejszych, wysokospecjalizowanych, coraz częściej oferowanych w chmurze. Wszystkie elementy takiego systemu muszą się ze sobą komunikować i to najczęściej w czasie rzeczywistym. Przy takim stopniu współzależności właściwe przetestowanie nowej aplikacji staje się ogromnym wyzwaniem obarczonym wysokimi kosztami, nakładem pracy i czasu. Aby temu zaradzić powstała koncepcja wirtualizacji aplikacji. Dzięki niej przedsiębiorstwa mogą zaoszczędzić znaczne środki na etapie zarówno samej produkcji jak i testowania oraz wdrażania nowych komponentów do swoich systemów informatycznych. Zawsze fascynowało mnie jak linie lotnicze ustalają ceny biletów w sprzedaży internetowej. Ostatnio miałem okazję zapo- znać się z częścią tej tajemnicy wizytując jedną ze znanych linii lotniczych. Ich proces sprzedażowy znacznie różni się od tego, który zarządza kupnem np. biletów komunikacji miejskiej czy kolejowej. W przypadku połączeń kolejowych, za dane połączenie w danym okresie czasu obowiązuje sztywna, z góry ustalona cena. Tymczasem zakup biletu lotniczego przypomina raczej ruletkę. Z grubsza rzecz biorąc cały proces przebiega w pięciu etapach. W pierwszym kroku klient loguje się do portalu. Następnie system CRM po dokonaniu identyfikacji klienta - dostarcza informacji na temat historii jego zakupów, ilości zgromadzonych punktów lojalnościowych, itd. Gdy klient wybierze skąd, dokąd i kiedy chciałby polecieć, wówczas portal kontaktuje się z głównym systemem opartym na komputerze typu mainframe w celu uzyskania możliwych opcji przelotu. W kolejnym kroku portal komunikuje się z zewnętrznym systemem dostarczającym informacji o tym, jakie ceny na podobne połączenia oferuje konkurencja. Dopiero po zebraniu tych wszystkich informacji następuje wycena połączeń dla danego klienta. Jeżeli klient wybierze jakieś połączenie, do zawarcia transakcji potrzebna jest jeszcze autoryzacja karty płatniczej, realizowana przez kolejny system zewnętrzny. Mamy więc pięć systemów biorących udział w transakcji: 1. Portal internetowy 2. CRM dostarczający dane o profilu klienta 3. Mainframe z systemem rezerwacyjnym 4. Serwis dostarczający dane o konkurencyjnych ofertach 5. Serwis transakcji finansowych Moja wizyta we wspomnianej wyżej linii lotniczej związana była nie tylko z zaspokojeniem ciekawości, ale przede wszystkim z problemem, z jakim borykała się ta