Rational Unified Process w testowaniu oprogramowania
Metodologia RUP (Rational Unified Process) wykorzystuje podejście obiektowe w swoim projekcie, a użycie notacji UML (Unified Modeling Language) jest zaprojektowane i udokumentowane w celu zilustrowania procesów w działaniu. Wykorzystuje ona komercyjnie sprawdzone techniki i praktyki.
Jest to proces uważany za ciężki i najlepiej nadający się do zastosowania w dużych zespołach programistów i dużych projektach, ale fakt, że jest on w dużym stopniu konfigurowalny, pozwala na dostosowanie go do projektów o dowolnej skali.
Szczegóły
Dla zarządzania projektami model RUP(Rational Unified Process) zapewnia zdyscyplinowane rozwiązanie, takie jak zadania i obowiązki nakreślone w ramach organizacji zajmującej się tworzeniem oprogramowania.
RUP (Rational Unified Process) jest sam w sobie produktem programistycznym. Jest modułowy i zautomatyzowany, a cała jego metodologia jest wspierana przez kilka narzędzi programistycznych zintegrowanych i sprzedawanych przez IBM poprzez jego „Rational Suites.”
Metody konkurencji w dziedzinie inżynierii oprogramowania obejmują „czyste pomieszczenia” (uważane za ciężkie) i zwinne (lekkie), takie jak Extreme Programming (XP-Extreme Programming), Scrum, FDD i inne.
Istnieją pewne wytyczne i szablony, które są zdefiniowane, dla pracowników cyklu produkcyjnego, przez RUP: część klienta i ocena postępu projektu przez jego kierownictwo. Pomaga to programistom pozostać skupionym na projekcie.
Wymagania dotyczące zarządzania
Właściwa dokumentacja jest niezbędna dla każdego projektu na dużą skalę; zauważ, że RUP opisuje, jak dokumentować funkcjonalność, ograniczenia systemu, ograniczenia projektowe i wymagania biznesowe.
Przypadki użycia i scenariusze są przykładami artefaktów procesu zależnego, które zostały uznane za znacznie bardziej skuteczne w przechwytywaniu wymagań funkcjonalnych.
Użycie architektury opartej na komponentach
Architektura oparta na komponentach tworzy system, który może być łatwo rozszerzalny, promując ponowne użycie i intuicyjne zrozumienie oprogramowania. Komponent zwykle odnosi się do obiektu w programowaniu obiektowym.
RUP zapewnia systematyczny sposób budowania tego typu systemu, koncentrując się na wytwarzaniu wykonywalnej architektury we wczesnych etapach projektu, czyli przed zaangażowaniem zasobów na dużą skalę.
Komponenty, o których tu mowa, są na ogół zawarte w infrastrukturach już istniejących w danym miejscu. Infrastruktury te obejmują CORBA, jak również Component Object Model (COM).
Użycie wizualnych modeli oprogramowania w modelu Rup
Przez abstrahowanie od programowania kodu i reprezentowanie go za pomocą graficznych bloków konstrukcyjnych, RUP może być skutecznym sposobem na uzyskanie przeglądu rozwiązania.
Używanie modeli wizualnych może również umożliwić osobom o mniej technicznym profilu (jako klienci) lepsze zrozumienie danego problemu, a tym samym większe zaangażowanie w projekt jako całość.
Język modelowania UML stał się standardem branżowym do reprezentowania projektów i jest szeroko stosowany przez RUP!
Know More: Przeczytaj o Ekskluzywne szczegóły testowania zwinnego
Sprawdzanie jakości oprogramowania
Nie zapewnia jakości oprogramowania jest najczęstszą porażką we wszystkich projektach systemów komputerowych. Zazwyczaj myśli się o jakości oprogramowania po zakończeniu projektów lub za jakość odpowiada inny zespół programistów.
Zarządzanie i kontrola zmian w oprogramowaniu
We wszystkich projektach oprogramowania istnienie zmian jest nieuniknione. RUP definiuje metody kontroli i monitorowania zmian. Ponieważ niewielka zmiana może wpłynąć na aplikacje w całkowicie nieprzewidywalny sposób, kontrola zmian jest niezbędna dla powodzenia projektu.
RUP (Rational Unified Process) definiuje również obszary pracy i bezpieczeństwa, co gwarantuje programiście, że zmiany w innym systemie nie wpłyną na jego system.
Fazy metodyki RUP
Jak dotąd wytyczne te są ogólne, należy się do nich stosować przez cały cykl życia projektu. Fazy (patrz rysunek poniżej) wskazują, na co kładzie się nacisk w projekcie w danym momencie. Aby uchwycić czasowy wymiar projektu, RUP dzieli projekt na cztery różne fazy:
Inicjacja lub Projektowanie: nacisk na zakres systemu;
Przygotowanie: nacisk na architekturę;
Budowa: nacisk na rozwój;
Przejście: nacisk na aplikację.
RUP opiera się również na 4 P:
- People
- Design
- Product
- Process
Warstwy składają się z iteracji. Iteracje są oknami czasu; iteracje zdefiniowały termin tak, jak fazy są obiektywne.
Wszystkie fazy generują artefakty. Będą one wykorzystywane w następnej fazie i udokumentować projekt i pozwala na lepsze follow-up.
Faza projektowania
Faza projektowania lub inicjacji zawiera przepływy pracy niezbędne do porozumienia zainteresowanych stron – interesariuszy – z celów, architektury i planowania projektu. Jeśli ci aktorzy mają dobrą wiedzę, analiza nie będzie konieczna. W przeciwnym razie, wymagana jest bardziej rozbudowana analiza.
Na tym etapie, zasadnicze wymagania systemu są przekształcane w przypadki użycia. Celem nie jest zamknięcie ich w ogóle, ale tylko tych, które są niezbędne do ukształtowania opinii.
Krok ten jest zazwyczaj krótki i służy do określenia, czy możliwe jest kontynuowanie projektu oraz zdefiniowania ryzyka i kosztów ostatniego. Można wykonać prototyp do zatwierdzenia przez klienta. Jak przytacza RUP, ideałem jest wykonywanie iteracji, które muszą być dobrze zdefiniowane pod względem ich ilości i celów.
Elaboration Phase
Przygotowanie będzie do projektowania systemu, jako uzupełnienie ankiety i/lub dokumentacji przypadków użycia, przed architekturą systemu, do przeglądu modelu biznesowego dla projektu i do rozpoczęcia wersji podręcznika użytkownika. Trzeba przyjąć do wiadomości: Opis produktu (zwiększenie + integracja) jest stabilny; Plan projektu jest wiarygodny? Koszty są kwalifikowane?
Faza budowy
W fazie budowy rozpoczyna się fizyczny rozwój oprogramowania, kody produkcyjne, testy alfa. Beta testy zostały przeprowadzone na początku fazy przejściowej.
Musisz zaakceptować testy, stabilne i procesy testowe, a kod systemu jest „bazowy”.
Faza przejściowa
W tej fazie jest dostawa („wdrożenie”) oprogramowania, która przeprowadza plan wdrożenia i dostawy, monitorowanie i jakość oprogramowania. Produkty (wydania, wersje) mają być dostarczone, a miejsce zadowolenia klienta. Na tym etapie odbywa się również szkolenie użytkowników.
Dyscypliny metodyki RUP (Rational Unified Process)
Dyscyplina modelowania biznesowego
Organizacje są coraz bardziej zależne od systemów informatycznych, dlatego konieczne jest, aby inżynierowie systemów informacyjnych wiedzieli, jak aplikacje są zintegrowane z rozwojem organizacji. Firmy inwestują w IT, które rozumieją przewagę konkurencyjną wynikającą z wartości dodanej przez technologię.
Celem modelowania biznesowego jest najpierw ustanowienie lepszego zrozumienia i komunikacji pomiędzy inżynierią biznesową a inżynierią oprogramowania.
Zrozumienie biznesu oznacza, że inżynierowie oprogramowania muszą zrozumieć strukturę i dynamikę firmy docelowej (klienta), obecne problemy, z którymi boryka się organizacja oraz potencjalne metody i strategie naprawcze.
Innym ważnym aspektem, który nie może być podważony jest to, że odpowiednie strony, takie jak deweloperzy, jak również klienci, a także użytkownicy końcowi muszą mieć jasne zrozumienie organizacji, a ważną cechą tego zrozumienia jest to, że musi być wspólny dla wszystkich zaangażowanych stron.
Modelowanie biznesowe wyjaśnia, jak opisać wizję organizacji, w której system będzie wdrażany i jak wykorzystać tę wizję jako podstawę do opisania procesów, funkcji i odpowiedzialności.
Wymagania kursowe
Kurs ten wyjaśnia, jak uzyskać żądania od zainteresowanych stron („zainteresowanych stron”) i przekształcić je w zestaw wymagań, aby produkty działały w ramach budowanego systemu oraz dostarczyć szczegółowe wymagania dotyczące tego, co jest niezbędne dla systemu.
Analiza i projektowanie dyscypliny („Projektowanie”)
Celem analizy i projektowania jest pokazanie, w jaki sposób system będzie realizowany. Celem jest zbudowanie systemu, który:
Wykonuje w określonym środowisku wykonawczym, zadania i funkcje określone w opisach przypadków użycia
Zaspokaja wszystkie potrzeby
Jest łatwy w utrzymaniu, gdy nie ma zmian w wymaganiach funkcjonalnych, wyniki projektu w modelu analizy i projektu opcjonalnie posiada model analizy.
Model projektu jest wykorzystywany jako koncepcyjna wersja kodu źródłowego, wyświetlając tylko niezbędne minimum. Pozwala to użytkownikowi dowolnej inspekcji ustalić styl, w jakim kod źródłowy został wyrenderowany.
Model projektowy jest renderowany w taki sposób, że zawiera różne podziały projektów. Podziały te są przechowywane w ramach określonych podsystemów.
Każdy podsystem ma odrębny interfejs, który jest precyzyjnie zaprojektowany. Zawiera również opisy, w jaki sposób obiekty w tych klasach współpracują w celu realizacji projektów przypadków użycia.
Dyscyplina Implementacja
Efektami aplikacji są:
- W odniesieniu do warstwowych podsystemów zorganizowanych dla aplikacji, kod organizacji jest skonfigurowany.
- Różne klasy lub podziały komponentów są realizowane. Komponenty te obejmują
- pliki źródłowe
- pliki wykonywalne i
- pliki binarne
- Komponenty opracowane jako jednostki są testowane
Włączenie wyników wytworzonych przez poszczególnych wykonawców (lub zespoły), w system wykonywalny. Systemy są osiągane poprzez komponenty aplikacji.
Proces ma na celu spełnienie ważnej funkcji, jaką jest określenie dokładnej procedury, która ma być wykorzystana, w celu ponownego wykorzystania komponentów, które albo już istnieją, albo zostały świeżo wprowadzone.
To pozwala na możliwość utrzymania systemu i znaczne zwiększenie szans na wykorzystanie komponentów.
Testowanie dyscypliny
Celami testowania dyscypliny są:
- Sprawdzenie interakcji między obiektami
- Sprawdzenie poprawności integracji wszystkich komponentów oprogramowania
- Sprawdzenie, czy wszystkie wymagania zostały wykonane poprawnie
- Zidentyfikowanie i zapewnienie, że defekty zostaną usunięte przed wdrożeniem oprogramowania
- Upewnienie się, że wszystkie defekty zostaną, przeglądane i zamykane
Wniosek
W przypadku, gdy w projekcie występują wady, ich korekta może pochłonąć niepotrzebne koszty z powodu tego, że wady nie zostaną ujawnione w odpowiednim czasie.
Jeśli projekt, jednak, jest testowany w całości, byłoby to korzystne, ponieważ wszelkie wady, które mogą być wkradł się do projektów mogą być zidentyfikowane i ustalone na najwcześniejszym.
To z kolei będzie mieć ogromne zmniejszenie kosztów związanych z usunięciem wad. To jest iteracyjne podejście proponowane przez Rational Unified Process.
Aby test przyniósł owoce i miał najlepsze możliwe wyniki, testy muszą być przeprowadzone na czterech parametrach jakości, a także muszą być ustalone standardy, które muszą być spełnione, aby projekt został uznany za przeszedł test.
.