t e s t o w a n i e j e s t ł a t w e

Transkrypt

1 testerzy.pl Podstawą tego tekstu jest Foundation Level Syllabus wydany przez ISTQB. Zarządzanie Zarządzanie testami Organizacja testów Niezależność organizacyjna testów Efektywność w znajdowaniu defektów może zostać poprawiona dzięki niezależnej grupie testowej. Wyróżniamy następujące typy niezależności: - niezależny tester wewnątrz grup programistów - niezależna grupa testowa lub po prostu grupa wewnątrz organizacji, raportująca do kierownika projektu lub zarządu - niezależność testera od organizacji biznesowej, społeczności użytkowników czy działu IT - specjalista testów niezależny od testerów takich jak testerzy użyteczności, bezpieczeństwa czy certyfikacji (certyfikujący produkt zgodnie ze standardami i regulacjami) - niezależny tester spoza organizacji. Dla potrzeb skomplikowanych i rozbudowanych projektów najlepsze jest stosowanie testowania na każdym poziomie przez niezależną grupę testową. Programiści mogą uczestniczyć w procesie testowym, szczególnie na niskich poziomach, ale ich brak obiektywności często skutkuje ich niską skutecznością. Niezależny tester może mieć umiejętności wymagane i zdefiniowane w procesie testowym, ale nade wszystko koniecznie powinien on mieć mandat do wykonania wszystkich zadań związanych z przypisanymi mu obowiązkami nadany mu przez kierownictwo. Korzyści płynące z niezależności to: - postrzeganie różnych defektów w sposób bezstronny - weryfikacja założeń wprowadzanych przez ludzi zajmujących się specyfikacją i implementacją systemu. Istnieją również negatywne aspekty: - izolacja od programistów (w przypadku pełnej niezależności) - niezależny tester może być zwężeniem a przez to opóźniać projekt jako jego ostatni punkt kontrolny - programiści przestają przejmować się jakością wiedząc, że ktoś i tak ich sprawdzi (ewentualnie zaproponuje poprawki). Zadanie testowe są wykonywane przez ludzi o określonych rolach, ale mogą one być również wykonywane przez ludzi na innych stanowiskach jak np. kierownik projektu, kierownik jakości, programista, ekspert biznesowy lub pracownicy IT. Zadania lidera i testera Zadanie i obowiązki ludzi na tych dwóch kluczowych stanowiskach zależą od projektu i sytuacji wokół produktu. Zależą również od ludzi na konkretnych stanowiskach i struktury samej organizacji.

