WYDZIAŁ ZARZĄDZANIA Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie

Transkrypt

1 WYDZIAŁ ZARZĄDZANIA Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Studia Podyplomowe ZARZĄDZANIE PROJEKTAMI KWALIFIKACJE PROJECT MANAGERA edycja 2013/2014 Praca podyplomowa ZARZĄDZANIE JAKOŚCIĄ W PROJEKTACH WYTWARZANIA OPROGRAMOWANIA NA PRZYKŁADZIE PROGRAMOWANIA EKSTREMALNEGO Autor: Robert Pająk Kraków, Czerwiec 2014

2 SPIS TREŚCI WSTĘP... 3 JAKOŚĆ W PROJEKTACH WYTWARZANIA OPROGRAMOWANIA... 5 Definicja jakości... 5 Jakość oprogramowania... 5 Składowe jakości... 6 ZARZĄDZANIE JAKOŚCIĄ... 9 Planowanie jakości Usprawnianie procesów Pomiary i miary jakości Zapewnianie jakości Kontrola jakości Weryfikacja i zatwierdzanie Testowanie Przeglądy PROGRAMOWANIE EKSTREMALNE JAKO METODYKA SKONCENTROWANA NA JAKOŚCI Wartości Zasady Praktyki Zarządzanie jakością Planowanie jakości Zapewnienie jakości Kontrola jakości Doskonalenie jakości PODSUMOWANIE BIBLIOGRAFIA

3 WSTĘP Jakość oprogramowania to wieloaspektowe zagadnienie. W rzeczywistości spojrzenie na jakość z kilku perspektyw jednocześnie jest kluczowe do zrozumienia i wytworzenia wartościowego produktu oraz zaspokojenia jawnych i ukrytych potrzeb klienta. Często można usłyszeć, że zagadnienia związane z jakością w świecie oprogramowania są inne niż w przypadku innych produktów, jednak nie jest to do końca prawdą. Ogólnie mówiąc zasady, systemy i metodyki jakościowe stosowane w produkcji są równie prawidłowe w przypadku oprogramowania i innych dóbr czy usług. Jednak oprogramowanie charakteryzuje się specyficznym środowiskiem projektowania i rozwoju. W celu efektywnego zarządzania jakością oprogramowania, należy poznać typowe wyzwania wynikające z abstrakcyjnej natury systemów cyfrowych oraz poziomu złożoności wielu aplikacji. Ponadto należy wziąć pod uwagę innowacyjność i trudność zadań, do których rozwiązania zostały zaprojektowane. W projektach wytwarzania oprogramowania problemy z jakością występują niemal zawsze. Najczęściej wynikają one z pewnych braków poznawczych potrzeb klienta. Wymagania związane z oprogramowaniem ulegają bardzo częstym zmianom. Jako odpowiedź na ten problem zaczęto stosować podejście adaptacyjne, które wyewoluowało do tzw. metodyk zwinnych. Jedną z pierwszych jest programowanie ekstremalne, które do dnia dzisiejszego cieszy się uznaniem wśród inżynierów oprogramowania. Ta metodyka w szczególny sposób kładzie nacisk na tworzenie oprogramowania wysokiej jakości w warunkach wysokiego ryzyka i częstych zmian. Celem niniejszej pracy jest przedstawienie problematyki związanej z jakością oprogramowania. Oprócz opisu podstawowych sposobów zarządzania jakością w projektach wytwarzania oprogramowania przedstawiona została metodyka programowania ekstremalnego, która podchodzi do jakości w bardzo kompleksowy sposób. Unikatowym elementem pracy jest analiza zarządzania jakością wprowadzanego przez metodykę. W pierwszym rozdziale przedstawione zostały najważniejsze informacje związane z jakością w projektach wytwarzania oprogramowania. W szczególności został przedstawiony model jakości oprogramowania według normy ISO/IEC 9126 oraz wymienione parametry jakości zgodnie z normą ISO/IEC

4 Kolejny rozdział omawia tematykę zarządzania jakością w projektach, ze szczególnym uwzględnieniem projektów wytwarzania oprogramowania. Treść powstała na podstawie najbardziej wpływowej literatury związanej z tą tematyką (m.in. ISO 9000, Software Engineering autorstwa Iana Sommervilla) oraz najpopularniejszych metodyk zarządzania projektami PMBOK oraz PRINCE2. Ostatni rozdział przestawia zwięźle metodykę programowania ekstremalnego. Ponadto obrazuje jak wygląda zarządzanie jakością w projektach rozwijanych zgodnie z tą metodyką. Kolejnym planowanym etapem rozwoju omawianej problematyki jest analiza problemów związanych z programowaniem ekstremalnym. W szczególności próba wyjaśnienia powodów, dla których programowanie ekstremalne nie jest szeroko stosowane. 4

