Reqmagazyn Wydanie 6 by Monika Perendyk

N r 6 (1/2017)

REQ

m a g a z y n

Testy AB Na Styku Biznesu

Dobry

z n i c h k o r z y s ta ć ?

p o c z ąt e k

inżynieria wymagań

inżynieria oprogramowania

dlaczego warto

Fuzzy Logic and Decision Trees approach

user experience

zarządzanie projektami

prawo w

procesy biznesowe

Szanowni Państwo Drogi Czytelniku, na Twoje ręce oddajemy kolejny numer naszego magazynu. W tym numerze możesz przeczytać o tym czym jest jakość w oprogramowaniu i jak jest definiowana przez różnych uczestników projektu. Złożoność wymagań to zmora wielu analityków biznesowych, inżynierów wymagań, w tym numerze możesz przeczytać o tym jak poradzić sobie z tym zagadnieniem za pomocą drzewa decyzyjnego. To pierwszy anglojęzyczny artykuł w naszym numerze. Maj-czerwiec to czas konferencji IT. Jak co roku nie mogło zabraknąć również konferencji dla analityków biznesowych i inżynierów wymagań, która odbędzie się 5-6 czerwca w Warszawie. To już III edycja Konferencji Inżynierii Wymagań i Analizy Biznesowej, na którą serdecznie zapraszamy.

Miłego czytania

Monika Perendyk Prezes Stowarzyszenia Inżynierii Wymagań Redaktor Naczelna

REDAKCJA Opracowanie i redakcja: Redaktor naczelna: Monika Perendyk Zespół redakcyjny: Włodzimierz Dąbrowski Artur Kiełbowicz Rafał Stańczak Marek Zawadzki Korekta: Ewa Brzeska Projekt graficzny i skład: Dagmara Zawada-Żark

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.

Facebook

http://www.facebook.com/reqmagazyn

Reklama

kontakt@reqmagazyn.pl

Współpraca

Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: kontakt@reqmagazyn.pl

Zdjęcia

siw.org.pl

między

a IT

warsztaty seminarium spotkania

biznesem

analiza systemowa zarządzanie projektami BPMN UML analiza biznesowa testy akceptacyjne BDD

architektura korporacyjna

zarządzanie procesami biznesowymi FDD modelowanie

ATDD

Treści

Spis

Słowo wstępu

Inżynieria Wymagań Katarzyna Nowak-Rybka Dobry początek

User Experience Grzegorz Rusiecki Testy AB - dlaczego warto z nich korzystać?

Zarządzanie Projektami Ewa Brzeska Na styku biznesu i IT: Jakość oprogramowania

Oleksii Sokolov Fuzzy Logic and Decision Trees approach for ranking candidates to new project

Katarzyna Nowak Rybka

Inżynieria Wymagań

Dobry początek To, jaką metodą projekt jest prowadzony nie wpłynie na jego sukces, jeśli rozpocznie się niewłaściziś w IT, nie mówimy już tylko o projek- wie. tach, lecz o programach i produktach dla Jak zatem zagwarantować sukces końcowy pronaszych klientów. To, co robimy w majektu? Jak podejść do tego zagadnienia od połej skali, projektowej, rzutuje na znaczczątku by uniknąć błędów w jego realizacji? O co nie szerszy aspekt. Zmiany, których dokonujemy pytać, aby uniknąć najczęstszych błędów? mogą mieć dotkliwe konsekwencje, zwłaszcza, jeśli są to zmiany w końcowej fazie tworzenia pro- Z pomocą przychodzą nam proste i znane wszystjektu. Niestety jest to wciąż częsta praktyka, która kim techniki – takie jak: warsztaty z interesariuszawpływa na wiele porażek. Stresujące wspomnie- mi, rozpoczęcie (kick-off) projektu, czy chociażby nia z końcowej fazy projektu pozostają w pamięci, dobrze zaplanowany pierwszy Sprint. dlatego opłaca się zadać sobie pytanie, „Czy możemy zrobić coś na początku by tego uniknąć?”.

Ważne jak się zaczyna

Poznajmy się

Projektowa codzienność, czyli zbyt krótkie terminy, zbyt duży zakres, często zbyt mała aktywność interesariuszy po stronie zleceniodawcy, umacnia przysłowiowego „złego doradcę” - pośpiech. Pośpiech projektowy towarzyszy nam już od początkowej fazy omawiania rozwiązania, czyli analizy potrzeb – jakże ważnego etapu procesu wytwarzania oprogramowania. Niejednokrotnie dochodzi do zmian potrzeb czy zakresu rozwiązania już na tym etapie. Dynamiczność rynku i zmienność potrzeb sprawiają, iż już po pozyskaniu dokumentów sprzedażowych „zatwierdzających start projektu” jego kształt ulega zmianie. Zdecydowanie dobrym rozwiązaniem są tu wówczas techniki zwinne (m.in. Agile), nie mniej jednak metody tworzenia programowania nie są odpowiedzią na wszystkie problemy procesu wytwarzania oprogramowania. 6

Rola analityka biznesowego w ostatnim czasie bardzo ewaluowała. Osoba ta nie jest już uznawana za skrybę projektu, czy kogoś wyszukującego dane. Okazuje się, że cechy interpersonalne i komunikacyjne oraz (w wielu przypadkach) wiedza techniczna są kluczowe w wykonywaniu tego zawodu. Ten zauważalny postęp w rozwoju roli analityka sprawia, że coraz częściej uczestniczy on we wcześniejszych fazach projektów. Co więcej, w projektach realizowanych w sposób zwinny rola analityka coraz bardziej zbliża się do roli właściciela produktu. Wiąże się to z jeszcze silniejszym wsparciem dla menadżerów projektu, dlatego warto już podczas pierwszych spotkań projektowych angażować obie role: analityka i menadżera. To czas nie tylko na ustalanie harmonogramów, ale też analityczne spojrzenie na procesy bizneso-

we w organizacji, mapy produktu czy integrację. Czas to pieniądz. Nie dziwi zatem nikogo, pośpiech w inicjowaniu projektów lub odwrotnie - opieszałość, gdy nikt nie ma czasu się nim zajmować. Niestety jest to moment najczęstszych błędów, które mogą rzutować na późniejszą współpracę. Nieporozumień, które narastając mogą spowodować, że miniemy się z oczekiwaniami klienta. Jedno- lub dwudniowy warsztat przeprowadzony z udziałem kluczowych ról projektowych może przynieść więcej korzyści niż kilkudniowe telekonferencje czy obszerna dokumentacja. Takie spotkanie oraz ich charakter poznawczy wpływa na atmosferę pracy a to przekłada się na wzajemne zaufanie i sukces długoterminowy.

Ważne, by wiedzieć, czego nie wiemy

1. Sprawdźmy, czy wiemy wystarczająco dużo o otoczeniu projektu: • Poznanie organizacji oraz procesów jej działania. Oczywiście mowa tu o zgrubnym poznaniu naszego klienta uwzględniającym niewielki czas początkowego etapu. Warto tu jednak dowiedzieć się choćby o plany rozwojowe firmy, czy platformy, której projekt dotyczy. Mogą one znacząco rzutować na tworzone oprogramowanie. Zauważone możliwości integracji czy rozwoju budowanego rozwiązania mogą wpłynąć nie tylko na wymagania niefunkcjonalne rozwiązania, ale także przełożyć się na wzrost zadowolenia klienta, co zaowocuje chęcią długofalowej współpracy. • Poznanie interesariuszy. Warto już na początku zrobić macierz odpowiedzialności (RASCI Matrix) lub prostą mapę myśli (Mind Map), która pozwoli w łatwy sposób zidentyfikować interesariuszy i określić ich realny wpływ na rozwiązanie. Często mamy do czynienia z dodatkowymi podwykonawcami (np. w zakresie testów). Ich poznanie może być kluczowe do dalszej komunikacji

