Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52.

Prezentacja na temat: "Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52."— Zapis prezentacji:

1 Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52

2 Elementy RUP

3 Cele fazy implementacji Zdefiniowanie organizacji kodu uwzględniające podsystemy uporządkowane w warstwach. Zaimplementowanie elementów projektu (pliki źródłowe, binaria, pliki wykonywalne itp.). Przeprowadzenie testów pojedynczych komponentów. Integracja komponentów stworzonych przez poszczególnych twórców w jeden działający system.

4 Koncepcje implementacji Build Odwzorowanie projektu na kod

5 Build Jest to operacyjna wersja systemu lub też jego części, która obrazuje możliwości i funkcje produktu finalnego. Buildy są integralną częścią iteracyjnego cyklu tworzenia produktu, gdyż ukazuje kolejne etapy działań. Podczas całego procesu tworzenia oprogramowania powstają kolejne numerowane wersje buildów, które są archiwizowane. Umożliwia to w każdej chwili cofnięcie się do poprzedniej wersji w momencie zaistnienia takiej potrzeby.

6 Odwzorowanie projektu na kod Projekt systemu to podstawa do rozpoczęcia jego implementacji. Hierarchia projektów: –projekt ogólny, przedstawiający zarys systemu, –projekt zawierający opisy poszczególnych podsystemów, –projekt szczegółowo opisujący poszczególne komponenty podsystemów.

7 Przegląd działań

8 Przegląd artefaktów

9 Przepływ pracy Struktura implementowanego modelu Plan integracji Implementacja komponentów Integracja poszczególnych subsystemów Integracja całego systemu

10 Struktura implementowanego modelu W tym etapie model dzielony jest na komponenty (subsystemy), nad którymi można pracować niezależnie. Dobrze zorganizowany model zapobiega problemom konfiguracyjnym i pozwala na bezproblemowe scalenie komponentów w większe elementy systemu, a w końcu w system.

11 Szczegółowy przepływ pracy W tej fazie pracuje architekt oprogramowania, który przekształca model projektowy w strukturę implementacyjna, z czego powstaje dokument opisujący architekturę oprogramowania i model implementacyjny. Pracownik ten musi mieć doświadczenie w zarządzaniu budową oprogramowania, zarządzaniu konfiguracją, oraz znać język programowania, w którym tworzone są komponenty.

12 Plan integracji Ta faza skupia się na określaniu, który podsystem powinien być teraz implementowany oraz jakie komponenty powinny być zintegrowane w tej iteracji. Plan integracji powinien na bieżąco uwzględniać wszelkie zmiany w architekturze czy projekcie systemu.

13 Szczegółowy przepływ pracy Integracja jest zwykle wysoce zautomatyzowanym procesem, stąd też integrator powinien posiadać wiedzę na temat zarządzania budową oprogramowania, zarządzania konfiguracją oraz znać język programowania, w którym tworzone są komponenty. Dodatkowo wymagana jest znajomość poleceń shellowych, języków skryptowych oraz narzędzi typu make.

14 Implementacja komponentów W czasie implementacji poszczególnych elementów modelu programiści tworzą nowy kod źródłowy, a także adaptują już istniejący, kompilują, linkują i przeprowadzają testy jednostkowe. W przypadku wykrycia błędów czy nieprawidłowości, implementacja danego elementu wraca do punktu wyjścia. Przy poprawkach i zmianach ponownie przeprowadzane są testy jednostkowe w celu ich weryfikacji.

15 Szczegółowy przepływ pracy

16 Schemat pracy cd. Sama implementacja jest przeważnie wykonywana przez jedną osobę. Przeglądanie i sprawdzanie stworzonego kodu wymaga już większej wiedzy i nakładu pracy, stąd też do tego zadania przeznaczany jest większy zespół osób bardziej doświadczonych w tej dziedzinie. Faza ta zwykle przebiega w kilku sesjach, gdzie każda jest skupiona wokół niewielkiego wycinka systemu czy też na konkretnym zagadnieniu. Sprawdzanie kodu ma na celu znalezienie błędów i problemów, a nie ich natychmiastowe rozwiązanie. Częstsze przeglądanie małych fragmentów kodu przynosi lepsze efekty niż rzadsze sprawdzanie większych partii.

17 Integracja poszczególnych podsystemów W tej fazie poszczególne komponenty są integrowane w jeden podsystem. W rezultacie otrzymujemy build, który jest następnie testowany. Integracja jest procesem wykonywanym kilkakrotnie zanim otrzymamy gotowy i w pełni sprawny subsystem.

18 Szczegółowy przepływ pracy Integracja oraz jej testowanie jest przeprowadzane zwykle przez jedna osobę lub niewielki zespół. Jest to związane z faktem, iż proces ten jest automatyzowany i wymaga interwencji ludzkiej jedynie w przypadku niepowodzenia.

19 Integracja całego systemu Faza ma na celu integrację poszczególnych subsystemów w jeden system, który jest końcowym produktem procesu implementacji. Integracja może być przeprowadzana kilkakrotnie na różnych etapach zaawansowania prac implementacyjnych. Tworzone są w ten sposób kolejne buildy, które są poddawane odpowiednim testom.

20 Szczegółowy przepływ pracy Podobnie jak w fazie integracji podsystemów, pracę tą wykonuje jedna osoba lub mały zespół (w zależności od wielkości projektu). Jest to wysoce zautomatyzowany proces wymagający dozoru i interwencji w przypadku błędów.