Rejestracja uczestników. Networking i powitalny poczęstunek.
Powitanie gości i otwarcie konferencji.
Jakość = Krew + Pot?
Proces zapewnienia jakości podobnie jak procesy związane z testowaniem oprogramowania są pracochłonne i czasochłonne ale krytyczne dla projektów IT. Kilka rad praktyka jak uniknąć pułapek w definicji i rozwoju mechanizmów zapewnienia jakości. Za jakość w projektach IT nie odpowiada tylko dział testów. Jak pomóc innym zrozumieć, że jakość to odpowiedzialność całej grupy projektowej?
Czy przestrzeganie standardów jakości oprogramowania obniża produktywność i szkodzi innowacyjności?
Z jednej strony widać coraz większą presję na dostosowanie procesu rozwoju oprogramowania do wymogów standardów jakości (m.in. w kwestii bezpieczeństwa), z drugiej zaś przestrzeganie standardów wiąże się z formalizmem i raczej przyziemnymi działaniami. Wśród programistów tego typu zadania nie należą do ulubionych, tak iż można obawiać się o ich zaangażowanie - trudno jest stworzyć w firmach spójny i trwały proces w zakresie przestrzegania standardów jakości.
Czy istnieją sposoby, aby złagodzić niepożądane skutki uboczne? Pokażemy kilka rzeczywistych przypadków pomyślnego wdrożenia procedur narzuconych przez standardy jakości, obalając narosłe mity.
Od wymagań do testów.
Problemy związane z niską jakością wymagań dla systemów informatycznych stanowią jedną z głównych przyczyn niepowodzeń projektów.
Koszty naprawy błędów oprogramowania w fazie testów są zdecydowanie wyższe niż na etapie powstawania wymagań. W projektach zapewnienia jakości dojrzałe procesowo powiązanie testów z wymaganiami daje wymierne korzyści. Kompleksowe rozwiązania Borland stanowią wiodącą ofertę w obszarze wymagań oraz testowania aplikacji.
Software - byle jakoś(ć) dostarczyć
Zbiór przemyśleń prelegenta, wynikających z doświadczeń zbieranych przez ponad 15 lat obecności na rynku IT. Prezentacja to manifest, bazujący na wyznawanych przez autora wartościach, opierający się na wierze w człowieka, który jest przecież Zamawiającym, Twórcą i Użytkownikiem rozwiązań software-owych. To próba nazwania wprost zjawisk, postaw czy zachowań mających, wg prezentującego, wpływ na owe rozwiązania, w szczególności zaś na ich jakość. Prelegent nie sili się na zachowanie poprawności politycznej, ale stara się być uczciwy w stosunku do uczestników pełniących w ramach projektów IT określone role: od zamawiających, poprzez dostawców, PM-ów, programistów, testerów, po końcowych użytkowników. Oznacza to, że wszystkim im dostanie się w równym stopniu. Jednocześnie prelegent przyzna, że nie jest wcale tak idealny, jak mogłoby się wydawać.
Ambicją autora jest zainspirowanie Odbiorcy do odrzucenia utartych sposobów myślenia o realizacji projektów IT, zachęcenie Go do holistycznego spojrzenia na proces i eliminowania elementów noszących znamiona marnotrawstwa. Celem jest przekazać podpowiedzi co można robić, aby Świat - nie tylko IT - stał się lepszy. Tylko. czy naprawdę tego chcemy i potrzebujemy? Po co się tak męczyć?
Przerwa na kawę i herbatę
Prowadzenie sesji: Przemysław Gamdzyk, IDG Poland
Proces i organizacja budowania jakości.
W przypadku banku jakość systemów informatycznych jest zagadnieniem krytycznym. Błędy lub niedostępność systemów IT mogą prowadzić do bardzo poważnych konsekwencji. Prezentacja pokazuje sposób wytwarzania oprogramowania dla potrzeb banku Nordea oraz najważniejsze wyzwania w poprawianiu jakości tych systemów. Obrazuje również praktyczne sposoby rozwiązywania problemów jakościowych, takie jak poprawianie współpracy z klientem, automatyzację testów, redukcję długu technologicznego, organizację drugiej linii wsparcia, tworzenie bazy wiedzy czy wprowadzanie standardów.
Jak motywować programistów?
Zagadnienie motywacji do pracy i realizacji zadań projektowych to jedno z największych wyzwań przełożonego. Coraz częściej - szczególnie w środowiskach profesjonalnych - okazuje się, że zwykłe motywatory finansowe nie są skuteczne. Analiza potrzeb i aspiracji programistów oraz propozycje mechanizmów budujących ich zaangażowanie.
Zwiększenie efektywności testów dzięki architekturze oprogramowania oraz optymalizacji ich planowania.
Efektywności testów oprogramowania staje się coraz większym wyzwaniem szczególnie, iż żyjemy pod presją oczekiwań jakościowych - z jednej strony - oraz skracania czasu cyklu wytwórczego z drugiej. Chcielibyśmy zachęcić do poszukiwań "zwiększenia efektywności" w architekturze oprogramowania oraz w optymalizacji procesu planowania testów. Dwa studia przypadku: przykład pierwszy dotyczy architektury oprogramowania i powiązanych z nią decyzji wpływających na efektywność testów aplikacji webowej opartej o framework GWT, drugi zaś możliwości rozbudowy narzędzia Sparx Enterprise Architect w celu zapanowania nad złożonością skryptów testowych. Zaprezentujemy wizualny sposób projektowania testów umożliwiający odwołanie się w narzędziu do elementów GUI testowanego oprogramowania i generowanie skryptów testowych dla wybranego silnika testów (Selenium).
Prowadzenie sesji: Marek Rzewuski, Computerworld
Ewolucja testowania przy przechodzeniu na scrum - fakty i mity.
Jak "przejść na SCRUM" zachowując ciągłość pracy? Wokół przechodzenia organizacji w stronę Scruma narosło wiele mitów - prezentacja na przykładach realnych projektów pokaże, w czym SCRUM może pomóc, a w czym jemu będzie trzeba pomagać. Przyjrzymy się rzeczywistości z trzech perspektyw - developera, testera i menadżera.
Scrum w projekcie czyli zalety i potykacze w praktyce.
Zalety i potykacze w trakcie wdrażania i stosowania Scruma w projektach informatycznych. Korzyści biznesowe, które zespół Scrumowy oraz Interesariusze uzyskają już po pierwszym sprincie. Znaczenie Product Ownera i Scrum Mastera. W jaki sposób w Zespole Developerskim mogą odnaleźć się pracownicy niemający umiejętności T-shaped.
Historia pewnej zmiany czyli zwinność w ING Banku Śląskim.
Zasadniczym celem ING Banku Śląskiego, który wynika z jego strategii, jest dostarczanie zintegrowanych usług finansowych oraz zachowanie charakteru banku zorientowanego właśnie na klienta. Dokładnie rok temu, uruchomiliśmy inicjatywę, która okazała się niezwykle istotnym czynnikiem wspierającym realizację tego celu – transformację agile. Jako narzędzie, wybraliśmy metodę Scrum, która stwarza szczególną przestrzeń dla innowacji. Zmniejsza dystans pomiędzy IT, a Biznesem. Daje większą transparentność, i możliwość szybkiego reagowania na zmiany. Eliminuje stratę i ułatwia komunikację. Ale także dużo wymaga, zwłaszcza na poziomie organizacji. Podczas wspólnej prezentacji opowiemy Państwu, jak do tego doszło. Przedstawimy kolejne etapy transformacji. Pokażemy pierwsze wyniki oraz wyciągnięte wnioski.
Ludmiła Pisiewicz, ING Bank Śląski
Mariusz Chrapko, Kugler Maag CIE
OBIAD
Prowadzenie sesji: Marek Rzewuski, Computerworld
Jakość oprogramowania na urządzenia mobilne - stara dobra inżynieria jakości czy całkiem nowy świat.
Propozycja adaptacji sprawdzonych metod zapewnienia oraz kontroli jakości w relatywnie nowym obszarze jakim są aplikacje na urządzenia mobilne. Analiza warunków biznesowych, użytkowych oraz technicznych aplikacji mobilnych. Wykorzystanie klasycznego modelu jakości pochodzącego z normy ISO 9126 do zbudowania modelu jakości aplikacji mobilnych. Narzędziowe możliwości wsparcia kontroli jakości w środowisku mobilnym – aspekty praktyczne.
Projakościowe wytwarzanie oprogramowania w środowisku portali internetowych.
Case study na przykładzie serwisu Sport.pl
Aspekty związane z cyklem wytwarzania oprogramowania - projektowanie, implementacja, testy, itp.
Zarządzanie zespołem w różnych lokalizacjach. Wykorzystanie nowych metodyk projektowych (jak Scrum). Aspekty mobilne (strona "lekka" serwisu - m.in. sport.pl i aplikacja SportLive). Jakość oprogramowania (w tym przeglądy kodu) oraz aspekty wydajnościowe i bezpieczeństwa serwisu Sport.pl (kilka milionów odsłon dziennie!).
Precyzyjne wymagania fundamentem wysokiej jakości oprogramowania - teoria a praktyka.
Dokładna definicja i specyfikacja wymagań dotyczących oprogramowania jako bardzo istotny czynnik decydujący o końcowym sukcesie projektu. Z jednej strony rzetelnie opisane zapotrzebowanie, mechanizmy oprogramowania oraz cele bardzo ułatwiają pracę i warunkują powodzenie – drugiej jednak praktyka zmusza często do weryfikacji założeń już w trakcie pracy. Jak pogodzić jedno z drugim? Zagadnienia dotyczące ustalania, tworzenia oraz modyfikacji specyfikacji technicznych i funkcjonalnych w projektach tworzenia oprogramowania.
Testowanie na podstawie ryzyka - ostateczne rozwiązanie tajemnicy.
Jak wyliczyć zwrot z inwestycji w jakość? Czy jakość ma swoje ROI? Jakie przyjąć założenia odnośnie nakładów związanych z testami oprogramowania oraz na innymi działaniami wspierające jakość. W jaki sposób klasyfikować nakłady na jakość, jak nauczyć się wyliczać ROI związane z jakością oprogramowania w organizacji i w jaki sposób doskonalić te umiejętności.
Prowadzenie sesji: Przemysław Gamdzyk, IDG Poland SA
Udoskonalenie procesu testowego wg. TPI.
Test Process Improvement jako jedna z głównych metodyk doskonalenia testów. Wykorzystanie TPI do oceny mocnych i słabych stron aktualnie wdrożonego procesu testowego w organizacji. W jaki sposób wykorzystać tę metodykę, by usprawnić proces testowy i zwiększyć efektywność testów w organizacji.
Testowanie oprogramowania w trakcie realizacji zamówień publicznych.
Zasady tworzenia dokumentacji zgodnej z rozporządzeniem ministerialnym nt. testów akceptacyjnych w oparciu o narzędzie uniTestManager.
Testowanie oprogramowania na urządzania wbudowane - na przykładzie dekoderów.
Czy jest testowania oprogramowania na urządzenia wbudowane. Jakim testom można poddać dekoder (testy manualne i automatyczne, testy wymagań, testy regresyjne i funkcjonalności, retesty, testy instalowalności i testy w oparciu o standardy). Projektowanie przypadków testowych. Wykorzystywane narzędzia (Excel, RedHat, DecTec StreamXpress, Bugzilla, Tera-Term).
Testowania oprogramowania dla banków.
Testowanie oprogramowania zgodnie z Rekomendacją D Komisji Nadzoru Finansowego.
Przerwa na kawę i herbatę. Networking.
DYSKUSJA PANELOWA - Jakość w świecie IT - ideał i cel czy tylko pusty slogan?
Jakość jest niemierzalna w sensie ścisłym - i jako taka nie może być używana bezpośrednio do zarządzania. Próby uczynienia jakości mierzalną skutkują sprowadzeniem jej do poziomu wybranych atrybutów, takich jak: liczba funkcji, zwrot z inwestycji, liczba defektów na produkcji, czas od pomysłu do wdrożenia. Te atrybuty mogą być łatwo mierzone, przeliczane na pieniądz i jednoznacznie używane do zarządzania firmą lub projektem. Czy w takim razie pojęcie „jakości” wnosi cokolwiek do naszej praktyki działania?
Analogią mogą być np. telefony które psują się po 2 latach – bo na dwa lata podpisujemy umowę z operatorem, auta po 5 latach bo na tyle bierzemy leasing, pralki po 3 bo tyle wynosi gwarancja. Firmy produkcyjne już dawno przestały postrzegać niezawodność jako atrybut jakości. Czy w tym kontekście dążenie do „najwyższej jakości” w branży IT nie jest anachronicznym i romantycznym frazesem?
Udział wezmą: zaproszeni menedżerowie IT z dużych przedsiębiorstw.
Prowadzenie dyskusji: Tomasz Osojca, CORRSE
Prowadzący poranną sesję plenarną: Marek Rzewuski, Computerworld
Rejestracja uczestników. Poranna kawa i herbata.
Dlaczego wszyscy ludzie (czasem) kłamią i jak to się ma do jakości w IT?
Zarządzanie to w 90 procentach komunikacja. To nie byłoby takie straszne, gdyby nie to, ze spora jej cześć nie jest prawdziwa. Oficjalnie nie mamy problemów, nie mamy słabości, a błędy są "innowacyjnym podejściem do wymagań klienta”. Dlaczego tak się dzieje? Co zrobić, zęby wiedzieć jak jest naprawdę? Jak zbudować zespól, który skupia się na pracy, a nie polityce? Poznaj podejście KISS PM i praktyczne sposoby na odkrycie prawdy. Pytanie, czy prawda Ci się spodoba.
Usuwanie ograniczeń rozwoju aplikacji za pomocą wirtualizacji usług*
Rosnąca złożoność i wzajemne powiązanie różnych środowisk IT, ciągłe pojawianie się kolejnych wersji systemów w połączeniu z częstą stagnacją albo spadkiem budżetów sprawiają, że dostarczanie aplikacji o wysokiej jakości staje się wyzwaniem dla wielu firm. Odpowiedzią może być wykorzystanie nowych technologii i nowe podejście do tych kwestii – chodzi o usunięcie ograniczeń w dostępie do systemów, obniżenie kosztów sprzętu i licencji a ostatecznie skrócenie czasu dostarczenia aplikacji. Wszystko dzięki wykorzystaniu rozwiązania wirtualizacji usług– na przykładzie CA Service Visualisation.
*prezentacja prowadzona będzie w języku angielskim
Narzędzia wspierające dewelopment – to prawdziwy dopalacz w projektach czy może raczej hamulec i kotwica?
Wdrożenie systemów wspomagających wytwarzanie oprogramowania nie może być celem samym w sobie. Jak uczy doświadczenie zakup i implementacja narzędzi typu ALM w najmniejszym stopniu nie gwarantuje sukcesu z jego użycia, a niesie za sobą wiele ryzyk. Co więcej, w niedojrzałych i nieprzygotowanych na zmianę organizacjach może przynieść więcej szkód niż pożytku. Dlatego także ważne są pytania: jakie przyjąć założenia, aby optymalnie wykorzystać dobrodziejstwa narzędzi? Jakich typowych błędów należy unikać w trakcie wyboru i wdrożenia tzw. toolingu w organizacji?
Zaadresowanie naszych potrzeb w trakcie ewaluacji narzędzi, a także polityka wdrożeniowa muszą być odpowiednio przemyślane, by nie narażać firmy na niepotrzebne koszty. Nie chodzi tu tylko o koszty stricte finansowe, ale także o morale załogi. Znacznie taniej uczyć się na błędach innych.
Rynek pracy IT w Polsce – najbardziej aktualne dane i wprowadzenie do dyskusji.
DYSKUSJA PANELOWA - Jakość na rynku pracy.
Kariera i praca – jak długo jeszcze będzie trwała na rynku koniunktura dla specjalistów zajmujących się tworzeniem i testowaniem rozwiązań IT? Krótkofalowe czynniki wewnętrzne a znaczenie trendów długofalowych i innowacji z samym IT. Możliwości polskiego rynku pracy a kariera za granicą. Kogo dzisiaj potrzebuje rynek pracy, kogo będzie potrzebować jutro?
Prowadzenie dyskusji: Przemysław Gamdzyk, IDG Poland
Przerwa na kawę i herbatę. Networking.
Praktyczny przegląd dostępnych narzędzi wspierających zarządzanie jakości i zapewnienie jakości w procesach tworzenia oprogramowania i systemów informatycznych.
Proces zapewnienia jakości, aby był efektywny, musi dotyczyć wszystkich aktywności w projekcie informatycznym oraz angażować wszystkich członków zespołu projektowego. W ramach wystąpienia słuchacze będą mieli okazję zapoznać się z „jakościowym spojrzeniem” na różne narzędzia wykorzystywane w procesie produkcji oprogramowania. „Jakościowe spojrzenie” oznacza w tym przypadku sposób w jakim te narzędzia a dokładnie mówiąc dane w nich gromadzone przy okazji realizacji standardowych prac projektowych mogą wspierać zapewnienie jakości. Szczególna uwaga zostanie zwrócona na integrację narzędzi w jedno całościowe rozwiązanie pozwalające na zapewnienie jakości „od wymagań do linii kodu”.
Standardy jakości i audyt oprogramowania - czy jest się czego bać?
Warsztaty prowadzone są w formie gry zespołowej z elementami rywalizacji. Grę poprzedza krótkie wprowadzenie do standardów (na wypadek braku udziału w wykładzie) oraz krótkie wprowadzenie do zasad gry.
Uczestnicy dowiadują się, iż klient wymaga od nich wprowadzenia środków poprawiających jakość oprogramowania i przewiduje wykonanie audytu. Od wyników audytu uzależnia dalszą współpracę. Preferowane jest wprowadzenie środków przewidzianych przez któryś ze znanych standardów z dziedziny functional safety.
Uczestnikom przedstawiany jest „team” składający się z paru osób – najlepiej przedstawicieli różnych zawodów: Tester, QA Manager, Developer, Team Lead, Product Manager, CTO lub jakiś inny manager. Następnie drużyny uczestników dostają kolejne zadania w postaci nagranych wypowiedzi członków ‘team-u’. Uczestnicy mają wytypować która z wcześniej nagranych osób prawidłowo odpowiedziała na pytanie.
Część I
Ustalenia ogólnej strategii pod audyt. W części teoretycznej prowadzący nakreśli założenia teoretyczne. Na tej podstawie zespoły opracują V&V plan - wytypują, jakie praktyki wybrać i wprowadzać w firmie w celu poprawy jakości oprogramowania. Następnie prowadzący przedstawi i omówi poprawną procedurę i oceni pracę zespołów.
Część II
Wprowadzimy i omówimy praktyki przewidziane przez standardy functional safety, podzielone na 4 kategorie:
1) Analiza statyczna
2) Unit testy / testy regresyjne
3) Code review
4) Testy manualne
Dla każdego z tych zadań będzie kilka problemów do rozwiązania . Na każdy problem przygotowujemy 6 nagranych wypowiedzi. Drużyny muszą podać, która z nagranych osób podała właściwe rozwiązanie. Następnie prowadzący podaje właściwą odpowiedź wraz z wyjaśnieniem i przyznaje zespołom punkty.
Część III
W części audytowej każda drużyna wybiera swojego przedstawiciela z nagranego 'team-u'. Osoby nagrane podają odpowiedzi do audytora. Drużyny, których przedstawiciele podali poprawne odpowiedź, otrzymują punkty.
Zabawę kończy podsumowanie wyników i przyznanie nagród.
Prowadzenie: Parasoft
Testowanie na podstawie ryzyka.
Od lat zadajemy sobie to samo pytanie: jak osiągnąć optymalną z punktu widzenia biznesowego równowagę między kosztami jakości, a kosztami braku jakości? W odniesieniu do testowania, to pytanie brzmi: jak oszacować najwłaściwszy dla danego projektu poziom nakładów na testowanie, tak by zminimalizować koszty naprawiania defektów i awarii, ale nie spowodować nadmiernego wzrostu kosztów samego testowania?
Ogólna odpowiedź na to pytanie jest dobrze znana od co najmniej dwudziestu lat: trzeba uwzględnić poziom ryzyka. Im większe jest ryzyko (konsekwencje i prawdopodobieństwo) możliwych awarii, tym więcej warto zainwestować w zapobieganie ryzyku, czyli w testowanie. Ta zasada jest wprawdzie słuszna, ale nie pozwala w praktyce uzyskać konkretnych odpowiedzi na podstawowe pytania, takie jak, na przykład:
• O ile zmaleje ryzyko awarii, jeśli obok dotychczasowych testów projektowanych ad hoc, zaczniemy także projektować testy na podstawie modeli?
• O ile zmaleje ryzyko awarii, jeśli podwyższymy wymagane pokrycie testowe z 90% pokrycia instrukcji, do 95% pokrycia rozgałęzień?
• W budżecie projektu przeznaczono o 100 tysięcy złotych więcej niż dotąd na zapewnienie jakości, a celem kierownictwa jest zmniejszenie kosztów awarii po wdrożeniu o co najmniej tę samą sumę. W jakiej proporcji przeznaczyć te pieniądze na
(a) inspekcje specyfikacji wymagań
(b) automatyczne testy statyczne kodu źródłowego
(c) automatyzację dotychczasowych testów ręcznych i poszerzenie ich zakresu
(d) wprowadzenie dodatkowych sesji testowania eksploracyjnego
(e) zatrudnienie osoby, która będzie nadzorować porządek w zarządzaniu konfiguracją i zmianami?
Podobne pytania można mnożyć, ale nie ma tutaj gotowej łatwej odpowiedzi – można natomiast poznać metody, za pomocą których można stopniowo zbliżać się do coraz lepszego oszacowania zysków i kosztów w tych obszarach. Warsztaty będą miały formę praktycznych ćwiczeń, w trakcie których będziemy szukać propozycji możliwych przedsięwzięć mających na celu obniżenie ryzyka.
Obiad na zakończenie konferencji
Regulamin
© Copyright 2024 International Data Group Poland S.A.
00-131 Warszawa, ul. Grzybowska 2/44
tel. +48 22 3217800