5 ROZDZIAŁ I JAKOŚĆ W PROJEKTACH WYTWARZANIA OPROGRAMOWANIA 1. Definicja jakości Jakość jest pojęciem względnym, które w zależności od kontekstu, kultury, środowiska może być różnie rozumiane. Przeważanie kryje się pod nim wszystko co ma związek z pewnymi cechami produktu lub usługi, mającymi wpływ na jego postrzeganie przez klienta. Termin jakości już od starożytności był definiowany na wiele sposobów. Najbardziej znaną starożytną definicją jest zaproponowana przez Platona jako "pewien stopień doskonałości". Współcześnie możemy spotkać wiele pojęć jakości, które się wzajemnie uzupełniają. W słownikach języka polskiego można znaleźć następujące definicje jakości: "wartość czegoś" (Słownik języka polskiego PWN, 2006); "zespół cech decydujących o ocenie danego wyrobu" (Uniwersalny słownik języka polskiego, 2007). Obecna norma ISO definiuje jakość jako "stopień, w jakim zbiór inherentnych cech spełnia wymagania" (ISO 9000:2005). Współcześnie w biznesie jakość definiuje się głównie jako spełnienie lub przekroczenie oczekiwań, wymagań oraz potrzeb klienta (Governica, Jakość). 2. Jakość oprogramowania Jakość oprogramowania, podobnie jak jakość dowolnego produktu, to wieloaspektowe zagadnienie. Stworzenie oprogramowania wysokiej jakości wymaga spojrzenia na jakość z kilku perspektyw (ISO/IEC :2000) (rys. 1). Jakość procesu (ang. process quality) - obejmuje cechy związane z procesem wytwarzania oprogramowania. Jakość wewnętrzna (ang. internal quality; alt. jakość strukturalna: ang. structural quality) - obejmuje cechy oprogramowania, które są widoczne przez wykonawców, ale nie przez użytkownika. 5

6 Jakość zewnętrzną (ang. external quality; alt. jakość funkcjonalna: ang. functional quality) - obejmuje cechy związane z działającym oprogramowaniem. Jakość użytkowania (ang. quality in use) - obejmuje cechy określające stopień spełnienia potrzeb użytkownika. Rysunek 1. Model jakości w procesie wytwarzania oprogramowania Oprogramowanie Efekty stosowania oprogramowania Jakość procesu Jakość wewnętrzna Jakość zewnętrzna Jakość użytkowania Metryki procesowe Metryki wewnętrzne Metryki zewnętrzne Metryki jakości użytkownika Źródło: Sacha, 2010, s.306 Zgodnie z przedstawionym modelem jakość danej perspektywy wpływa na jakość pozostałych perspektyw znajdujących się na rysunku po jej prawej stronie. Wymagania dotyczące jakości oprogramowania zwykle uwzględniają kryteria oceny jego jakości wewnętrznej, zewnętrznej oraz użytkowania, aby zaspokoić potrzeby programistów, klientów oraz użytkowników końcowych. Z przedstawionego modelu wynika, że sama zgodność oprogramowania ze specyfikacją wymagań, która zawiera się w perspektywie zewnętrznej nie jest wystarczająca, aby oprogramowanie było wysokiej jakości. 3. Składowe jakości Norma ISO/IEC 25010:2011 wyróżnia oddzielnie charakterystyki jakości oprogramowania (wewnętrzna i zewnętrzna) oraz charakterystyki jakości użytkowej oprogramowania. Model jakości użytkowania składa się z pięciu charakterystyk, które odnoszą się do wyniku interakcji, gdy system jest używany w określonym kontekście użycia. 6