Jest wiele aspektów, którym warto się przyjrzeć na starcie współpracy i nie sposób ich wszystkich tutaj omówić. Rys.1 przedstawia najbardziej istotne elementy pierwszego spotkania. Część z nich można przygotować jeszcze przed warsztatem lub spotkaniem, a brakujące informacje pozyskiwać w trakcie spotkania. Prowadzone rozmowy będą wówczas dążyć do uzyskania jak największej liczby w kolejnych fazach projektu. Ponadto należy poodpowiedzi na nasze pytania. Oto kilka wskazó- znać relacje pomiędzy poszczególnymi interesariuszami by zrozumieć potencjalne niespójności wek, na których warto się skupić. w zgromadzonych wymaganiach. • Poznanie innych produktów klienta oraz dziedziny jego działalności. Znajomość portfolio klienta może to być przydatna przy integracji systemów, lub wyłącznie w celu określenia czy projektowane rozwiązanie ma graficznie i funkcjonalnie przystawać do pozostałych rozwiązań klienta. • Poznanie planów dotyczących samego projektu. Zdarza się, że klient nie ujawnia swoich planów wprost. Często nie wiemy od razu, czy rozwiązanie ma być częścią platformy, czy ma występować jako niezależny produkt, czy tylko element większego programu zmian w organizacji.

Rys. 1 Pierwsze kroki na start

2. Upewnijmy się, że wiemy, do czego dążymy produktu (ang. Product Owner - PO): i gdzie jesteśmy. Trzeba zatem: • Rola w zbieraniu wymagań. • Potwierdzić lub zbudować harmonogram prac Obecnie w większości realizowanych projektów (Road Mapę) i określić cele projektu. po stronie klienta wyznaczona jest osoba odpoKażdy z interesariuszy może mieć inne cele. Po- wiedzialna za kontakty z dostawcą i wyznaczanie dobnie jak każdy poziom w organizacji może ina- kierunków działań. Realia pokazują jednak, iż taka czej postrzegać kryteria sukcesu projektu. Nie- osoba często jest powoływana do tej roli w ramniej jednak ważne by cele i plany projektu były mach dodatkowych obowiązków, lub nie posiada zaznaczone i zakomunikowane odpowiedniej gru- w pełni wiedzy dziedzinowej. Współpraca i popie odbiorców. Zminimalizujemy w ten sposób ry- dział obowiązków pomiędzy właścicielem produkzyko częstych zmian w zakresie projektu, a co za tu a analitykiem są umowne i mogą się znacząco różnić w różnych projektach. Przykładowo, w jedtym idzie opóźnień w jego realizacji. nym projekcie zespół dostawcy ma dostęp do • Ustalić spójność celów. użytkowników końcowych i analityk sam pisze wymagania uzyskując ich akceptację od właściciela Cele interesariuszy mogą być rozbieżne, dlatego produktu. W drugim projekcie wszystkie kontakty istotnym jest by już w początkowej fazie projektu z użytkownikami należą wyłącznie do właściciela pomyśleć o formach kompromisu. produktu. Zależnie od sytuacji, należy wyraźnie zaznaczyć potrzebę ewentualnych dodatkowych • Audyt wymagań. kontaktów z ekspertami dziedzinowymi. Ustalenie Bywają projekty, których jesteśmy uczestnikiem wzajemnych oczekiwań znacząco poprawią komuw wyniku zmiany dostawcy. Warto tu zastosować nikację. audyt wymagań dotychczas zebranych, w celu ich potwierdzenia oraz sprawdzenia aktualności po- • Wyznaczenie zakresu odpowiedzialności. trzeb. Zdarza się, że właściciele produktów nie znają swoich obowiązków, dlatego podział pracy • Określić kryteria sukcesu. i wzajemne zaufanie ról jest tu szczególnie istotne, ale ważnym też jest by niektórych granic nie zacierać. Pewne elementy dotyczące ceremonii związanych z użytą metodą wytwarzania oprogramowania należy wyraźnie nazwać i ustalić na początku (np. kto jest opowiedziany za prowadzenie dema, • Ustalić ceremonie projektu oraz punkty kontrol- kto może zmieniać historyjki). ne i integracyjne. Kryteria sukcesu mogą być różne, dla różnych użytkowników. Wypada wiedzieć, kto te kryteria wyznacza i w jaki sposób. To głównie rola właściciela produktu, ale nie zawsze jest on w projekcie dostępny.

Każda ze stron powinna mieć takie samo zrozumienie poszczególnych ceremonii i terminów re- 4. Upewnijmy się, że mówimy tym samym językiem: alizacji. W organizacjach, w których metodyki zwinne do- • Słownik pojęć. piero raczkują, jest to ważny element zaznaczenia Choć pojęcie to budzi niechęć zwłaszcza wśród wzajemnych oczekiwań. doświadczonych kolegów, taki słownik powinien powstać zawsze. Nie musi on być jednak opisem formalnym. Chodzi wyłącznie o to by obie strony 3. Poświęćmy chwilę na dyskusję o obowiązkach rozumiały pewne pojęcia w identyczny sposób. analityka (ang. Business Analyst - BA) i właściciela Dotyczy to zarówno wiedzy domenowej, jak i po8

projektu. Będzie to obopólna wartość dodana, gdyż dla analityka rola menadżera i jego pomoc • Operujemy na tych samych danych. będzie nieoceniona. Natomiast dla menadżera, będzie to wsparcie w podejmowaniu decyzji proDuża część realizowanych projektów odbywa się jektowych. Dobrze ułożone relacje, także te lokalna danych testowych. Są one zanonimizowane ne, przekładają się na wspólny sukces końcowy. zanim trafią do zespołu lub próbka danych jest mała. To częste problemy nie tylko fazy testów, Bibliografia: ale także analizy wymagań. Często, bowiem analityk opisuje wymagania używając przykładu opar- Książka: tego na posiadanych danych. W takich sytuacjach reprezentatywność wykorzystanych danych i ich Jake Halloway, David Bryde, Roger Joby, „A Pracjednolitość po obu stronach znacząco wpływa na tical Guide to Dealing with Difficult Stakeholders”, Gowr publishing Limited, 2015, ISBN: kanał komunikacyjny PO – BA. 9781409407379 jęć związanych z ceremoniami.

Gra do wspólnej bramki