2 Czasami liderzy testowi nazywani są kierownikami testów lub koordynatorami testów. Zadania lidera mogą być wykonywane przez kierownika projektu, kierownika programistycznego, kierownika ds. zapewnienia jakości lub kierownika grupy testowej. W dużych projektach zazwyczaj rozróżniamy dwa stanowiska: lider i kierownik testów. Lider zazwyczaj planuje, monitoruje i kontroluje czynności testowe. Zadania lidera grupy testowej: - planowanie i koordynacja strategii wraz z kierownikiem projektu i innymi udziałowcami - pisanie i przegląd strategii testów dla projektów oraz polityki testowej dla organizacji - stosowanie perspektywy testów dla innych aktywności testowych takich jak planowanie integracji - planowanie testów - rozważanie kontekstu i rozumienie ryzyka - włączając w to wybór metod testowych, szacowanie czasu, wysiłku i kosztów testowania; zdobywanie zasobów, definiowanie poziomów testowych, cykli, metodologii i celów oraz planowanie zarządzania przypadkami - inicjowanie, specyfikacja, przygotowanie, implementacja i wykonanie testów oraz późniejsze ich monitorowanie i kontrola - korekty planowania oparte na wcześniejszych planach w odniesieniu do postępu testów (czasami udokumentowanych w statusie) oraz podjęcie niezbędnych czynności dla kompensacji problemów - dla ułatwienia śledzenia wersji ustanowienie adekwatnego zarządzania konfiguracją dla narzędzi testowych - decydowanie, co powinno być zautomatyzowane, do jakiego stopnia oraz jak powinno to być przeprowadzone - zaproponowanie dopasowanych miar dla pomiarów postępu testowego oraz szacowania jakości testowania oraz jakości produktu - decydowanie o implementacji środowiska testowego - rozpisanie na osi czasu testów - pisanie raportów podsumowujących testy, opartych na informacjach zebranych podczas testowania. Typowe zadania testera: - przegląd i własny wkład w plany testów - analiza, przegląd i ocena wymagań użytkowników, specyfikacji i modeli pod kątem testowalności - tworzenie specyfikacji testowej - ustanowienie środowiska testowego (często koordynacja z administratorem systemu i sieci) - przygotowanie i zdefiniowanie danych testowych - implementowanie testów na wszystkich poziomach testowych, wykonanie i zapisywanie wyników testów, ocena wyników i dokumentacja różnic w stosunku do oczekiwanego rezultatu - użycie narzędzi administrowania, zarządzania i monitorowania testów - automatyzacja testów (wspierana programistami lub ekspertami od automatyzacji testów) - pomiar wydajności komponentów systemu (gdy wymagane) - przegląd i sprawdzenie testów napisanych przez innych. Ludzie pracujący nad analizą, projektowaniem i automatyzacją testów mogą być specjalistami w tych zadaniach. W zależności od poziomu testowego oraz ryzyka powiązanego z produktem i projektem, różni ludzie mogą przyjmować zadania testerów, zachowując ciągle niezależność. Typowo testerzy na poziomie komponentu lub integracji będą programistami, testerzy na poziomie testów akceptacyjnych będą ekspertami biznesowymi i użytkownikami, a testerzy operacyjnych testów akceptacyjnych będą po prostu operatorami. Planowanie i estymacja testów Planowanie testów Ta część podejmuje się zdefiniować cel planowania testów wewnątrz projektu tworzenia oprogramowania, implementacji i potrzeb serwisowych. Planowanie może być udokumentowane w projektowym lub głównym planie testów lub oddzielnym planie testów stworzonym specjalnie dla poszczególnych poziomów testowych, takich jak testowanie systemu i testowanie akceptacyjne. Dokładne wskazówki jak planować testy można znaleźć w "Standard for Software Test Documentation" (IEEE 829).

3 Na planowanie wpływa polityka testów organizacji, zakres testowanie, cele, ryzyko, ramy, ważność, testowalność i dostępność zasobów. Czym bardziej planowanie projektu i testów jest zaawansowane tym więcej informacji jest dostępnych i więcej szczegółów może zostać dołączonych do planów. Planowanie testów jest ciągłą czynnością wykonywaną w ciągu trwania cyklu życia projektu. Informacja zwrotna z czynności testowych jest użyta do rozpoznania ryzyka tak by planowanie mogło być dopasowane do rzeczywistych warunków. Czynności związane z planowaniem testów obejmują: - zdefiniowanie ogólnej metody testowej (strategia testów), włączając w to definiowanie poziomów testowych oraz kryteriów rozpoczęcia i zakończenia testów - integracja i koordynacja czynności testowych w ramach cyklu tworzenia oprogramowania: zakupu, dostarczenia, rozwoju, operacji i serwisu - dokonywanie decyzji o tym, co należy testować, kto ma wykonywać każdą z czynności testowych, kiedy i jak czynności testowe powinny być wykonane, jak wyniki testów będą analizowane i kiedy przerwać testowanie (kryterium wyjścia) - przypisanie zasobów dla różnych, zdefiniowanych zadań - definiowanie ilości, poziomu dokładności, struktury i wzorców dokumentacji testowej - wybór miar dla monitorowania i kontrolowania przygotowania testów, rozwiązywania problemu defektów oraz oceny ryzyka - ustanawianie poziomu dokładności dla procedur testowych w celu dostarczenia wystarczającej informacji do wsparcia reprodukowanych czynności przygotowania i wykonania testów Kryterium zakończenie testów Celem definiowania kryterium zakończenia testów jest określenie, kiedy przerwać testowanie, na różnych poziomach lub kiedy zestaw testów zostanie wyczerpany. Kryterium wyjścia zawiera: - dokładne metryki takie jak pokrycie kodu, funkcjonalności lub ryzyka - kalkulacja ilości defektów w stosunku do tych, możliwych do wystąpienia lub miary niezawodności - koszty - pozostałe ryzyko, takiej jak pozostawione defekty, niepełne pokrycie testów w określonym obszarze - rozpiska planów w czasie, takich jak data dostarczenia produktu na rynek. Ocena testów Dwie metody oceny wysiłku testowego: - ocena wysiłku testowego oparta na metrykach poprzedniego lub podobnego projektu lub oparte na znanych, typowych wartościach - ocena zadań dokonana przez właściciela tych zadań lub przez eksperta. Kiedy wysiłek zostanie już oceniony, zasoby mogą zostać określone oraz można przygotować plan działań. Wysiłek testowy zależy od różnych czynników takich jak: - parametry produktu: jakość specyfikacji i innych informacji użytych dla modeli testowych, rozmiar produktu, złożoność obszaru problemu, wymagań niezawodności i bezpieczeństwa, wymagań względem dokumentacji - parametry procesu rozwoju oprogramowania: stabilność organizacji, użyte narzędzia, procesy testowe, umiejętności ludzi zaangażowanych w projekt oraz presja czasu - wynik testowania: ilość znalezionych defektów i ilość wymaganych poprawek Strategie testów Jedna z metod klasyfikacji strategii testów jest oparte na okresie czasu, w którym największe nawał pracy w projektowaniu testów się rozpoczyna: - metoda prewencji, gdzie testy projektowane są jak najwcześniej - metoda reaktywna, gdzie testy projektowane są po wyprodukowaniu oprogramowania lub systemu. Do typowych metod lub strategii zaliczamy:

4 - analityczne metody oparte na ryzyku testowym gdzie testowanie jest ukierunkowane na obszary najbardziej narażone na ryzyko wystąpienia błędów - metody oparte na modelu takie jak testowanie stochastyczne z użyciem informacji statystycznych o kalkulacji problemów występujących po wystąpieniu defektów - metodologiczne takie jak oparte na konsekwencjach błędów (włączając w to zgadywanie błędów), oparte na punktach kontrolnych, oparte na jakości parametrów - metody zgodne z procesami i standardami, takie jak te opisane przez standardy przemysłowe lub różne metodologie Agile - metody dynamiczne, takie jak wyczerpujące testowanie gdzie testowanie jest bardziej konsekwencją zdarzeń poprzednio zaplanowanych i gdzie wykonywanie i ocenianie są równoległymi zadaniami - metody konsultatywne, kierowane wcześniejszą radą, przy pomocy przewodnika technologicznego i/lub obszarem biznesowych ekspertyz wykonanych poza zespołem testowym - metody regresywne takie jak ponowne użycie materiałów testowych, automatyzacji testów regresji oraz standardów testowych. Różne metody mogą być ze sobą łączone np. dynamiczne metody oparte na ryzyku. Wybór strategii powinien być poprzedzony rozważaniem kontekstu: - ryzyka wystąpienia konsekwencji błędów w projekcie, niebezpieczeństwo dla produktu i ryzyko narażenia bezpieczeństwa użytkownika, środowiska lub firmy - umiejętności i doświadczenie ludzi w zaproponowanych technikach, narzędziach i metodach - cele zdolności testowania i misja zespołu testowego - aspekty regulujące takie jak wewnętrzne i zewnętrzne regulacje dla procesu tworzenia oprogramowania - natura produktu i biznesu.