7 Skuteczność (ang. effectiveness) - dokładność i kompletność, z którym użytkownicy osiągają określone cele. Efektywność (ang. efficiency) - zasoby wydatkowane w relacji do dokładności i kompletności, z którym użytkownicy osiągają celów. Satysfakcja (ang. satisfaction) - stopień, w jakim potrzeby użytkownika są spełnione, gdy system jest używany w określonym kontekście użycia. Wolność od zagrożeń (ang. freedom from risk) - stopień, w jakim system ogranicza zagrożenia. Pokrycie kontekstu (ang. context coverage) - stopień, w jakim system może być skutecznie i efektywnie używany z wolnością od zagrożeń i satysfakcją w określonych kontekstach użycia. Aby móc uzyskać wysoką jakość użytkowania koniecznie jest poznanie potrzeb klienta, które mają zostać zaspokojone przez oprogramowanie. Model jakości oprogramowania składa się z ośmiu charakterystyk odnoszących się do właściwości statycznych (strukturalnych) oraz dynamicznych (funkcjonalnych) oprogramowania: Przydatność funkcjonalna (ang. functional suitability) - stopień, w jakim oprogramowanie oferuje funkcje, które spełniają określone wymagania, kiedy jest stosowany w określonych warunkach. Niezawodność (ang. reliability) - stopień, w jakim system wykonuje konkretne funkcje w określonych warunkach, w zadanym okresie czasu. Skalowalność (ang. performance efficiency) - wydajność w stosunku do ilości zasobów wykorzystywanych w określonych warunkach. Operacyjność (ang. operability) - stopień, w jakim system może być skutecznie i efektywnie używany z satysfakcją w określonym kontekście użycia. Zabezpieczenie (ang. security) - stopień, w jakim system chroni informacje i dane, tak aby osoby lub inne produkty lub systemy miały odpowiedni dla nich stopień dostępu i poziom autoryzacji. Kompatybilność (ang. compatibility) - stopień, w jakim system może wymieniać informacje z systemami oraz wykonywać wymagane funkcje w obrębie tego samego sprzętu lub środowiska oprogramowania. 7

8 Łatwość utrzymania (ang. maintainability) - stopień skuteczności i efektywności, z jaką system może być modyfikowany. Przenośność (ang. portability) - stopień skuteczności i efektywności, z jaką system może być przenoszony z jednego sprzętu, oprogramowania lub środowiska operacyjnego bądź użytkowania na inny. Zdaniem Consortium of IT Software Quality najważniejszymi charakterystykami oprogramowania wymaganymi do dostarczania wartości biznesowej są niezawodność, skalowalność, zabezpieczenie oraz łatwość utrzymania (CISQ TR ). Istotną cechą jakości oprogramowania jest relacja pomiędzy jakością wewnętrzną a zewnętrzną. Otóż w oprogramowaniu często istnieje możliwość takiej zmiany, która zwiększa jakość zewnętrzną jednocześnie pogarszając wewnętrzną. Jednak takie podejście jest bardzo ryzykowne i kosztowne, ponieważ powstaje tzw. dług technologiczny (ang. technical dept). Jakość wewnętrzna ma wpływ na jakość zewnętrzną i ostatecznie powoduje, że dalsze modyfikowanie oprogramowania jest coraz bardziej utrudnione (McConnell, 2004) (Fowler, Tradable Quality Hypothesis). Często charakterystyki mają obszary wspólne oraz są wzajemnie powiązane. Z tego powodu usprawnienia określonej charakterystyki mogą wpływać, zarówno negatywnie jak i pozytywnie, na pozostałe (McConnell, 2004). 8

9 ROZDZIAŁ II ZARZĄDZANIA JAKOŚCIĄ Norma ISO 9000:2005 definiuje zarządzanie jakością jako "skoordynowane działania dotyczące kierowania organizacją i jej nadzorowania w odniesieniu do jakości". Należy zaznaczyć, iż termin "organizacji" znajdujący się w normie dotyczy również projektów. Przyjęte założenie jest zgodne z definicją projektu zawartą w ramach metodyki PRINCE2 - "Projekt to organizacja czasowa powołana w celu dostarczenia jednego lub więcej produktów biznesowych według uzgodnionego Uzasadnienia Biznesowego". Obecna norma dzieli również zarządzanie jakością na cztery części: planowanie jakości (ang. quality planning), zapewnienie jakości (ang. quality planning), kontrola jakości (ang. quality control), doskonalenie jakości (ang. quality assurance). Podział ten jest zgodny z cyklem PDCA (Plan-Do-Check-Act, alt. koło Deminga) (Moen, Norman, Evolution of the PDCA cycle). W przypadku zarządzania projektami (również wytwarzania oprogramowania) zwykle nie wyróżnia się oddzielnie części doskonalenia jakości jako oddzielnego procesu (rys. 2). Wskazują one, że zarządzanie jakością powinno się skupiać na ciągłym doskonaleniu, w którym każda część powinna być zaangażowana w doskonalenie jakości. W szczególności podczas planowania jakości planuje się usprawnienia procesów (PMI, 2013) (OGC, 2009) (Sommerville, 2010). Rysunek 2. Typowa struktura procesów zarządzania jakością projektu Zarządzanie jakością Planowanie jakości Zapewnianie jakości Kontrola jakości Źródło: Opracowanie własne 9