Ken Schwaber, „Agile Project Managment with Powyżej omówione zostały tylko wybrane aspek- Scrum”, Library of Congress Cataloging-in-Publity, którym warto się przyjrzeć na starcie projektu. cation Data, ISBN 0-7356-1993-X Nie sposób ich wszystkich tutaj omówić. JednakStrony internetowe: że wyżej wymienione kroki, nawet przy małym nakładzie pracy czy ograniczonej ilości czasu, mogą 1. https://pl.wikipedia.org/wiki/Macierz_odpoprzynieść wymierne korzyści w dalszej fazie pro- wiedzialnosci [10.01.2017] jektu. Każdy projekt jest inny i każdy należy trakhttps://pl.wikipedia.org/wiki/Mapa_mysli tować indywidualnie. Wystarczy, bowiem jedna 2. zmiana w otoczeniu projektu, a jej wpływ może [10.01.2017] zaważyć na końcowym sukcesie. 3. https://www.wrike.com/project-managePrzedstawione przykłady dotyczą głównie współ- ment-guide/faq/what-is-a-roadmap-in-projectpracy z klientem, ale można je przenieść także na -management/ [30.01.2017] grunt lokalny, organizacji zespołu, w którym pracujemy. Trendy panujące na rynku i ewolucja roli analityka sprawiają, że zarówno rola i jego obowiązki w różnych firmach są odmienne. Należy pamiętać, że także granice roli menadżera projektu nie są sztywne. Dlatego należy już na początku wypracować wspólne zrozumienie odpowiedzialności nie tylko z klientem, ale także z menadżerem