5 Monitorowanie i kontrola postępów w testowaniu Monitorowanie postępu testów Celem monitorowania testowania jest otrzymywanie informacji i zdobywanie jasności o czynnościach testowych. Efekt monitorowania może być zbierany ręcznie lub automatycznie i może być użyty dla pomiaru kryterium zakończenie testów takich jak pokrycie. Miary mogą być użyte do oceny postępu w odniesieniu do tego, co zostało zaplanowane i zabudżetowane. Najczęściej metryki testowe zawierają: - procent wykonanej pracy w przygotowaniu przypadków testowych (lub procent zaplanowanych przypadków testowych już przygotowanych) - procent pracy wykonanej do przygotowania środowiska testowego - wykonanie przypadków testowych (np. liczba wykonanych/niewykonanych przypadków testowych i ilość przypadków testowych, które "przeszły"/"nie przeszły") - informacje o defektach (np. ilość defektów, ilość defektów znalezionych i naprawionych, ocena konsekwencji błędów, wyniki retestów) - pokrycia wymagań, ryzyka lub kodu - daty kamieni milowych testowania - koszty testowania, włączając w to koszty porównane z korzyściami płynącymi ze znajdowania następnych defektów lub przeprowadzania następnych testów. Raportowanie Raportowanie testowe jest postrzegane jako zbieranie informacji o wysiłku w testowaniu: - co stało się podczas testowania, np. daty, kiedy kryterium zakończenia testów zostanie osiągnięte - przeanalizowanie informacji i metryk do wsparcia rekomendacji i decyzji o przyszłych działaniach takich jak ocena pozostałych defektów, ekonomiczne korzyści z kontynuacji testów, pozostałe ryzyko i poziom niezawodności testowanego oprogramowania. Metryki powinny być zbierane podczas i na koniec każdego poziomu testowego dla oceny: - poziomu jakości w odniesieniu do celów założonych dla danego poziomy testowego - efektywności testowania w odniesieniu do celów - adekwatności obranej metody testowej. Kontrola Kontrola opisuje wszystkie działania korygujące i naprowadzające powzięte jako rezultat informacji i metryk zebranych i zaraportowanych. Czynności mogą pokrywać czynności testowe i mogą wpływać na inne czynności w cyklu tworzenia oprogramowania. Przykłady kontroli testów: - zmiana priorytetów testów w przypadku, gdy pojawi się ryzyko - zmiana planu testów zgodnie z dostępnością środowiska testowego - zestaw kryteriów jakości wymagających naprawy, które muszą zostać przetestowane przez programistę, zanim zostaną zaakceptowane do integracji.

6 Zarządzanie konfiguracją Celem zarządzania konfiguracją jest ustanowienie i serwisowanie integralności produktów (komponentów, danych i dokumentacji) programistycznych lub systemów w czasie trwania projektu i cyklu tworzenia oprogramowania. Dla testowania, zarządzanie konfiguracją obejmuje zapewnienie, że: - wszystkie elementy środowiska narzędziowego testów zostały zidentyfikowane, ich wersje podlegają kontroli, zmiany są śledzone w całym czasie trwania procesu - wszystkie zidentyfikowane dokumenty i elementy oprogramowanie znajdują odniesienie (w sposób bezsprzeczny) w dokumentacji testowej. Zarządzanie konfiguracją pomaga testerowi zidentyfikować (i zreprodukować) testowane elementy, dokumenty testowe, testy i narzędzia wspierające testowanie. Podczas planowania, procedury i infrastruktury (narzędzi) zarządzania konfiguracją powinno być wybrane, udokumentowane i zaimplementowane.

7 Ryzyko Ryzyko można definiować jako przypadek, niebezpieczeństwo, możliwość lub sytuację występującą w projekcie z niepożądanymi konsekwencjami - potencjalny problem. Poziom ryzyka będzie określony prawdopodobieństwem wystąpienia zdarzenia i jego wypływem (możliwości uszkodzeń). Ryzyko w projekcie Ryzyko projektowe jest ryzykiem otaczającym zdolność projektu do dostarczenia określonych dla niego celów. Wyróżniamy: - czynniki dostawcy: - niemożność dostarczenia produktu/podzespołu przez zewnętrzną grupę - czynniki kontraktowe - czynniki organizacyjne: - brak umiejętności i ludzi - czynniki osobiste i treningi - czynniki polityczne takie jak problem z komunikacją, niemożność uczenia się na własnych błędach - niepoprawny odbiór lub oczekiwania względem testowania (np. brak doceniania wartości błędów znalezionych podczas testowania) - czynniki techniczne - problem ze zdefiniowaniem właściwych wymagań - zakres wymagań, który może zostać osiągnięty dla istniejących ram - jakość projektów, kodu i testów. Kiedy kierownik testów analizuje, zarządza i przeciwdziała ryzyku, wypełnia założenia zarządzania projektem. Norma IEEE 829 wymusza zawarcie w test planie informacji o potencjalnym ryzyku i jego konsekwencjach. Ryzyko produktu Potencjalne obszary występowania awarii (powodujące przyszłe niebezpieczeństwa) w oprogramowaniu lub systemie nazywane są ryzykiem produktu, gdyż są ryzykiem w odniesieniu do jakości produktu. Wyróżniamy następujące ryzyko produktu: - oprogramowanie dostarczone na rynek zawierające defekty powodujące awarie - potencjalne zagrożenia zranienia osoby lub wprowadzenie niebezpieczeństwa uszkodzeń wewnątrz organizacji - słabe parametry oprogramowania (np. funkcjonalność, bezpieczeństwo, niezawodność, użyteczność i wydajność) - oprogramowanie, które nie zachowuje się tak jak powinno (nie spełnia swoich założeń). Pojęcia ryzyka używa się dla zdecydowania gdzie zacząć testowanie i gdzie przetestować bardziej dogłębnie; testowanie jest używane do zredukowania ryzyka występowania niepożądanych efektów lub do zredukowania wpływu tych efektów. Ryzyko produktu jest specjalnym typem ryzyka do wsparcia sukcesy projektu. Testowanie jako kontrola ryzyka dostarcza informacji zwrotnej o pozostałym ryzyku poprzez miarę efektywności usuwania krytycznych błędów i planom ich zapobiegania. Metoda testowa oparta na ryzyku zawiera szanse (użyte od najwcześniejszych etapów projektu) przeciwdziałania błędom zanim się pojawią, a przez to zredukowania poziomu ryzyka. Zawiera ona identyfikację ryzyka produktu i zawarcie informacji o nim w planowaniu testów, specyfikacji i podczas przygotowania i wykonywania testów. Ryzyko to możemy użyć by określić: - używane techniki testowe - zakres testów - ważność poszczególnych testów w celu znalezieniu najbardziej krytycznych błędów we wczesnej fazie - czy czynności pozatestowe mogące zostać zaprzęgnięte by zredukować ryzyko (np. dostarczenie treningów dla niedoświadczonych architektów).