10 1. Planowanie jakości Proces planowania jakości skupia się na ustaleniu celów jakościowych (m.in. wymagań) oraz określaniu procesów operacyjnych, technik i związanych z nimi zasobów niezbędnych do ich spełnienia (ISO 9000:2005). Powinno się również zaplanować, w jaki sposób projekt będzie wykazywał zgodność z celami jakościowymi. W ramach planowania jakości można wyróżnić takie czynności jak: określanie i uprawnianie procesów, dobór technik i narzędzi, ustalanie metryk, formułowanie standardów, tworzenie list kontrolnych, definiowanie przeglądów i aktualizowanie dokumentacji projektowej (PMI, 2013). Podczas planowania powinno się uwzględniać wszystkie perspektywy jakości związane z wytwarzaniem oprogramowania Usprawnianie procesów Bardzo wiele korzyści przynosi wykorzystywanie istniejących praktyk. Popularnymi uniwersalnymi praktykami, które znajdują również szerokie zastosowanie w projektach wytwarzania oprogramowania są: Total Quality Management (TQM) (Ishikawa, 1988) (Feigenbaum, 1991), Lean, Kaizen, 5S, Kanban (Gilpatrick, Furlong, 2006) (Poppendieck, 2003), P7 (ang. 7QC - Seven Basic Tools of Quality), poka-yoke, 7 ZP ang. (7M - Seven Management and Planning Tools), Quality Function Deployment (QFD) (Ishikawa, 1988) (Jayaswal, Patton, 2006). Ponadto istnieją jeszcze metodyki, które są charakterystyczne dla projektów wytwarzania oprogramowania. Obecnie największym uznaniem cieszą się metodyki oraz praktyki zwinne (ang. Agile) takie jak: programowanie ekstremalne (szerzej omówione w rozdziale 3), Scrum, Acceptance Test-Driven Development, Continuous Integration, Domain-Driven Design, SOLID, Timeboxing (Manifesto for Agile Software Development) (Fowler, The New Methodology) (Martin, 2006). Do doskonalenia można również stosować modele dojrzałości (ang. maturity models) jako narzędzie do oceny procesów. Najpopularniejszym modelem dojrzałości stosowanym przy wytwarzaniu oprogramowania jest Capability Maturity Model Integration (CMMI) (West, 2004). ISO/IEC jest standardem, który również definiuje model dojrzałości 10

11 SPICE (Software Process Improvement and Capability Determination), jednak obecnie cieszy się on mniejszą popularnością. Bardzo ważnym aspektem jest właściwa integracja procesów. Szczególnie pożądane jest, aby procesy występujące w projekcie wzajemnie się uzupełniały oraz jednocześnie, aby nie dochodziło pomiędzy nimi do konfliktów (Kerzner, 2004). W roku 2010 Forrester Research opublikowało raport opisujący siedem praktyk doskonalących jakość tworzonego oprogramowania (Visitacion, Gualtieri, 2010): zdefiniuj jakość do twoich potrzeb, rozgłaszaj proste metryki jakości, dostrajaj indywidualne/zespołowe cele, aby wprowadzały jakość, pozyskuj prawidłowe wymagania, testuj sprytniej, aby testować mniej, projektuj oprogramowanie, aby zmniejszyć ryzyko błędów, optymalizuj wykorzystanie narzędzi do testowania Pomiary i metryki jakości Pomiary, jako jeden z elementów monitowania, stanowią bardzo ważne narzędzie zarządzania. McConnell twierdzi nawet, że "negowanie korzyści z pomiarów to twierdzenie, że lepiej nie wiedzieć co się dzieje w projekcie" (McConnell, 2004). Dla każdego atrybutu projektu można znaleźć metrykę oraz metodę jej pomiaru (Glib, 2005). Znane jest twierdzenie: "Co zostaje zmierzone zostanie zrobione" (ang. What gets measured gets done), na podstawie którego rozwinęło się podejście zarządzania przez cele. Jednak pomiary mają również negatywne skutki, ponieważ koncentracja na tym co jest mierzone prowadzi często do pogorszenia jakości innych aspektów projektu. Nie oznacza to jednak, aby nie stosować metryk, ale żeby ich dobór był bardzo staranny i nieustannie optymalizowany (Deming, 2000) (Kua, An Appropriate Use of Metrics). W procesie doboru metryk bardzo dobrą opinią cieszy się wykorzystywanie metody GQM (Goal, Question, Metric). W projektach wytwarzania oprogramowania metryki jakości użytkowania i metryki zewnętrzne są bardziej przydatne niż metryki wewnętrzne i procesowe (Sacha, 2010) (rys. 1). 11