Katarzyna Nowak-Rybka, Analityk Biznesowy w Objectivity Bespoke Software Specialists. Lider zespołu. Pracowała w dużych projektach oraz programach dla różnych dużych klientów zagranicznych tworząc oprogramowanie dostosowane do ich potrzeb. Zajmowała się projektami jako samodzielny analityk biznesowy, analityk programowy czy lider zespołu. Doktor nauk technicznych Wydziału Elektroniki Politechniki Wrocławskiej. Absolwentka studiów podyplomowych z zakresu zarządzania projektami na Wydziale Informatyki i Zarządzania Politechniki Wrocławskiej pod patronatem „International Project Management Association”. Stażystka w ramach programu Top 500 Innovators na University of California, Berkeley, USA. Współtwórca wrocławskich spotkań analityków – Business Analysts Meetup (https://pl-pl.facebook.com/businessanalystmeetup/; https://www.linkedin.com/groups/8414881/profile ). 9

Grzegorz Rusiecki

UX user experience

Testy AB - dlaczego warto z nich korzystać?

szystkie cechy Twojej strony internetowej wpływające na percepcję użytkowników takie jak: kolory, ich układ na stronie, styl komunikacji etc., determinują to, w jaki sposób użytkownicy z niej korzystają, co za tym idzie, jak i czy realizują założone przez Ciebie cele biznesowe. Wykorzystując podstawy psychologii poznawczej możemy założyć, że wybrane wskazania dotyczące wyglądu oraz funkcji Twojego serwisu będą odpowiednie, jednak dopóki nie skonfrontujemy przyjętych założeń z kontekstem jego użytkowników, nie otrzymamy możliwości poznania ich reakcji, w przełożeniu na określone mierniki sukcesu. Dlatego opieranie się wyłącznie na ogólnych wskazówkach może okazać się niewystarczające i zazwyczaj tak jest.

i zrealizować testy multiwariacyjne, różniące się od testów AB ilością podstron i elementów testowanych w ramach jednego badania. Wyciągniesz w ten sposób jeszcze więcej ciekawych wniosków w tym samym czasie.

Dlaczego powinieneś robić test AB?

Głównym powodem, dla którego powinieneś realizować testy AB jest stosunek niewielkiego nakładu pracy związanej z uruchomieniem takiego badania do potencjalnych korzyści wynikających z porównania dwóch różnych wersji tej samej podstrony. Nierzadko bardzo drobna zmiana np. koloru głównego przycisku CTA (Call to Action) zwiększa wskaźnik konwersji, którą w tym przypadku będzie współczynnik kliknięć CTR (Click Through Dlatego jeśli jesteś na etapie optymalizacji swo- Rate), nawet o kilkaset procent. jego serwisu czy usługi, zastanawiania się jakie Dlatego jeśli do tej pory Twoim sposobem na zmiany przyniosą korzyści i wpłyną pozytywnie na wzrost np. liczby rejestracji w serwisie czy subrealizację założonych celów, powinieneś zwrócić skrypcji newslettera było zwiększenie budżetu uwagę na jedną z metod badawczych, jaką są Temarketingowego, powinieneś pomyśleć o realisty AB oraz Testy MV (Multiwariacyjne). zacji testów AB. W przeciwieństwie do działań Testy AB to w założeniach bardzo proste badanie związanych ze zwiększeniem ruchu w serwisie, polegające na porównaniu dwóch różnych wersji poniesiesz jednorazowy koszt realizacji badania, tej samej strony internetowej (dokładnie wybranej uzyskując ten sam a nawet lepszy i przede wszystpodstrony), których celem jest sprawdzenie, która kim długotrwały efekt. wersja konwertuje lepiej. Dlaczego celem powinPoniższy przykład pokazuje jak niewielka zmiana na być konwersja? O tym w dalszej części tekstu. sposobu komunikacji: dodanie do formularza reMożesz także pójść od razu kilka kroków dalej alnych korzyści wynikających z zapisania się do 10

newslettera, wpłynęła pozytywnie na wskaźnik Po usunięciu wspomnianej grafiki, liczba uzupełnionych formularzy wzrosła o 12,6%. Dlatego tak konwersji o 83,75%! ważne w kontekście optymalizacji konwersji jest to, aby decyzje projektowe podejmować wyłącznie w oparciu o ściśle określone mierniki sukcesu, a nie własną intuicję czy głos większości w zespole. Równie niebezpieczne jest kopiowanie tzw. wzorców, będących wynikiem testów w innych serwisach, bez ponownego porównania ich w kontekście użytkowników Twojego serwisu. To samo badanie w dwóch różnych serwisach może dać Rys. 1 https://vwo.com/blog/high-converting-copy-tweaks- zupełnie inne wyniki. Wzorce wynikające z badań innych powinny być dla Ciebie jedynie wskazów-for-ab-testing/ ką, którą warto wziąć pod uwagę w testach AB Porównaj koszt wdrożenia takiej zmiany z kosz- realizowanych we własnym serwisie. tem zwiększenia ruchu w serwisie o 83,75%. Brzmi zachęcająco? A co, jeśli w kolejnej iteracji tego Od czego zacząć? samego badania uzyskasz dodatkowe 20-30%? Jest to możliwe, ponieważ kolejną zaletą testów Podstawową zasadą w realizacji testów AB jest AB jest to, że nigdy nie możesz uznać danej wersji postawienie odpowiednich hipotez, które zostaną podstrony za najlepszą. Możliwości optymalizacji zweryfikowane w trakcie badania. To postawione hipotezy determinują zmiany projektowe do są wręcz nieograniczone! badania. Korzystając z różnego rodzaju narzędzi Kolejnym powodem, dla którego warto skupić się agregujących dane ilościowe dot. zachowań użytna testach AB jest intuicja, która bardzo często kowników w Twoim serwisie (np. Google Analyzawodzi. To, co na pierwszy rzut oka z projekto- tics) możemy zacząć zadawać pytania np.: wego punktu widzenia wydaje się być oczywiste, • Dlaczego tylko 2% użytkowników zapisuje się np. ograniczenie liczby pól formularza rejestracji do newslettera? do wybranej usługi, w konfrontacji z kontekstem • Dlaczego tylko 15% użytkowników zapoznająużytkownika i ściśle określonym miernikiem sukcych się z cennikiem usługi, decyduje się opłacesu może okazać się po prostu nietrafionym pocić abonament? mysłem. • Dlaczego tylko 10% użytkowników klika w przySpójrz na poniższy przykład i odpowiedz sobie cisk „Załóż darmowe konto”? na pytanie, czy dodanie do formularza rejestracji • Dlaczego tylko 35% osób decydujących się na elementu graficznego komunikującego gwarancję założenie konta, finalizuje rejestrację? bezpieczeństwa wprowadzanych danych, wpłynie Zwróć uwagę, że do każdego z zadanych pytań pozytywnie na konwersję? możemy przypisać ściśle określoną akcję, którą muszą wykonać użytkownicy, aby mówić o sukceOdpowiedź brzmi: niekoniecznie. W przypadku sie: tego badania wersja B okazała się skuteczniejsza. • Uzupełnienie i wysłanie formularza subskrypcji. • Wykonanie płatności za wybrany abonament. • Kliknięcie w przycisk. • Uzupełnienie i wysłanie formularza rejestracji. Dlaczego tak ważne w testach AB jest zadawanie pytań ubranych w kontekst wykonanej akcji? Ponieważ bez określenia jaką akcję muszą wykonać Rys. 1 http://unbounce.com/a-b-testing/shocking-results/

użytkownicy w serwisie, nie będziemy w stanie gardła), hipotezy oraz akcje do wykonania i mierokreślić miernika sukcesu dla badanych zmian, niki sukcesu, możemy przejść do projektowania zmian, które zostaną zbadane. Zwróć uwagę, że czyli definicji konwersji określanej w procentach. każda zmiana projektowa (wersja badanej podOdpowiedzią na zadane wcześniej pytania są hi- strony) powinna być odpowiedzią na postawioną potezy, które zweryfikujemy w trakcie badania np.: hipotezę. • Dlaczego tylko 2% użytkowników zapisuje się do newslettera? o Ponieważ nie komunikujemy żadnej korzyści wynikającej z subskrypcji. o Ponieważ przycisk z CTA jest słabo widoczny. o Ponieważ wymagamy zbyt dużej ilości danych (pola formularza). • Dlaczego tylko 15% użytkowników zapoznających się z cennikiem usługi, decyduje się opłacić abonament? o Ponieważ cennik jest zbyt rozbudowany, przez co ciężko podjąć decyzję. o Ponieważ ceny są zbyt wysokie. o Ponieważ wymagamy zapłaty za rok z góry. • Dlaczego tylko 10% użytkowników klika w przycisk „Załóż darmowe konto”? o Ponieważ przycisk jest słabo widoczny. o Ponieważ użytkownicy chcą wypróbować usługę bez zakładania konta. • Dlaczego tylko 35% osób decydujących się na założenie konta, finalizuje rejestrację? o Ponieważ formularz jest zbyt rozbudowany. o Ponieważ wymagamy podania danych niepotrzebnych do korzystania z usługi. Nie ograniczaj się do postawienia wyłącznie jednej hipotezy dla danego problemu. Im więcej hipotez, tym większy potencjał badania i szansa na poprawienie wskaźników konwersji. Mając już dobrze zdefiniowane: problemy (wąskie

W celu przeprowadzenia badania możesz skorzystać z jednego z dostępnych narzędzi online np. Visual Website Optimizer (vwo.com) czy Optimizely (optimizely.com). Tego typu narzędzia nie wymagają wiedzy programistycznej, działają tak jak edytor WYSIWYG (ang. what you see is what you get). Bez problemu poradzisz sobie z jego obsługą.

Jak długo powinno trwać badanie? Kluczowym czynnikiem wpływającym na czas trwania badania jest liczba unikalnych użytkowników, odwiedzających Twój serwis. Im większa próba, tym szybciej zweryfikujesz postawione hipotezy a wynik badania będzie statystycznie istotny (Statistically Significant). Bardzo często wskaźniki uzyskane na początku badania mają się nijak do wyniku statystycznie istotnego, dlatego nie wstrzymuj badania zbyt pochopnie. Kolejnym parametrem wpływającym na czas trwania badania jest MDE (Minimum Detectable Effect), czyli zmiana współczynnika konwersji w porównaniu do jej bazowej wartości. Im wyższa zmiana współczynnika konwersji w trakcie badania nowej wersji podstrony, tym mniejsza próba użytkowników potrzebnych do uzyskania wyniku statystycznie istotnego.

W celu oszacowania próby determinującej czas Ci wyeliminować kluczowe problemy UX w dużo trwania badania warto skorzystać z gotowych kal- krótszym czasie w porównaniu do testów AB. kulatorów np.:

Kiedy wdrożyć zmiany • https://vwo.com/ab-split-test-duration/ • https://www.optimizely.com/resources/sampleKiedy już osiągniesz satysfakcjonujący wynik nie -size-calculator/ możesz traktować go jak gwarancji na przyszłość. Przyzwyczajenia i potrzeby użytkowników ewoluTest AB czy MV ują w czasie, więc to, co działa dzisiaj, nie musi Podstawowa różnica między testami AB a testami zadziałać nawet w niedalekiej przyszłości. DlateMV to liczba kolejnych wersji badanej podstro- go powinieneś wdrożyć zweryfikowaną zmianę jak ny oraz liczba zmodyfikowanych elementów na najszybciej, nie tylko dlatego aby korzystać z niej jednej podstronie, co za tym idzie, także dłuższy jak najdłużej, ale również dlatego, aby od razu czas potrzebny na zweryfikowanie wszystkich po- uruchomić kolejną iterację testu tej samej podstawionych hipotez. Dlaczego? Ponieważ bada- strony, w którym wdrożona zmiana będzie bazową jąc tylko dwie wersje A i B, cały ruch skierowa- wersją A. ny do badania podzielimy na pół: 50% do wersji A i 50% do wersji B. Każda kolejna wersja C, D… Bibliografia: zmniejsza próbę użytkowników skierowanych do określonej wersji, przez co czas potrzebny na uzy- Strony internetowe: skanie wyniku statystycznie istotnego wydłuża się https://vwo.com/blog/high-converting-copy-tweproporcjonalnie. aks-for-ab-testing/ Dlatego, jeśli dysponujesz niewielką próbą unikalnych użytkowników w Twoim serwisie, prawdopodobnie lepszym rozwiązaniem dla Ciebie będą klasyczne badania jakościowe z użytkownikami, które dzięki możliwości pogłębienia wywiadu, pozwolą

http://unbounce.com/a-b-testing/shocking-results/ https://vwo.com/ab-split-test-duration/ https://www.optimizely.com/resources/sample-size-calculator/

Grzegorz Rusiecki, Senior UX Specialist w Agencji UX Symetria. Z branżą internetową związany od 2006 roku. Doświadczenie zdobywał na wielu płaszczyznach: od kierowania projektami w dużych portalach, projektowania dla największych marek w Polsce oraz platform ecommercowych, po zarządzanie produktem i UX w środowisku startupowym. Zdobyte doświadczenie przekłada na skuteczne projekty serwisów i usług internetowych oraz aplikacji mobilnych. Agencja UX Symetria specjalizuje się w projektowaniu złożonych interfejsów i przeprowadzaniu badań użyteczności. Od 1998 roku eksperci agencji doradzają i wykonują projekty dla dużych polskich i zagranicznych firm. Obecnymi klientami Symetrii są m.in. Alior Bank, BZ WBK, Credit Agricole, Deutsche Bank, Hestia, ING, LIDL, LOT, Orange, Philip Morris International, PKO, PZU.

Ewa Brzeska

Zarządzanie Projektami

Na styku biznesu i IT Jakość oprogramowania

Wstęp

ryterium odpowiedniej jakości rozwiązania informatycznego jest bardzo często decydujące przy podejmowaniu decyzji odnośnie zakupu czy zlecenia realizacji takiego rozwiązania. Inwestor oczekuje oprogramowania wysokiej jakości i często jest świadom, że wyższa jakość kosztuje więcej niż niższa. Twórcy oprogramowania starają się zapewnić jakość produktu na etapie jego wytwarzania, gdyż wiedzą, że późniejsze usuwanie błędów i wad jest kosztowne i nieopłacalne. Obie strony stawiają sobie ten sam cel – jakość. Jednak pomimo tego, że zarówno zamawiający, jak i dostawca są zorientowani na jakość, często na etapie odbioru produktu lub później, podczas jego eksploatacji, okazuje się, że obie strony słowo „jakość” rozumiały inaczej. Dlaczego tak się dzieje? Ponieważ pojęcie „jakość oprogramowania” jest niejednoznaczne, a obie strony: biznes i IT używając tego pojęcia mogą mieć na uwadze zupełnie różne atrybuty produktu i zupełnie różne względem niego oczekiwania.

Czym jest lub co to jest jakość? Wg Platona jakość to pojęcie filozoficzne, oznaczające pewien stopień doskonałości. Ponieważ jednak niniejszy artykuł dotyczy kwestii oprogramowania, interesuje nas przede wszystkim tech14

niczne, a nie filozoficzne, ujęcie jakości. I tak: P.B. Crosby, amerykański przedsiębiorca, który na badania nad jakością poświęcił ponad 40 lat swojego życia, jakość określił jako zgodność ze specyfikacją. Wg ISO 9001:2008 jakość to stopień w jakim zbiór inherentnych1 cech spełnia wymagania. W.E. Deming jakość zdefiniował jako przewidywalny stopień jednorodności i niezawodności przy możliwie niskich kosztach i dopasowaniu do wymagań rynku. To jedynie kilka z wielu definicji jakości. Warto zauważyć, że z jednej strony jakość definiowana jest w odniesieniu do zgodności ze specyfikacją oraz stopnia spełnienia wymagań, z drugiej do możliwie niskich kosztów [wytwarzania] oraz dopasowania do wymagań rynku. Zastanówmy się zatem jakie jest znaczenie wymienionych kryteriów w kontekście jakości oprogramowania. Czy powyższe definicje oznaczają, że oprogramowanie powinno być jednocześnie niezawodne, wytworzone niskim kosztem, zgodne ze specyfikacją, spełniające wymagania oraz dopasowane do potrzeb rynku? Taki zestaw atrybutów jest wysoce pożądany, lecz 1 Inherencja – przynależność, nierozłączność – http://sjp.pwn.pl/slowniki/inherentny.html Inherentny – nierozłącznie z czymś związany, tkwiący w istocie, strukturze, naturze czegoś – https://pl.wiktionary.org/wiki/inherentny

w praktyce bardzo trudny do jednoczesnego zapewnienia. Zapewnienie wysokiej jakości zwiększa zazwyczaj koszty wytwarzania, co pozostaje w sprzeczności z kryterium niskich kosztów. Oprogramowanie w pełni zgodne ze specyfikacją i spełniające wymagania interesariuszy może okazać się niedopasowane do potrzeb rynku. Jak takim razie szukać optimum jakościowego podczas wytwarzania oprogramowania?

Jakość produktów informatycznych W kontekście produktów i projektów informatycznych parametr jakości występuje w dwóch kategoriach: • Jakość oprogramowania jako produktu końcowego, rezultatu procesu wytwarzania prowadzonego w projekcie informatycznym • Jakość procesu realizacji samego projektu

wania decyzji czy systemy bankowe, a całkowicie inne – proste programy i aplikacje desktopowe czy mobilne służące rozrywce użytkownika. Kryteria jakościowe produktu powinny zatem każdorazowo zostać jednoznacznie zdefiniowane w fazie zbierania wymagań.”2 W swojej praktyce zawodowej od wielu lat realizuję duże projekty informatyczne w wyniku których powstają złożone systemy informatyczne, w tym oprogramowanie czasu rzeczywistego, średnie projekty rozwiązań użytkowych, w skład których wchodzą aplikacje desktopowe, webowe i mobilne oraz projekty niewielkie, których celem jest wytworzenie aplikacji mobilnych. Jako, że działania te prowadzę równolegle, poruszając się w obszarach różnych metodyk zarządzania projektami i wytwarzania oprogramowania, a czasem na styku tych metodyk, nieustająco na bieżąco porównuję kryteria jakościowe w tak różnorodnych typach projektów i produktów informatycznych. W praktyce przekonałam się, że wyrażenie „jakość oprogramowania” jest wielowymiarowe i niejednoznaczne, a jego znaczenie zależy przede wszystkim od kontekstu w jakim jest używane. Nauczyło mnie to, że pojęcie jakość zawsze powinno być doprecyzowane:

Wszystkie metodyki zarządzania projektami i wytwarzania oprogramowania uwzględniają kontrolę jakości lub zarządzanie jakością jako jeden z elementów procesu. Z uwagi na ograniczone ramy niniejszego artykułu nie będę omawiać szerzej tych zagadnień - skupię się jedynie na wybranych praktycznych kryteriach jakościowych. • jakie dokładnie wymagania jakościowe rozpatrujemy, O jakości oprogramowania jako produktu koń- • w stosunku do jakiego obiektu są definiowane, cowego procesu wytwórczego w projekcie infororaz matycznym wspomniałam już pokrótce w moim • kto jest interesariuszem definiującym te wymaartykule, który ukazał się w 2 numerze REQ Magania. gazynu: „(…) przyjmuje się, że produkt ma właściwą jakość, jeśli spełnione są kryteria yrażenie „jakość jakościowe określone w dokumentacji oprogramowania” projektu, w ramach którego produkt jest jest wielowymiarowe wytwarzany. W informatycznych projeki niejednoznaczne, a jego tach wytwórczych produktem jest oprogramowanie. Z racji różnorodności typów znaczenie zależy przede wszystkim od oprogramowania i jego przeznaczenia, kontekstu w jakim jest używane. nie można mówić o jednoznacznej definicji jakości, uniwersalnej dla wszystkich produktów. Inne normy jakościowe będzie miało oprogramowanie sterujące maszynami 2 „Na styku biznesu i IT: Zakres projektu inforlub procesami, inne – oprogramowanie czasu matycznego i zakres oprogramowania” – REQ rzeczywistego wspomagające procesy podejmoMagazyn nr 2 15

Jakość oprogramowania a różne perspektywy

rodzajów oprogramowania, celowo dobranych w taki sposób, aby najważniejsze dla nich kryteria jakościowe różniły się znacznie pomiędzy sobą.

Zarządzanie

W tabelach poniżej prezentuję najważniejsze kryteria jakości określane z perspektywy głównych Rodzaj oprogramowania grup interesariuszy, z perspektywy rodzajowej (rodzaju wytwarzanego oprogramowania) oraz z per- Oprogramowanie krytyczne (sterujące, bankowe, wspomaspektywy metodyki realizacji projektu. gające produkcję w newralInteresariusz

Najważniejsze kryteria jakości w odniesieniu do produktu (oprogramowania) lub procesu wytwórczego

Inwestor (biznes)

Produkt realizuje założony cel biznesowy, został zrealizowany w terminie i w założonym budżecie

Użytkownik

Funkcjonalność, łatwość obsługi, niezawodność

Wytwórca (IT)

Niski koszt wytworzenia oprogramowania, niskie koszty konserwacji i rozbudowy

Programista (IT)

Właściwa dla typu produktu technologia implementacji, czytelność kodu źródłowego, uniwersalność i przenaszalność

Najważniejsze kryteria jakości w odniesieniu do produktu Niezawodność (!), wydajność (szybkość działania), bezpieczeństwo

gicznych branżach jak energetyka, itp.) Oprogramowanie bankowe dla Łatwość obsługi, funkcjonalużytkownika końcowego

ność

Oprogramowanie dla groma-

Bezpieczeństwo, niezawod-

dzenia i zarządzania danymi (w

ność

tym krytycznymi i osobowymi) Oprogramowanie użytkowe

Funkcjonalność, zgodność ze

wspomagające zarządzanie

standardami, łatwość obsługi,

przedsiębiorstwem

bezpieczeństwo, niezawodność

Oprogramowanie służące

Atrakcyjność, funkcjonalność,

rozrywce: informacyjne portale

intuicyjność obsługi

internetowe i aplikacje mobilne, gry, itp.

Tabela 2 Najważniejsze kryteria jakości - perspektywa rodzajowa

kodu, łatwość testowania,

Dla zobrazowania różnic w kryteriach jakościowych w stosunku do różnych rodzajów oprogramowaAdministrator (IT) Niezawodność i właściwa nia posłużę się przykładem: wyobraźmy sobie, że wydajność oprogramowania, w oprogramowaniu tkwi błąd nie znaleziony w fałatwość instalacji, zarządzania zie testowania i nie usunięty przez programistów i serwisu przed przekazaniem oprogramowania do eksploaTabela 1 Najważniejsze kryteria jakości oprogramo- tacji. Błąd ten powoduje sporadyczne dzielenie wania - perspektywa interesariuszy przez 0, co jest matematycznie niedopuszczalne, a w oprogramowaniu najczęściej skutkuje dalszym nieoczekiwanym działaniem albo zaprzestaniem Niektóre kryteria wymienione w powyższej tabedziałania w ogóle. Oprogramowanie, w którym li mogą pozostawać ze sobą w sprzeczności (np. kryje się tego typu błąd staje się zawodne, co prniski koszt wytworzenia vs. uniwersalność i przezeczy kryterium niezawodności. naszalność kodu źródłowego vs. niezawodność i wydajność oprogramowania). Podczas realizacji Jeśli tego typu błąd zdarzy się w oprogramoprojektu konieczne jest takie dobranie kompromi- waniu krytycznym, np. w algorytmie kontrolująsów projektowych i jakościowych, aby w rezultacie cym prędkość samolotu – lot z dużym prawdootrzymać produkt o jakości zoptymalizowanej pod podobieństwem może zakończyć się katastrofą. kątem wymagań jakościowych wszystkich intere- W systemie bankowym – może skutkować błędsariuszy. ną transakcją finansową, w systemie zarządzania łatwość zarządzania kodem

W kolejnej tabeli zestawiłam kilka przykładowych 16

przedsiębiorstwem – może dostarczyć fałszywych

danych operacyjnych. Natomiast jeśli błąd taki wydarzy się w oprogramowaniu przeznaczonym do rozrywki, nie spowoduje żadnych poważniejszych konsekwencji. Być może oprogramowanie przestanie działać i użytkownik będzie musiał uruchomić go jeszcze raz, co może spowodować jego chwilowe niezadowolenie, lecz jest to praktycznie jedyna konsekwencja błędu. Dlatego też w oprogramowaniu rozrywkowym niezawodność nie jest jednym z najważniejszych kryteriów jakościowych. W tego typu oprogramowaniu natomiast na pierwsze miejsce przy ocenie jakości wysuwają się atrakcyjność, funkcjonalność i intuicyjność obsługi – to te atrybuty najczęściej decydują o rynkowym powodzeniu produktu.

W nowoczesnych, iteracyjnych procesach wytwarzania sterowanych wartością klienta pojęcie jakość oprogramowania nabiera nowego znaczenia. Procesy te z góry zakładają zmienność wymagań użytkownika i inwestora z racji dynamicznie zmieniającego się rynku. Ważnym kryterium jakościowym staje się zapewnienie wytworzonemu oprogramowaniu powodzenia rynkowego oraz realizacja założonego celu biznesowego. Z punktu widzenia nowoczesnego podejścia do wytwarzania oprogramowania produkt, który jest w pełni zgodny z wymaganiami niekoniecznie jest produktem wysokiej jakości.

Jeśli pomimo zgodności ze specyfikacją oprogramowanie nie realizuje założonego celu bizne„Rynkowe powodzenie produktu” – to wyrażenie sowego, może to oznaczać, że: w kontekście rozważań jakościowych pada niezbyt • Wymagania odnośnie oprogramowania, na często. Jednak, jak przekonałam się w praktyce, podstawie których oprogramowanie zostało przy obecnym nowoczesnym podejściu do wytzrealizowane, niedostatecznie uwzględniały warzania oprogramowania, wyższą wartością jest cel biznesowy przedsięwzięcia często stworzenie oprogramowania, które z po- • Niepoprawnie wyłoniono interesariuszy, reprewodzeniem przyjmie się na rynku niż to, aby to zentujących wymagania inwestora i różnych oprogramowanie było zgodne ze specyfikacją, grup użytkowników co stanowi jedną z miar jakości w podejściu tra- • Zebrane wymagania dycyjnym. Spójrzmy zatem na poniższe zestawieo nie były kompletne nie: jakość w odniesieniu do metodyki wytwarzao były sprzeczne, a sprzeczności nie nia oprogramowania. zostały rozwiązane Interesariusz

Najważniejsze kryteria jakości w odniesieniu do produktu (oprogramowania) lub procesu wytwórczego

Jakość

Zgodność produktu końcowego z wy-

Dla inwestora:

maganiami

• Realizacja założonego celu biznesowego • Maksymalny efekt rynkowy przy minimalnym koszcie wytworzenia Dla użytkownika – stopień zaspokojenia oczekiwań i potrzeb

Wada

Odstępstwo od specyfikacji wymagań

Z punktu widzenia inwestora: • Nie spełnienie założonego celu biznesowego • Brak rynkowego powodzenia produktu Z punktu widzenia użytkownika – nie zaspokojenie oczekiwań i potrzeb

Kryteria

• Mierzalne i obiektywne

jakości

• Dotyczące parametrów technicznych

• Oparte w dużej mierze na subiektywnych odczuciach

i atrybutów Sposób

• Właściwe zdefiniowanie wymagań

• Analiza rynku i konkurencji

zapew-

• Standaryzacja i kontrola procesu

• Ciągłe zmiany i priorytetyzowanie wymagań, aby nadążyć za dynamicznymi

nienia

wytwarzania oprogramowania

zmianami rynkowymi

jakości

• Testowanie produktu na zgodność

• Iteracyjny rozwój produktu sterowany maksymalizacją wartości klienta (inwe-

z wymaganiami

stora i użytkownika)

• Faza testów w końcowej fazie

• Zapewnienie jakości na każdym etapie rozwoju produktu – zapobieganie błę-

wytwarzania produktu - wykrywanie

dom i wadom

błędów i ich usuwanie

Tabela 3 Jakość – perspektywa metodyki wytwarzania oprogramowania

o nie zostały dostatecznie zweryfi-

kowane

• Kompromisy projektowe oraz atrybuty jakości oprogramowania nie zostały poprawnie określone i uzgodnione z inwestorem • Podczas realizacji projektu nie uwzględniono dynamiki zmian zewnętrznych (np. rynkowych)

Podsumowanie

punktu widzenia nowoczesnego podejścia do w y t w a r z a n i a oprogramowania produkt, który jest w pełni zgodny z wymaganiami niekoniecznie jest produktem wysokiej jakości.

W dzisiejszym świecie 2.0, w którym wieloma procesami mającymi wpływ na efekty naszej pracy, a także na nasze dobre samopoczucie, zdrowie i życie, zarządza oprogramowanie jego jakość stała się szczególnie istotna. Błąd krytyczny w oprogramowaniu sterującym stopień przyrumienienia grzanki w tosterze może skutkować jedynie jej spaleniem, ale już taki sam błąd w oprogramowaniu nadzorującym pracę elektrowni jądrowej może spowodować skutki w postaci katastrofy kosztującej życie i zdrowie wielu istnień ludzkich, zarówno w tym jak i w następnych pokoleniach. Podobnie błąd w prostej aplikacji używanej w chwili relaksu (gra, portal informacyjny) nie będzie miał dla nas praktycznie żadnych skutków oprócz może chwilowej irytacji, że aplikacja wyłączyła się, choć powinna działać. Jednak błąd w oprogramowaniu przeznaczonym do zarządzania procesami, organizacjami, czy przedsiębiorstwami może mieć określone skutki ekonomiczne, społeczne, czy polityczne teraz albo w mniej lub bardziej odległej przyszłości (np. dalekosiężne skutki decyzji podjętych dziś na podstawie błędnych danych podawanych przez błędnie działające oprogramowanie).

Zarządzanie

Dlatego tak istotne staje się zapewnienie odpowiedniej jakości oprogramowania. Odpowiedniej, tzn. takiej, która jest optymalna z punktu widzenia interesariuszy projektu, adekwatna do celu przedsięwzięcia oraz uwzględnia inne czynniki jak np. rodzaj oprogramowania.

Bibliografia: Książki: Pressman R.S., Praktyczne podejście do inżynierii oprogramowania, WNT Wydawnictwa Naukowo-Techniczne, 2006, ISBN: 83-204-2933-1 Wysocki K. Robert, dr, Efektywne zarządzanie projektami; Tradycyjne, zwinne, ekstremalne, Wydanie 6, Gliwice, Helion, 2013, ISBN: 978-83-2466891-5 Strony internetowe: https://pl.wikipedia.org/wiki/Jakość, dostęp: 17.03.2017. https://pl.wikipedia.org/wiki/Philip_Crosby, dostęp: 17.03.2017. https://www.jakosc.biz, dostęp: 17.03.2017

Ewa Brzeska, Manager i doradca IT, współwłaścicielka Ebitech Sp. z o.o. Od ponad 25 lat związana czynnie z branżą IT. W tym czasie uczestniczyła w realizacji wielu projektów informatycznych, pełniąc rolę kierownika projektów, analityka, projektanta, architekta i programisty. Wśród zrealizowanych przez nią systemów znajdują się rozwiązania wspomagające zarządzanie różnymi sferami biznesu i produkcji, dedykowane na różne platformy systemowe i sprzętowe. Skutecznie zarządza projektami i produktami informatycznymi oraz produkcją oprogramowania. Zajmuje się konsultingiem i doradztwem IT, wykorzystując przy tym bogate doświadczenie praktyczne oraz wiedzę teoretyczną, zdobytą między innymi w Szkole Głównej Handlowej w Warszawie. Współzałożycielka Stowarzyszenia Inżynierii Wymagań, Członek Zarządu I kadencji, obecnie Członek Komisji Rewizyjnej. 18

Oleksii Sokolov

Zarządzanie Projektami

Fuzzy Logic and Decision Trees approach for ranking candidates to new project

Introduction

design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. [5]

odern IT companies that are developing in parallel a huge quantity of projects using different business-process models and development models. The most popular models are Scrum[1], AgiNot all companies cannot afford to develop using le[2,3], Waterfall model[4]. agile method because of different departments Agile software development describes a set of and project members are located in different loprinciples for software development under which cations (cities, countries). In this regard, one of the requirements and solutions evolve through the most important target in Project Management is collaborative effort of self-organizing cross-func- to Save and to Improve project Teams. tional teams.[1] It advocates adaptive planning, The formation process of team that should be evolutionary development, early delivery, and involved in multiprojects is iterative and envisacontinuous improvement, and it encourages raging possibility to redistribution of team mempid and flexible response to change. [3] bers during projects lifecycle. Using an approach Scrum is an iterative and incremental agile softwa- that take in account team members skills allows to re development framework for managing product determine precisely the levels of skills and expedevelopment.[1][2] It defines „a flexible, holistic rience of each team member. All existing methods product development strategy where a develop- take in account only the presence of skill, but not ment team works as a unit to reach a common a skill level or experience with current skill. goal”,[3] challenges assumptions of the „traditional, sequential approach”[3] to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved. [4] The waterfall model is a sequential (non-iterative) 20

The presence of any skill means possession of competence by the person on a basic level, that does not ensure the effectiveness of the specified indicators of functioning (quality of performance) of multiproject team. Because in the project’s boundaries the necessary degree of competence can be different, there

is a need to develop effective methods for the formation of multiproject teams based on the level of competence (skills levels). In cases, when project team already been formed, some of team members could not have the necessary skill level, there are two ways to solve the problem: hiring a new specialist or advanced training of current specialist. In most cases hiring a new specialist need much more financial ant time recourses. In this case, it is more effective to develop the skills of current employees.

role in a project.

When there is a need to solve this problem of forming a new project team the main input data is Curriculum Vitae, that should be previously analyzed by Human Resources department and the CV’s should be formalized as a spreadsheet data. Also taken into consideration participation of candidate in previous completed projects, his involving in completed projects and his activities in completed projects. Based on all this data above, the top management should make a binary Having data of skills level of current team mem- subjective decision, that specialist is “Good” or bers, assessment of employees from managers, “Bad”. employees experience on current position, the manager can define which skill should be impro- In order to definition of possibility to add a speved to face the target (project target or other) with cialist candidate to project team basing on information about project proposed to compose minimal time and material costs. a test, which will consist of base directions of proThat is why the task of classification based on ject requirements for candidates for participation known database is actual for now. There are a lot in the project. of methods of building classification rules – from heuristic rules of Top management, to using intel- Let’s see on example of forming project team for lectual data analysis methods, like Decision trees, project of reconstruction of responsive web-source, created on Drupal CMS. Project team consist Bayesian rules, neural networks. of Graphic Designer, Front-end developer and back-end developer. As the first step let’s define a High-level project assumptions:

Main goal

1. To create new responsive UI there is no The main goal of this work is to develop a recom- need to take in account specifics of Drupal CMS. mendations of using a Bayesian method and builTo develop Responsive Front-End HTML ding basing on it a Decision Tree to finding a Skills 2. level of specialist and defining a specialist role in code, we need a specialist, that have skills of responsive Cross-browser coding using modern a project. technologies (HTML5, CSS3). During the solution of the problem of forming of To develop back-end of our web-source on a project team in multiproject environment the 3. CMS Drupal, we need a high skills specialist, that following aspects should be considered: have success experience of developing projects 1. Hiring a new specialist and definition of his such as current one. Because in current project we new the most appropriate role in company pro- need to reconstruct existing web-source, this specialist should also have an experience of working jects (multiproject environment) with “unfamiliar” code. 2. Rearrangement of current project team As a result of analysis of project specification we when team should be involved in a new project. can define a requirements system: The main target of this work is to develop a recommendations of using a Bayesian method and Graphic Designer building basing on it a Decision Tree to finding Knowing Adobe Photoshop: yes/no a Skills level of specialist and defining a specialist 1. 21

2. Knowing the most popular screens resolutions for all modern devices: yes/no 3. Experience of creating a mockups and graphics for cross-browse solutions (Desktop, mobile): yes/no

The relations between questions and verifying skills should be formed as table (Table 2) – the fuzzy relations, where:

Front-end developer

S – skills

1. High experience in HTML5, CSS3, Bootstrap: yes/no 2. Knowing PHP, JavaScript: yes/no 3. Knowing Adobe Photoshop: yes/no 4. Knowing MooTools, jQuery: yes/no 5. Experience in front-end coding as “pixel-perfect” standard, cross-browse coding: yes/no 6. Knowing English (reading documentation): yes/no

Zarządzanie

Q – questions that verify skill P

Q/S

PHP deve-

Base

HTML

JAVA

MySQL

lopment

solutions

front-end

development

developm

developing

development

on CMS

0,2

0,4

0,8

0,5

0,3

0,4

0,8

0,5

0,1

Table 2. Fuzzy relations table

Back-end developer

On next step using max-min fuzzy relations, according to provided data about experience and sub1. Work experience: number of years 2. Web-sources development using Drupal jective binary assessments let’s create an overall table with relations of Candidates and verifying CMS: yes/no 3. Web-sources development using any other skills (Table 3). CMS: yes/no PHP Base MySQL HTML JAVA 4. Good knowing PHP: yes/no development solutions front-end development develo 5. Experience in working with MySQL developing development Database: yes/no on CMS 6. Knowing of JavaScript: yes/no Kowalski 0,5 0,5 0,8 1 0, 7. Knowing English (reading docuNowak 1 0,5 0,6 0,6 0, mentation): yes/no

Assessment of competence based on fuzzy relationships

Wiśniewski

0,5

0,9

0,3

0,4

Dąbrowski

0,9

0,5

Table 3. General table – Fuzzy relations of verifying skills

For example, for candidate Kowalski the value 0,5 To provide an assessment of competence can(PHP development) defines in the further way: didates should pass a tests. The answers on test questions should be formed as table (fuzzy rela- C=[ tions). 0.5 0.5 0.8 1 0.5 The results of quiz of candidates provided in ta- 1 0.5 0.6 0.6 0.6 0.5 0.9 0.3 0.4 0.4 ble 1. 1 0.9 0.5 0.5 0.4 Q1

0,4

0,5

0,6

0,5

0,6

Wiśniewski

0,3

0,9

0,4

Dąbrowski

0,5

0,9

0,4

Kowalski Nowak

Table 1. results of quiz

]; F=cell(4,1); F={‚Kowalski‘ ‚Nowak‘ ‚Wiśniewski‘ ‚Dąbrowski‘}‘; t = classregtree(C,F,‘names‘,{‚PHP‘ ‚CMS‘ ‚HTML‘ ‚JAVA‘ ‚MySQL‘ },‘minparent‘,1);

PHP

Base

HTML

JAVA

development

solutions

front-end

development development

developing

development

MySQL

Conclusion

This method allows you to give recommendations to Kowalski 0,5 0,5 0,8 1 0,5 Management of recruitment, Nowak 1 0,5 0,6 0,6 0,5 which of the candidates will Wiśniewski 0,5 0,9 0,3 0,4 0,4 not immediately go to the vaDąbrowski 1 0,9 0,5 0,5 0,4 cant position, and which ones Table 5. Source data to building a decision tree will do, but have the compement Decision tree for regression tence to be increased. Increasing the input data for this algorithm will improve the quality of re1. if HTML<0.4 then node 2 elseif HTML>=0.4 commendations. then node 3 else Kowalski 2. class = Wiśniewski 3. if PHP<0.75 then node 4 elseif PHP>=0.75 Links and sources: then node 5 else Kowalski 1. https://en.wikipedia.org/wiki/Decision_tree 4. class = Kowalski 2. https://en.wikipedia.org/wiki/Bayesian_proba5. if CMS<0.7 then node 6 elseif CMS>=0.7 bility then node 7 else Nowak 3. https://en.wikipedia.org/wiki/Agile_software_ 6. class = Nowak development 7. class = Dąbrowski 4. https://en.wikipedia.org/wiki/Scrum_(software_ development) The constructed Decision tree has the form: 5. https://en.wikipedia.org/wiki/Waterfall_model L 6. Agile Project Management with Scrum (Microopment soft Professional), 2004 by Ken Schwaber ISBN:073561993x 7. Royce, Winston (1970), „Managing the Development of Large Software Systems“ ,5 8. 5th Ed 2013, Project Management Body of ,5 Knowledge PMBOK Guide ,4 9. Matlab User’s Guide, Chapter 9, Statistical ,4 Pattern Recognition, 2002 by Chapman &Hall/ CRC Figure 1. The Decision Tree 10. Aleksandra Mreła, Oleksandr Sokołov. APPLICATION OF TYPE 2 FUZZY RELATIONS TO ESAs a result of the analysis of the decision tree, is TABLISH LEVELS OF LEARNING OUTCOMES’ determined that in order to implement tasks only ACQUIREMENT BY STUDENTS. Cywilizacja techon CMS Drupal, we should hire Dąbrowski can- niczna. Społeczeństwo technologiczne XXI wieku . didate, but if we need to implement any other Kujawsko-Pomorska Szkoła Wyższa w Bydgoszczy, front-end tasks without CMS, we should hire No- 2016. Str. 77-94 wak candidate. on CMS

Oleksii Sokolov, I am a project manager and a software system engineer, former manager of web-development company, former manager of space-oriented company. Currently working in COMARCH TECHNOLOGIES in Field Service Management Business Unit. I have a master degree in Project Management and Social Informatics. Interested in quality management, project management, time management and project standards any types of delivery projects. My main Research Areas are: business-processes development, Project management approaches, Using mathematics in Project management. 23

chcesz układać puzzle w

inżynierii wymagań

razem z nami

Facebook

http://www.facebook.com/reqmagazyn

SIW - Stowarzyszenie Inżynierii Wymagań

Reklama

kontakt@reqmagazyn.pl

Współpraca

Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: kontakt@reqmagazyn.pl