8 Testowanie oparte na ryzyku podsumowuje zebraną wiedzą i pokazuje udziałowcom ryzyko i poziom potrzebny do jego wyeliminowania. Dla zapewnienia, że szanse na awarie produktu są minimalne, czynności zarządzania ryzykiem dostarczają wsparcia w postaci: - oceny (regularnie powtarzanej), co może pójść źle (ryzyko) - określenia, z jakim ryzykiem i o jakiej ważności będziemy mieli do czynienia - wprowadzenia akcji do przeciwdziałania ryzyka. Dodatkowo, testowanie może wspierać identyfikację nowego ryzyka, może pomagać określić ryzyko, jakie można zredukować oraz może obniżyć niepewność w występowaniu ryzyka.

9 Zarządzanie przypadkami Jednym z celów testowania jest znajdywanie defektów, różnica między aktualnym i oczekiwanym wynikiem muszą zostać zakwalifikowane jako przypadki. Przypadek powinien być śledzony od momentu jego odkrycia aż po przedstawienie dla niego rozwiązania. W celu zarządzania przypadkami organizacja powinna ustanowić proces i zasady klasyfikacji przypadków. Przypadek może zostać dostrzeżony podczas czynności programistycznych, przeglądów, testowania lub użycia oprogramowania. Może być odniesiony do kodu lub do systemu, ale również do dokumentacji programistycznej, dokumentów testowych lub informacji dla użytkownika jak np. "Pomoc". Cele raportów o przypadkach: - dostarczyć programistom i innym uczestnikom informację zwrotną o problemach, aby wspomóc identyfikacją, izolacją i korekcją, gdy jest to konieczne - dostarczyć liderom testów narzędzi do śledzenia jakości systemu będącego testowanym i postępu w testowaniu - dostarczać pomysły dla poprawy procesu testowego. Tester lub osoba dokonująca przeglądu zazwyczaj zapisują następujące informacje o przypadkach: - data wykrycia, część organizacji gdzie został znaleziony przypadek, autor, potwierdzenie i status - zakres, negatywne konsekwencje i priorytet przypadku - referencje, zawierające, jaki przypadek testowy pozwolił wykryć problem. Szczegóły raportu o przypadku zawiera: - oczekiwany i aktualny rezultat - data, kiedy przypadek został wykryty - identyfikacja i konfiguracja oprogramowania lub systemu - cykl życia oprogramowania, w którym przypadek został zaobserwowany - opis anomalia dla wsparcia znalezienia rozwiązania - poziom wpływu na zainteresowanych udziałowców - negatywny wpływ na system - pilność/priorytet naprawy - status przypadku (np. otwarty, duplikat, czeka na naprawę, naprawiony - oczekujący na potwierdzenie, zamknięty) - konkluzje i rekomendacje - czynniki zewnętrzne, jak inne obszary mogące być zainfekowane zmianą wprowadzoną dla naprawy przypadku - historia zmian, jako sekwencja działań podjętych, przez członków zespołu projektowego, dla wyizolowania i naprawienia przypadku.