12 2. Zapewnianie jakości Według większości źródeł zapewnienie jakości (zwane również "nadzorem jakości") polega na audytowaniu jakości ustawionych procesów. Zapewnienie jakości jest ściśle związane z ciągłym doskonaleniem procesów i jest ukierunkowane na zapewnieniu zaufania, że wymagania dotyczące jakości będą spełnione (PMI, 2013) (OGC, 2009) (ISO 9000:2005) (Sommerville, 2010) (Cunningham & Cunningham, Quality Assurance). Zapewnienie jakości jest pojęciem wieloznacznym oraz posiadających wiele definicji. Z tego powodu jest ono obecnie bardzo różnie rozumiane w środowisku wytwarzania oprogramowania. W przemyśle oprogramowania bardzo często w ramach zapewniania jakości klasyfikuje się również weryfikację oraz zatwierdzanie (kontrolę jakości), ponieważ termin kontroli jakości nie jest popularny (Sommerville, 2010) (Cunningham & Cunningham, Quality Assurance Is Not Quality Control). Z tego powodu można wyróżnić różne implementacje roli odpowiedzialnej za zapewnianie jakości: niezależna od zespołu rola w organizacji, który służy audytowaniu procesów występujących w projekcie oraz ustanawiająca określone procedury i standardy, rola w zespole, która jest odpowiedzialna za jakość procesową, rola w zespole odpowiedzialna za testowanie oraz monitorowanie jakości oprogramowania. 3. Kontrola jakości Również termin kontrolowania jakości cechuje różnorodność interpretacji (Hamrol, Mantura, 2002). W literaturze polskiej termin anglojęzyczny quality control tłumaczy się na kontrolę jakości oraz sterowanie jakością. Korzystając z tych dwóch terminów można wyróżnić następujące definicje: sterowanie jakością - zbiór czynności ukierunkowany na spełnienie wymagań dotyczących jakości (ISO 9000:2005) (OGC, 2009), kontrola jakości - zbiór czynności weryfikujących i zatwierdzających wymagania dotyczące jakości (PMI, 2013) (Cunningham & Cunningham, Quality Control). Głównym zadaniem kontroli jakości jest wykrywanie wszelkich niezgodności, które występują w każdym etapie i każdym rodzaju prac. Defekty wykrywane w późniejszych etapach charakteryzują się większym kosztem ich usuwania. Ponadto z danych 12

13 empirycznych wynika, że usuwanie defektów jest najbardziej kosztowną i czasochłonną czynnością w projektach wytwarzania oprogramowania. Dlatego dobrą praktyką jest planowanie kontroli jakości na samym początku prac oraz jak najczęstsze weryfikowanie oraz zatwierdzanie (McConnell, 2004). Bardzo ważnym elementem zarządzania jakością jest analiza rezultatów powstałych w wyniku kontroli jakości (PMI, 2013) Weryfikacja i zatwierdzanie Jak wspominano w podrozdziale 2. termin kontroli jakości nie jest popularny w przemyśle oprogramowania w przeciwieństwie do weryfikacji (ang. verification) oraz zatwierdzenia (ang. validation), z których składa się kontrola jakości. Weryfikacja jest to proces sprawdzania czy oprogramowanie jest zgodne z wymaganiami. Zatwierdzanie służy sprawdzaniu czy oprogramowanie oraz wymagania spełniają potrzeby i oczekiwania klienta. Podstawowymi metodami weryfikacji oraz zatwierdzania są testowanie (ang. testing) oraz przeglądy (ang. reviews) (Sommerville, 2010). Rysunek 3. Weryfikacja oraz zatwierdzanie w modelu jakości oprogramowania Potrzeby użytkownika Zatwierdzanie Jakość użytkowania Specyfikacja (wymagania jakości zewnętrznej) Weryfikacja i zatwierdzanie Jakość zewnętrzna Wymagania jakości wewnętrznej Weryfikacja Jakość wewnętrzna Źródło: Opracowanie własne 13

14 3.2. Testowanie Testowanie jest metodą sprawdzania jakości oprogramowania poprzez jego próbne wykonanie. Głównym celem testowania jest wykrywanie defektów. W procesie testowania oprogramowania można wyróżnić cztery poziomy testów: testy jednostkowe (ang. unit testing) - testowanie indywidualnych jednostek oprogramowania, testy integracyjne (ang. integration testing) - testowanie pewnego zbioru współdziałających jednostek, testy systemowe (ang. system testing) - testowanie całości oprogramowania, testy akceptacyjne (ang. acceptance testing) - sprawdzanie zgodności z wymaganiami oraz oczekiwaniami klienta. Model V (rys. 4) przedstawia zależności pomiędzy poszczególnymi fazami wytwarzania oprogramowania a związanymi z nimi poziomami testowania. Praktyka wykazuje, iż bardzo dobre efekty daje opracowywanie testów już w momencie rozważania określonych aspektów oprogramowania, ponieważ sprzyja to ich lepszemu zrozumieniu oraz daje możliwość natychmiastowej weryfikacji (Sacha, 2010). Rysunek 4. Model V procesu testowania oprogramowania Specyfikacja wymagań opracowanie testów Testy akceptacyjne Specyfikacja systemu Testy systemowe Architektura systemu Testy integracyjne Implementacja Testy jednoskowe Źródło: Opracowanie własne Metody testowania najczęściej dzieli się na następujące kategorie: testy strukturalne (biało-skrzynkowe) - opracowywane na podstawie znajomości wewnętrznej struktury oprogramowania głównie w celu znalezienia błędów związanych z implementacją, 14

