W dniach 7-10 września 2014 r. w Warszawie odbyła się kolejna edycja międzynarodowej konferencji naukowej FedCSIS (Federated Computer Science and Information Systems).
Organizatorami tegorocznej edycji konferencji naukowej byli:
- Polskie Towarzystwo Informatyczne (PTI),
- Instytut Badań Systemowych Polskiej Akademii Nauk,
- Uniwersytet Ekonomiczny we Wrocławiu,
- Politechnika Warszawska.
W porównaniu z wcześniejszymi edycjami, udało się rozwinąć konferencję - zarówno pod względem różnorodności i liczby atrakcji, jak i frekwencji. Zaplanowano w sumie 22 wydarzenia w ramach 7 obszarów tematycznych. Swój udział zgłosiło ponad 360 osób z 43 krajów i 6 kontynentów. Pierwszego dnia odbyły się warsztaty w ramach siedmiu wydarzeń. W niektórych salach liczba uczestników była o wiele większa niż się spodziewano - wskutek dużego zainteresowania zabrakło nawet miejsc siedzących. Ale nikomu nie przeszkodziło to w dobrej zabawie - od samego początku można było poczuć wspaniałą atmosferę towarzyszącą licznym rozmowom w kuluarach i wymianie doświadczeń.
Wśród wydarzeń, które miały miejsce pierwszego dnia konferencji, znalazły się: 5th International Workshop Automating Test Case Design, Selection and Evaluation (ATSE'14), 5th International Workshop on Advances in Business ICT (ABICT'14), 7th Workshop on Computational Optimization (WCO'14), 9th International Symposium Advances in Artificial Intelligence and Applications (AAIA'14), 4th International Workshop on Advances in Semantic Information Retrieval (ASIR'14), 7th International Symposium on Multimedia Applications and Processing (MMAP'14), 2nd Workshop on Scalable Computing in Distributed Systems (SCoDiS'14). Wydarzenia odbywały się w 4 równoległych ścieżkach. Na każdej sali było od 20 do ponad 40 uczestników słuchających o wynikach doświadczeń i badań prelegentów. Ilość pytań z reguły sprawiała, że część z nich trzeba było przenieść na rozmowy w kuluarach podczas przerw. Świadczy to o tym, że zainteresowanie było duże, a tematyka prezentacji interesująca dla uczestników.
Automatyzacja testowania
Rozmowa z Sigridem Eldthem (Ericsson AG, współorganizator ATSE'14)
Tomasz Klasa (TK): Czy możesz opisać o czym jest sesja ATSE?
Sigrid Eldth (SE): Sesja poświęcona jest automatyzacji testowania. Testy stanowią istotną część procesu tworzenia oprogramowania, choć przez długi czas były mocno niedoceniane jako obszar badawczy. Choć testy zawsze były nieodłącznym elementem (etapem) inżynierii oprogramowania, przez długi czas nie poszukiwano metod ich systematyzacji, czy automatyzacji. W pewnym sensie dopiero rozwój podejścia Agile sprawił, że 10-15 lat temu poświęcono im znacznie więcej uwagi. Niestety, podejście akademickie wciąż jest odmienne od podejścia przemysłu. Wynika to w znacznej mierze z odmiennych doświadczeń w tym zakresie, które mają wpływ na zmianę perspektywy widzenia. Sesja jest jedną z prób znalezienia wspólnego mianownika między podejściem akademickim a przemysłowym.
TK: Czy automatyczne testowanie ma zastosowanie w przypadku dowolnego kodu i w każdej sytuacji?
SE: W zasadzie tak, to tylko kwestia kosztów. Nie zawsze jest to opłacalne, ale biorąc pod uwagę czas życia systemów przemysłowych (czy ogólnie komercyjnych) oraz tempo wprowadzanych w nich zmian zwykle jest to dobra inwestycja. Dzięki automatyzacji można uzyskać pełną powtarzalność testów - tego nie zapewni nawet najbardziej zdyscyplinowana grupa testerów. Jeśli kod żyje, czyli jest systematycznie modyfikowany, to automatyzacja testów pozwala na zbudowanie i wielokrotne wykorzystanie bazy przypadków testowych. To znacznie przyspiesza pracę i obniża koszty.
TK: Czy są jakieś wady/zagrożenia?
SE: Przede wszystkim są to koszty opracowania mechanizmu automatyzacji testów. Oczywiście koszt ten jest niwelowany w kolejnych przebiegach testów, gdy można ponownie wykorzystać raz wypracowane rozwiązania. Część prac lepiej wykona człowiek, szczególnie te w obszarze "user experience". Ponadto, zawsze istnieje ryzyko błędów w algorytmach testów, które są opracowywane przez ludzi.
Refactoring kodu
Rozmowa z Stevem Counsellem (Brunel College London, prelegent ATSE'14)
Refactoring polega na modyfikowaniu kodu programu bez wpływania na jego semantykę. Celem jest oczyszczenie kodu i ułatwienie zrozumienia go przez innych programistów. Ponieważ kod jest modyfikowany, konieczne jest wykonanie dodatkowych testów.
Tomasz Klasa (TK): Czy można po czymś poznać, że refactoring jest wymagany?
Steve Counsell (SC): Niestety nie. Refactoring należy robić na bieżąco. Należy wykonać go także po przejęciu obcego kodu. Natomiast nie ma takiego wskaźnika, który pokazałby, czy kod jest wystarczająco czysty, czy może już wymaga działania w postaci refactoringu.
TK: W jaki sposób określić, czy zakres planowanego refactoringu nie jest zbyt szeroki, a wykonanie go w całości to będzie jak "jeden most za daleko"?
SC: Faktycznie, istnieje ryzyko, że się przedobrzy i wynik poprawiania kodu również będzie niezrozumiały dla innych, choć z innych powodów niż przed zmianami. Trudno powiedzieć kiedy już wystarczy - w praktyce przemysłowej zwykle problem "przedobrzenia" nie występuje. Patrząc z drugiej strony niewątpliwie jest to proces wymagający balansowania między potencjalnymi zyskami a kosztami. Pod tym względem może się okazać, że za dużo czasu/energii poświęcamy na poprawki kodu biorąc pod uwagę jego biznesową czy funkcjonalną istotność.
Wieczór argentyński
Ostatnim, choć wcale nie najmniej ważnym elementem dnia było spotkanie integracyjne w postaci wieczorku argentyńskiego. Była możliwość spróbo- wania argentyńskiej kuchni i posłuchania argentyńskiej muzyki. Najważniejsze jednak, że była to okazja do wymiany doświadczeń i prowadzenia swobodnych rozmów na temat wygłoszonych prezentacji, ale też wspólnych zainteresowań.
Pierwszego dnia w konferencji wzięło udział około 150 osób, wygłoszono niemal 50 prelekcji. Wydaje się, że organizatorzy niejednej konferencji z radością przyjęliby takie wielkości na całość 2-3 dniowej konferencji. Tymczasem FedCSIS dopiero rusza.