10 Modele tworzenia oprogramowania Testowanie nie jest czynnością wykonywaną w izolacji, jest powiązane z tworzeniem oprogramowania. Różne cykle tworzenia oprogramowania wymagają różnych metod testowych. Wodospad Model wodospadu w pełni oddaje pierwsze projekty informatyczne. Jest to prosta próba przedstawienia czynności w projekcie, gdzie dwie najważniejsze fazy: projektowanie i weryfikacja, następują po sobie. W uproszczeniu najpierw tworzony jest system lub oprogramowanie a dopiero potem następują testy. Model V Różne modele V testowe zostały opisane, ale można wyróżnić cztery poziomy testowe, powiązane z czterema poziomami rozwoju oprogramowania. Te poziomy to: - testy komponentów - testy integracji - testy systemu - testy potwierdzające. Czytaj więcej w artykule na stronie Model iteratywny Rozwój oprogramowania oparty na metodach iteratywnych jest procesem ustalania wymagań, projektowania, budowania i testowania systemu, wykonane przez podzielenie całego procesu na jego mniejsze elementy. Wyróżniamy dwa główne nurty: inkrementacji, czyli wzrostu poprzez dodawania małych cząstek oraz ewolucyjny, czyli stopniowy. Przykłady: procesy prototypowe, szybki rozwój aplikacji (ang. RAD), zunifikowany process firmy Rational (RUP), model Agile. Efekt iteracji może być testowany na różnych poziomach rozwoju oprogramowania. Elementy dodane do procesu wcześniej, tworzą cały system, który również musi zostać przetestowany. Szczególnie ważne jest testowanie regresyjne po każdej iteracji. Weryfikacja i walidacja może również być włączona w każdą inkrementacją. Testowanie w modelu cyklu życia W modelu cyklu życia, możemy wyróżnić parametry dobrego testowania: - dla każdej czynności programistycznej możemy wyróżnić odpowiadającą jej czynność testową - każdy poziom testowy ma cele specyficzne dla niego - analiza i projekt testów dla konkretnego poziomu powinien rozpoczynać się wraz z odpowiadającym mu poziomem programistycznym - tester powinien być zaangażowany w przegląd dokumentów od momentu pojawienia się ich pierwszych szkiców. Poziomy testowe mogą być łączone i reorganizowane w zależności od natury projektu lub architektury systemu. Przykładowo: integracja komercyjnego oprogramowania prosto z półki sklepowej z systemem, klient kupujący taki produkt sam wykonuje testy integracji w systemie (np. integracja z infrastrukturą i innymi systemami) i testy akceptacyjne (funkcjonalne i niefunkcjonalne)

11 Metodologie Agile - czyli metoda ułatwionego ruchu, bardziej dotyczy deweloperów, którym coraz bliżej do testerów XP - ekstremalne programowanie Test Driven Developmnet - czyli rozwój oprogramowania kierowany poprzez testy jest niesamowitym połączeniem testowania i programowania. Jest to zupełnie nowe podejście do tematu projektowania i zarządzania, który przestaje wreszcie tworzyć sztuczne granice między testerami i programistami. Drużyny tworzone w projektach łączą jednych i drugich w celu osiągnięcia właściwej jakość oprogramowania na czas. Ekspert tej techniki Jack Gansleyy powiedział/napisał: "Testowania i integracja nie są już osobnymi kamieniami milowymi projektu". TTD łączy w sobie dwie techniki testowania: - jednostki (unit) - testy białej skrzynki pisane i wykonywane przez programistów - akceptacji - testy czarnoskrzynkowe dla każdej części produktu tworzone przez ludzi związanych z zapewnieniem mu jak najwyższej jakości. Podstawowe hasło tej metody to: Testy na początku! Cykl testowania zintegrowany z programowaniem jest dość prosty: 1) Dodaj test 2) Wykonaj test i obserwuj przypadki negatywne 3) Dokonaj zmian 4) Wykonaj testy i obserwuj przypadki pozytywne 5) Przeanalizuj duplikaty i usuń RUP - zunifikowany proces firmy Rational RAD - szybki rozwój aplikacji Prototyping testowanie prototypów