15 testy niestrukturalne (czarno-skrzynkowe) - opracowane bez analizy struktury oprogramowania m.in. w celu znalezienia niezgodności z wymaganiami jakościowymi, testy użytkownika (ang. user tests, live tests) - testowanie oprogramowania dokonywane przy pomocy użytkowników oprogramowania (testy alfa, beta, akceptacyjne użytkownika) (Black, 2009). Oprócz wymienionych rodzajów występuje jeszcze bardzo wiele typów testów, z których warto wymienić: funkcjonalne, wydajnościowe, dymne, regresyjne, eksploracyjne, bezpieczeństwa, użyteczności, kompatybilności, współbieżności. Skuteczne testowanie w dużej mierze zależy od odpowiedniego dobranego procesu testowania. Przykładowy cykl testowania może składać się z następujących faz: planowanie testów - opracowanie planu testowania na podstawie wymagań oraz projektu oprogramowania, projektowanie testów - konfigurowanie środowiska testowego i tworzenie testów, wykonanie testów - uruchamianie testów, zapis statusów testów, raportowanie wyników, retesty defektów - wykonywanie testów, które zakończyły się niepowodzeniem, po wprowadzeniu korekt, testowanie regresyjne - wykonanie testów, które były wykonane bezbłędnie przed rozpoczęciem usuwania defektów. Podczas testowania bardzo pomocne jest wykorzystywanie narzędzi, spośród których można wyróżnić narzędzia do zarządzania testami, wykonywania testów, wstrzykiwania błędów, testowania wydajności oraz symulatory, emulatory, a nawet języki skryptowe (Black, 2009). W procesie testowania oprogramowania bardzo istotną rolę pełnią testy automatyczne. Automatyzowanie testów jest najpraktyczniejszym sposobem na zwiększenie efektywności testów regresyjnych. Jedynie właściwe wykorzystanie testów automatycznych umożliwia utrzymanie stałego czasu testowania przy rosnącej funkcjonalności i złożoności oprogramowania (McConnell, 2004). Popularną w ostatnich czasach praktyką jest stosowanie testów automatycznych jako wykonywalną specyfikację oprogramowania, dzięki czemu unikamy problemów związanych z aktualizowaniem dokumentacji 15

16 projektowej (Adzic, 2011). Dzięki temu, że testy automatyczne mogą być uruchamiana w dowolnym momencie w celu sprawdzenia poprawności oprogramowania, są one jednym z najbardziej istotnych elementów ciągłej integracji, ponieważ zwiększają szanse na szybkie wykrycie błędów podczas wprowadzania zmian w oprogramowaniu (Fowler, Continuous Integration) Przeglądy Przeglądy są aktywnościami mającymi na celu ocenę jakości stanu prac (np. testowania) lub produktów wykonywanych (np. specyfikacji wymagań, projektu architektury, kodu programu) w procesie wytwarzania oprogramowania. W czasie przeglądu grupa ludzi sprawdza podmiot poddawany przeglądowi szukając potencjalnych problemów i niezgodności z przyjętymi standardami. Przykładowymi sposobami dokonywania przeglądów są: oględziny (nieformalne przeglądy), inspekcje (formalne przeglądy), audyty zewnętrzne, praca zespołowa (np. programowanie w parach) (Sacha, 2010) (McConnell, 2004). Wiele badań potwierdza, że inspekcje są znacznie tańsze niż testowanie. Pozwalają na szybsze wykrywanie defektów, dzięki czemu nie tylko koszt znalezienia, ale również ich usuwania jest znacznie niższy (McConnell, 2004). 16

