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.

Slides:



Advertisements
Podobne prezentacje
Projektowanie w cyklu życia oprogramowania
Advertisements

Złożoność procesu konstrukcji oprogramowania wymusza podział na etapy.
Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
Opis metodyki i procesu produkcji oprogramowania
Metodyki prowadzenia projektów - SCRUM
Wykład 1 Najlepsze praktyki
Wykład 8 Przepływ prac: Modelowanie biznesowe
Wykład 7 Przepływ prac: Zarządzanie projektem
Wykład 4 Dynamiczna struktura RUP
1 / 47 WARSZAWA 2005 Przemysław Siekierko Stanisław Andraszek Rational Unified Process.
Rational Unified Process www-306.ibm.com/software/rational/
Propozycja metodyki nauczania inżynierii oprogramowania
Co UML może zrobić dla Twojego projektu?
Tomasz Pieciukiewicz Rafał Hryniów
Cykle życia oprogramowania
Inżynieria Oprogramowania dla Fizyków
Projektowanie systemów informacyjnych
Jakość systemów informacyjnych (aspekt eksploatacyjny)
Rational Unified Process
1/18 LOGO Profil zespołu. 2/18 O nas Produkcja autorskich rozwiązań informatycznych dla małych i średnich firm w zakresie systemów: Baz danych Aplikacji.
Analiza i projektowanie Informacyjnych Systemów Zarządzania
Dalsze elementy metodologii projektowania. Naszym celem jest...
Analiza, projekt i częściowa implementacja systemu obsługi kina
Projekt i implementacja aplikacji wspomagającej testowanie oprogramowania, zgodne z metodologią Unified Software Development Process (RUP). Włodzimierz.
Wykład 4 Analiza i projektowanie obiektowe
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.
C.d. wstępu do tematyki RUP
Model referencyjny łańcucha dostaw
UML 2.x Robert Pająk.
Kontrola spójności modeli UML za pomocą modelu przestrzennego DOD
Model przestrzenny Diagramu Obiegu Dokumentów
Komputerowe wspomaganie pracy inżyniera
Zarządzanie projektami
Microsoft Solution Framework
Magdalena kurzyńska Sławomir Kwasiborski
Metodyki zarządzania projektami
Wykład 6 Przypadki użycia a proces
Zaprojektowanie i wykonanie prototypowego systemu obiegu dokumentów (workflow) dla Dziekanatu Wydziału z wykorzystaniem narzędzi open-source i cloud computing.
Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52.
Program Operacyjny Kapitał Ludzki
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Unified Modeling Language - Zunifikowany Język Modelowania
Wprowadzenie do UML dr hab. inż. Kazimierz Subieta profesor PJWSTK.
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Komputerowe wspomaganie projektowania
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
SZKOŁA Z KLASĄ 2.0 Spotkanie otwierające. SZKOŁA Z KLASĄ 2.0 Serdecznie witam Was w kolejnej – trzeciej już – edycji programu Szkoła z klasą 2.0. W tym.
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
ZASTOSOWANIE KOMPUTEROWEGO WSPOMAGANIA W ZARZĄDZANIU JAKOŚCIĄ - METODY FMEA I QFD Politechnika Śląska, Wydział Organizacji i Zarządzania, Katedra Zarządzania.
ZINTEGROWANE SYSTEMY ZARZĄDZANIA
Systemy zarządzania przepływem pracy i systemy zarządzania procesami biznesowymi Karolina Muszyńska.
Zarządzanie wdrożeniem oprogramowania w organizacji w oparciu o metodykę ITIL Michał Majewski s4440 Praca magisterska napisana pod kierunkiem dr inż. Tomasza.
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 1, Slajd 1 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 1 Najlepsze praktyki Wykładowca:
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.
Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML
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.
Wyższa Szkoła Informatyki i Zarządzania W Bielsku-Białej Kierunek informatyka Specjalność : Systemy informatyczne Praca dyplomowa inżynierska : System.
Inżynieria systemów informacyjnych
Zarządzanie projektami informatycznymi
Inżynieria Oprogramowania Laboratorium
IEEE SPMP Autor : Tomasz Czwarno
Zapis prezentacji:

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ładowca: dr inż. Ewa Stemposz Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 2 Zagadnienia Co to jest RUP? Kto i jak używa RUP? Dwa wymiary RUP Najlepsze praktyki a RUP Podsumowanie Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 3 Co to jest Rational Unified Process ? (1) Rational Unified Process (RUP) − produkt firmy Rational Software, wspomagający zdyscyplinowane podejście do rozwoju oprogramowania, co z założenia powinno ułatwić produkcję oprogramowania wysokiej jakości w przewidywalnym dla klienta czasie i budżecie. RUP oparty został o zbiór sześciu najlepszych praktyk: iteracyjny rozwój, zarządzanie wymaganiami, architektura oparta o komponenty, wizualne modelowanie, systematyczna weryfikacja jakości i zarządzanie zmianami. RUP, to także szkielet, rama (framework), który może być przystosowany (również rozszerzany) stosownie do specyficznych potrzeb adaptującej go organizacji. RUP jest zintegrowany z wieloma produktami firmy Rational Software, np. Rational Rose (modelowanie wizualne) czy ClearCase (zarządzanie zmianami): każde z narzędzi zostało zaprojektowane w taki sposób, by dostarczyć wsparcia również użytkownikom początkującym (tool mentors). Lee Osterweil (1987): “Software processes are software, too”

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 4 Co to jest Rational Unified Process ? (2) RUP – w ramach “douczania” – dostarcza:  Microsoft Word i Adobe FrameMaker: szablony dla podstawowych dokumentów i raportów.  Rational SoDa: szablony wspierające automatyzację prac przy przetwarzaniu dokumentów pochodzących z różnych źródeł.  RequisitePro: szablony wspomagające zarządzanie wymaganiami.  Microsoft Project: szablony wspomagające zarządzaniem projektu opartego o RUP.  HTML: szablony wspierające pracę online. (2) Przykładowe artefakty dla prostych systemów. (1) Szablony dla podstawowych artefaktów wytwarzanych w trakcie procesu projektowego, takich jak np.: E-coach zawiera wiele wariantów RUP (np. RUP dla e-biznesu), które mogą służyć jako punkt startowy dla wielu różnych zastosowań.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 5 Kto i jak używa RUP ? Jak dotąd, RUP został wykorzystany przez więcej niż 1000 organizacji (dane z końca 1999 roku) dla różnych zastosowań, dla małych i dużych projektów:  Telekomunikacja: Ericsson, Alcatel, MCI  Transport, lotnictwo, obrona: Lockheed-Martin, British Aerospace  Produkcja: Xerox, Volvo, Intel  Finanse: Visa, Merrill Lynch, Schwab  Inne: Ernst & Young, Oracle, Deloitte & Touche. Więcej niż 50% użytkowników albo już wykorzystywało albo planowało wykorzystać w najbliższej przyszłości RUP do e-biznesu. Niektóre z organizacji – ściśle w oparciu o RUP – budowały własny proces dostosowany do swoich specyficznych potrzeb, podczas gdy inne wykorzystywały RUP bardziej nieformalnie, traktując je jak repozytorium dobrych rad, wytycznych i szablonów.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 6 Dwa wymiary RUP (1) Strukturę RUP można analizować z dwóch perspektyw, zwanych tu “wymiarami”: (1) Wymiar statyczny, związany ze statycznymi aspektami procesu, takimi jak, np. części składowe procesu: aktywności, przepływy prac, artefakty i uczestnicy projektu. Wymiar statyczny procesu jest reprezentowany przez oś pionową rysunku na następnej folii. Na osi pionowej zostały oznaczone główne przepływy prac, grupujące aktywności zgodnie z ich wewnętrzną naturą. (2) Wymiar dynamiczny, reprezentujący aspekty dynamiczne procesu i opisywany w terminach, takich jak: cykle, fazy, iteracje i kamienie milowe. Oś pozioma rysunku reprezentująca ten wymiar odzwierciedla upływ czasu.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 7 Dwa wymiary RUP (2) Fazy PoczątkowaOpracowywanie Modelowanie biznesowe Wymagania Analiza i projektowanie Implementacja Testowanie Konfiguracja i zarządzanie zmianami KonstrukcjaWdrażanie Zarządzanie projektem Środowisko Przepływy prac Wdrażanie Iter. #1Iter.#1, Iter.#2Iter.#1, Iter.#2, Iter.#3Iter.#1, Iter.#2 Iteracje

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 8 Najlepsze praktyki a RUP (1) Iteracyjny rozwój  zarządzanie wymaganiami,  integrację elementów składowych produktu (integracja postępuje progresywnie, a nie w postaci jednego “big bang” na końcu, ponadto integruje się mniejsze elementy),  wcześniejszą mitygację ryzyk (z reguły moment integracji jest tym momentem, w którym odsłaniają się zagrożenia dla projektu),  ponowne użycie,  bardziej stabilną architekturę,  zwiększenie zaangażowania i umiejętności uczestników projektu (patrz przykład testerów),  ulepszanie procesu w efekcie nabywania doświadczeń w kolejnych iteracjach. W RUP planowana jest liczba iteracji, cel i czas trwania każdej z nich, tak by zapobiec powstaniu niekontrolowanego, trwającego bez końca procesu. Podejście iteracyjno-przyrostowe rekomendowane przez RUP wspomaga:

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 9 Najlepsze praktyki a RUP (2) Zarządzanie wymaganiami  lepszą kontrolę złożonych projektów,  uzyskanie produktu o lepszej jakości,  zwiększenie satysfakcji klienta,  poprawę komunikacji w zespole projektowym. Zarządzanie wymaganiami rekomendowane przez RUP wspomaga: Architektura oparta o komponenty Aktywności związane z projektowaniem, szczególnie w pierwszych iteracjach, skupione są głównie na definiowaniu architektury przyszłego systemu. W efekcie, w pierwszych iteracjach powstaje architektoniczny prototyp, stopniowo ewoluujący, aż do przybrania ostatecznej postaci systemu w iteracjach końcowych. RUP wspiera systematyczne, metodyczne podejście do projektowania, rozwijania i poddawania walidacji architektury systemu oferując style architektoniczne, reguły, ograniczenia oraz szablony dla opisu architektury bazujące na idei posiadania wielu perspektyw systemu.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 10 Najlepsze praktyki a RUP (3) Komponent: Nietrywialny fragment systemu, który wykonuje jasno sformułowane zadania i jest dobrze wyizolowany z otoczenia dzięki wyraźnie określonym granicom. Komponent stanowi realizację elementu z modelu logicznego (z reguły tzw. podsystemu). Komponenty mogą być niezależnie, stopniowo (dzięki iteracyjnemu podejściu) rozwijane i stopniowo integrowane – “stary” pomysł bazujący na pojęciach: modularność i hermetyzacja (obiektowość idzie tu trochę dalej). Niektóre z komponentów mogą być przekształcane w aktywa ponownego użycia – wtedy powinny obejmować większy, spójny fragment oprogramowania. Aktywa ponownego użycia wyodrębnione w jednym projekcie, mogą znaleźć zastosowanie w innych projektach w obrębie danej firmy, dzięki czemu ich tworzenie może wywierać znaczący wpływ na wzrost produktywności, a przez to na poprawę jakości produktów danej organizacji jako całości. CORBA, ActiveX, JavaBeans: co budować, co wykorzystać, co kupić? Dwa ostatnie punkty przesuwają ciężar budowy systemów z “programowania” na “składanie z komponentów”.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 11 Najlepsze praktyki a RUP (4) Wizualne modelowanie (UML) a RUP  UML – język, z notacją graficzną, do specyfikowania, wizualizowania i dokumentowania artefaktów wytwarzanych w trakcie procesu projektowego.  UML nie jest metodyką, nie narzuca reguł tworzenia systemu, jedynie wspomaga modelowanie. Systematyczna weryfikacja jakości: jakość procesów i produktu  RUP nie próbuje wyróżniać grupy członków zespołu projektowego odpowiedzialnych za jakość produktu, przeciwnie za ostateczną jakość produktu odpowiedzialny jest każdy członek zespołu.  Jakość produktu dotyczy wszystkich artefaktów, które ten produkt obejmuje.  Jakość procesów zależy od tego w jakim stopniu pomiary i kryteria jakości dla artefaktów wytwarzanych “w trakcie” (takich, jak np: plan iteracji, plan testów, realizacja use-case, model, itp.) są ustalone i rzeczywiście wykorzystywane.  RUP poświęca wiele uwagi systematycznej weryfikacji jakości.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 12 Najlepsze praktyki a RUP (5) Konfiguracja i zarządzanie zmianami W trakcie procesu projektowego, a szczególnie procesu opartego o podejście iteracyjne wiele produktów podlega modyfikacji. RUP wspomaga zarządzanie zmianami dzięki umożliwieniu śledzenia zmian w wymaganiach, projekcie implementacji i samej implementacji. Są zdefiniowane aktywności (wraz z odpowiednimi artefaktami) umożliwiające śledzenie defektów, nieporozumień czy uzgodnień. Inne własności RUP  Rozwijanie oprogramowania w oparciu o przypadki użycia.  Możliwość wykorzystania RUP jako wzorca (szablonu), który może być rozszerzany i przystosowywany do własnych potrzeb (konfiguracja procesu). Wszystkie elementy statyczne procesu: artefakty, aktywności. przepływy prac, wytyczne, szablony mogą być modyfikowane.  Istnienie narzędzi, które wspierają tworzenie i zarządzanie artefaktami wytwarzanymi w trakcie procesu projektowego.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 13 Inne własności RUP Rozwijanie oprogramowania w oparciu o przypadki użycia  Przypadki użycia tworzą połączenie między zbiorem wymagań a innymi artefaktami wytwarzanymi w procesie projektowym, takimi jak np. projekt implementacji, kod czy testy. Ta własność powoduje, że są powszechnie wykorzystywane w procesie budowy oprogramowania (choć nie są elementem koniecznym, również w podejściu obiektowym).  RUP wspiera rozwijanie oprogramowania w oparciu o przypadki użycia, co oznacza, że w RUP właśnie przypadki użycia stanowią podstawę dla kolejnych etapów projektowych. Przypadki użycia grają główną rolę w przepływach prac, takich jak: wymagania, analiza i projektowanie, testowanie czy zarządzanie projektem. Konfiguracja procesu RUP może być z powodzeniem wykorzystany w postaci “as is” dla małych i średnich organizacji, szczególnie dla tych, które nie rozwinęły własnego procesu.

E. Stemposz. Rational Unified Process, Wykład 2, Slajd 14 Podsumowanie RUP przykrywa całość cyklu życiowego SI. RUP wykorzystuje najnowsze trendy i technologie: obiektowe podejście, architektura oparta o komponenty, modelowanie wizualne z UML, podejście iteracyjne, itd. RUP jest systematycznie rozwijany i ulepszany (nie jest produktem zamrożonym”). RUP posiada “solidną” architekturę, która może być przystosowana do konkretnych potrzeb użytkownika. RUP wspiera rozwój oprogramowania w oparciu o sześć najlepszych praktyk: iteracyjny rozwój, zarządzanie wymaganiami, architektura oparta o komponenty, wizualne modelowanie, systematyczna weryfikacja jakości i zarządzanie zmianami. RUP posiada całą paletę narzędzi wspierających.