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

Slides:



Advertisements
Podobne prezentacje
Złożoność procesu konstrukcji oprogramowania wymusza podział na etapy.
Advertisements

Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
Role w zespole projektowym
1 / 47 WARSZAWA 2005 Przemysław Siekierko Stanisław Andraszek Rational Unified Process.
Referat 3. Planowanie zadań i metody ich obrazowania
Rational Unified Process www-306.ibm.com/software/rational/
Zarządzanie konfiguracją Doskonalenie Procesów Programowych Wykład 6 Copyright, 2001 © Jerzy.
Cykle życia oprogramowania
Administracja zintegrowanych systemów zarządzania
Rational Unified Process
Projektowanie i programowanie obiektowe II - Wykład IV
GENERATOR WNIOSKÓW I STUDIUM WYKONALNOŚCI WYBRANE INFORMACJE Wrocław, 22 listopada 2005 r. WOJCIECH WICZKOWSKI Dział Wdrażania Europejskiego Funduszu Rozwoju.
Proces tworzenia oprogramowania
Dalsze elementy metodologii projektowania. Naszym celem jest...
Wykład 2 Cykl życia systemu informacyjnego
Projekt i implementacja aplikacji wspomagającej testowanie
Projekt i implementacja aplikacji wspomagającej testowanie oprogramowania, zgodne z metodologią Unified Software Development Process (RUP). Włodzimierz.
SZPIF – Harmonogram, Opis narzędzi, Schemat bazy danych
Projekt i implementacja aplikacji wspomagającej testowanie
C.d. wstępu do tematyki RUP
Instytut Tele- i Radiotechniczny WARSZAWA
Continuous Integration
Największe problemy w projektach informatycznych IT Opracował: Karol Pietrzak na podstawie artykułu z SDJ/2007 IX.
Człowiek – najlepsza inwestycja Program Operacyjny Kapitał Ludzki PROBLEMY PROGRAMOWANIA, WDRAŻANIA I PROJEKTOWANIA W RAMACH EUROPEJSKIEGO FUNDUSZU SPOŁECZNEGO.
Maszyna wirtualna ang. virtual machine, VM.
Implementacja systemu
POŚREDNIK Jak reprezentowana jest informacja w komputerze? liczby – komputer został wymyślony jako zaawansowane urządzenie służące do wykonywania.
Dr Karolina Muszyńska Na podst.:
Program Operacyjny Kapitał Ludzki
Unified Modeling Language - Zunifikowany Język Modelowania
Proces tworzenia oprogramowania
Program Operacyjny KAPITAŁ LUDZKI Priorytet IV Szkolnictwo Wyższe i Nauka Dział Rozwoju Kadry Naukowej Narodowe Centrum Badań i Rozwoju.
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Service Oriented Architecture
C++.
Upowszechnianie produktu projektu MJUP. Ramowy harmonogram 2011 Zadanie 5 - Zarządzanie projektem Zadanie 4 - Upowszechnianie produktu Zadanie 3 - Opracowanie.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Waterfall model.
Metodologia CASE. Przyczyny użycia narzędzi CASE Główną przesłanką użycia narzędzi CASE jest zwiększenie produktywności i jakości produkowanych systemów.
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Podstawy zarządzania projektami Karta projektu
Michał Sipek Piotr Kapciak
Systemy kontroli wersji
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
ZINTEGROWANE SYSTEMY ZARZĄDZANIA
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Podstawy programowania
Logical Framework Approach Metoda Macierzy Logicznej
Struktura systemu operacyjnego
Model warstwowy ISO-OSI
Dokumentacja programu komputerowego i etapy tworzenia programów.
1 © copyright by Piotr Bigosiński DOKUMENTACJA SYSTEMU HACCP. USTANOWIENIE, PROWADZENIE I UTRZYMANIE DOKUMENTACJI. Piotr Bigosiński 1 czerwiec 2004 r.
Temat: Porównanie technologii php,c# oraz javascript na przykładzie webaplikacji typu społecznościowy agregator treści Autor: Wojciech Ślawski.
E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ.
E. Stemposz. Rational Unified Process, Wykład 11, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 11 Typowe.
T ESTY JEDNOSTKOWE W C# Alicja Majka, A GENDA Wprowadzenie do środowiska Czym są testy jednostkowe i po co je stosować? XUnit, NUnit Pokrycie.
E. Stemposz. Rational Unified Process, Wykład 2, Slajd 1 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 2 Krótka charakterystyka RUP.
Wykład 2 – Zintegrowane systemy informatyczne Michał Wilbrandt.
MAS Rafał Hryniów. Agenda  Zasady  Referaty  Projekt  Kolosy.
Testy jednostkowe. „Test jednostkowy (unit test) to fragment kodu, który sprawdza inny fragment kodu”
InMoST Wielkopolska sieć współpracy w zakresie innowacyjnych metod wytwarzania oprogramowania Termin realizacji: – Innowacyjne metody.
Programowanie strukturalne i obiektowe Klasa I. Podstawowe pojęcia dotyczące programowania 1. Problem 2. Algorytm 3. Komputer 4. Program komputerowy 5.
Cykle życia oprogramowania oraz role w zespole projektowym Autor: Sebastian Szałachowski s4104.
„Metodologia Zarządzania Cyklem Projektu (PCM) — klucz do sukcesu
Zarządzanie projektami informatycznymi
Inżynieria Oprogramowania Laboratorium
Cykl życia oprogramowania
JavaBeans by Paweł Wąsala
Zapis prezentacji:

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

Elementy RUP

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.

Koncepcje implementacji Build Odwzorowanie projektu na kod

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.

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.

Przegląd działań

Przegląd artefaktów

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

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.

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.

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.

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.

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.

Szczegółowy przepływ pracy

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.

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.

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.

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.

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.