17 ROZDZIAŁ III PROGRAMOWANIE EKSTREMALNE JAKO METODYKA SKONCENTROWANA NA JAKOŚCI Programowanie ekstremalne (ang. Extreme Programming, akr. XP) (Beck, Andres, 2004) jest metodyką zwinną autorstwa Kenta Becka powstałą w latach dziewięćdziesiątych podczas prac nad projektem Chrysler Comprehensive Compensation System (akr. C3). Metoda powstała w odpowiedzi na projekty, w których wymagania często ulegają zmianom oraz charakteryzują się wysokim ryzykiem. Głównym jej celem jest zwiększenie jakości wytwarzanego oprogramowania oraz szybkości reakcji na zmiany wymagań klienta. Programowanie ekstremalne jest metodyką adaptacyjną, która próbuje obniżyć koszty zmiany wymagań poprzez stosowanie tygodniowych iteracji, w których oprogramowanie jest rozwijane w sposób inkrementalny. Zmiany są elementem naturalnym, nieuniknionym, a nawet pożądanym i powinny być na bieżąco planowane, zamiast posiadania odgórnie zdefiniowanego, stabilnego zestawu wymagań. Programowanie ekstremalne jest oparte na wartościach, zasadach i praktykach doprowadzonych do ekstremalnych poziomów. 1. Wartości Fundamentem programowania ekstremalnego jest pięć wartości, które według jej autora są niezwykle istotne, aby projekt wytwarzania oprogramowania zakończył się sukcesem, czyli spełniał wymagania jakościowe klienta. Komunikacja (ang. communication) - większość problemów i błędów jest spowodowanych brakiem komunikacji. Jej najskuteczniejszą formą jest komunikacja bezpośrednia, interpersonalna. Artefakty projektowe muszą być aktualne oraz czytelne. Prostota (ang. simplicity) - "Zrób najprostszą rzecz, która może działać". Jednak tworzenie prostego oprogramowania wymaga doświadczenia, pomysłu i ciężkiej pracy. Prostota sprzyja komunikacji, zmniejsza złożoność oraz poprawia jakość. Dzięki prostocie implementacja nowej funkcjonalności jest prostsza. Ponadto jednym z założeń jest brak przedwczesnego planowania. 17

18 Informacje zwrotne (ang. feedback) - z powodu częstych zmian konieczne jest posiadanie efektywnych środków informujących o statusie projektu. Podstawowymi narzędziami zwrotnymi są bliski kontakt z klientem i dostępności zestawu zautomatyzowanych testów, które zostały opracowane razem z oprogramowaniem. Sprzężenie zwrotne jest ściśle związane z komunikacją. Należy się komunikować, aby uzyskać informacje zwrotne oraz należy posiadać wyniki informacji zwrotnej, aby kontynuować dalszą komunikację. Dzięki informacjom zwrotnym łatwiej jest otrzymać prostotę, która często jest uzyskiwana za pomocą metody prób i błędów. Ponadto, im prostszy system, tym łatwiej jest uzyskać informacje na jego temat. Odwaga (ang. courage) - wszystkie metodyki i procesy są narzędziami służącymi zmniejszaniu naszych obaw. Komunikacja, prostota i informacje zwrotne pozwalają na bezpieczne dokonywanie nawet dużych zmian wymagań i znacznej refaktoryzacji (zmiana wewnętrznej struktury oprogramowania, zwiększającą przejrzystość oprogramowania jednocześnie nie wpływając na jego obserwowalne zachowanie). Odwaga bez pozostałych wartości jest niebezpieczna. Jednak dzięki pozostałym wartościom jest potężnym narzędziem do dokonywania zmian. Szacunek (ang. respect) - członkowie zespołu muszą dbać o siebie i swoją pracę. Należy mieć szacunek do pracy, organizacji i osób, których dotyczy rozwijane oprogramowanie. Programowanie ekstremalne nie będzie funkcjonowało bez szacunku. 2. Zasady Wymienione wartości nie dają konkretnych porad na temat zarządzania projektem oraz tworzenia oprogramowania. W tym celu potrzebne są praktyki, które oparte są na ściśle określonych zasadach. Człowieczeństwo (ang. humanity) - czynniki ludzkie mają bardzo duży wypływ na rozwijane oprogramowanie i są głównym kluczem do dostarczania oprogramowania wysokiej jakości. Twórca metodyki zwraca szczególną uwagę, aby zadbać o poczucie bezpieczeństwa, możliwość realizacji i zaspokajać potrzebę przynależności, rozwoju oraz intymności. Ekonomia (ang. economics) - głównym celem oprogramowania jest przynoszenie korzyści biznesowych. Programowanie ekstremalne wyróżnia dwa aspekty ekonomiczne: wartość 18

19 pieniądza w czasie oraz wartość opcji systemów i zespołów. Pierwszy mówi, że im szybciej dostarczy się oprogramowanie, tym szybciej zacznie przynosić korzyści. Ponadto dzięki przyrostowemu wytwarzaniu oprogramowania koszty projektowe są odraczane do ostatniego możliwego momentu. Innym źródłem wartości ekonomicznej w rozwoju oprogramowania jest jego wartość jako opcje na przyszłość, uzyskanej dzięki łatwości wprowadzania zmian. Wzajemna korzyść (ang. mutual benefit) - każda działalność powinna dawać korzyść wszystkim powiązanym osobom i organizacjom. Zawsze istnieją łatwe rozwiązania, przez które jedni zyskują a inni tracą. Jednak ostatecznie są one czystą stratą, ponieważ zaburzają relacje i pogarszają środowisko pracy. Z tego powodu trzeba stosować praktyki, z których korzysta zarówno zespół jak i klient Samo-podobieństwo (ang. self-similarity) - natura nieustannie wykorzystuje struktury fraktalne, które są do siebie podobne w różnych skalach. Ta sama zasada sprawdza się podczas tworzenia oprogramowania. Wielokrotne wykorzystanie podobnych rozwiązań, w różnych kontekstach, porządkuje projekt. Doskonalenie (ang. improvement) - ciągłe doskonalenie jest kluczowym aspektem programowania ekstremalnego. Należy nie tylko codziennie starać się działać jak najlepiej, ale również trzeba myśleć o tym, co zrobić, aby lepiej pracować następnego dnia. Doskonalenie ma na celu eliminowanie długów technologicznych oraz procesowych. Różnorodność (ang. diversity) - zespoły, w których każdy jest podobny nie są skuteczne. Zespół powinien obejmować różne dziedziny wiedzy, umiejętności i osobowości, aby móc rozpoznawać i rozwiązywać problemy Posiadanie różnych opinii i propozycji wielu rozwiązań jest bardzo przydatne w rozwoju oprogramowania, pod warunkiem skutecznego zarządzania konfliktami oraz umiejętności wyboru właściwych decyzji. Refleksja (ang. reflection) - skuteczny zespół nie tylko wykonuje swoją pracę, ale również zastanawia się w jaki sposób działa i dlaczego. Istotna jest analiza sukcesów i porażek. Podczas każdej iteracji należy znaleźć czas na refleksje na temat stanu projektu i możliwych udoskonaleń. Przepływ (ang. flow) - programowanie ekstremalne jest ukierunkowane w kierunku ciągłego przepływu wartościowego oprogramowania, poprzez wykonywanie razem wszystkich aktywności rozwojowych, a nie posiadania dyskretnych faz. Ciągły przepływ 19

20 umożliwia informację zwrotną w celu zapewnienia, że system ewoluuje we właściwym kierunku oraz pozwala uniknąć problemów związanych z tzw. integracją wielkiego wybuchu (ang. Big Bang). Możliwości (ang. opportunity) - problemy należy postrzegać jako szansę na poprawę. Problemy występują zawsze. Dlatego nie należy ich jedynie rozwiązywać, ale także wykorzystać do nauki oraz doskonalenia. Redundancja (ang. redundancy) - krytyczne i trudne problemy powinny być rozwiązywane na kilka różnych sposobów. Jeśli jedno rozwiązanie zawiedzie, inne mogą zapobiec awarii. W takich przypadkach koszt redundancji szybko się spłaca. Defektów oprogramowania należy szukać, znajdywać i naprawiać na wiele sposobów. Jednak nie należy wprowadzać praktyk, które nie wnoszą żadnych dodatkowych korzyści. Niepowodzenie (ang. failure) - jeśli nie wiesz jak dokonać zmiany - spróbuj i najwyżej zawiedź. Porażki mogą być bardzo pouczające. Zawsze lepiej jest próbować niż zbyt długo opóźniać konieczne działanie. Lepiej jest wcześniej ponosić koszty związane z ryzykiem. Jakość (ang. quality) - jakość musi być zawsze maksymalna. Przyjmując niższą jakość nie przynosi się ani oszczędności, ani szybszego rozwoju. Z kolei ulepszanie ogólnej jakości często wiąże się z poprawą innych cech projektu takich jak produktywność i efektywność. Jakość nie jest jedynie czynnikiem ekonomicznym. Członkowie zespołu muszą być dumni ze swojej pracy, ponieważ poprawia to ich poczucie własnej wartości oraz skuteczność. Nie można mylić jakości z perfekcjonizmem. Opóźnianie działań przez dążenie do doskonałości, nie promuje jakości. Raczej należy próbować i osiągać porażki, aby następnie udoskonalać istniejące rozwiązania. Dziecięce kroki (ang. baby steps) - duże zmiany, przygotowane w długim okresie czasu, które są ewaluowane w jednym momencie, są niebezpieczne. Lepiej jest stosować możliwie krótkie iteracje, które dokonują weryfikacji przyjętego kierunku i rozwiązania. Akceptowana odpowiedzialność (ang. accepted responsibility) - odpowiedzialność musi być przyjęta, a nie przypisana. Najczęściej wydawanie poleceń jest nieskuteczne, ponieważ niszczy kreatywność. 20