rpisc, nauka, realizacja projektu informatycznego
[ Pobierz całość w formacie PDF ]
RUP – Rational Unified Process Dyscypliny RUP: • Modelowanie biznesowe • Wymagania • Analiza i projektowanie • Implementacja • Testowanie • Wdrożenie • Zarządzanie konfiguracją i zmianami • Zarządzanie projektem • Środowisko Elementy procesu: • Czynność (Activity) • Częściowy porządek czynności • Rola (Worker) • Rola pełniona przez osobę lub zespół (analityk, projektant, dokumentalista, etc.) • Produkt (Artifact) • Porcja informacji wytwarzana, modyfikowana lub używana przez proces (model, kod, dokument, etc.) Lista kontrolna - Lista pytań pozwalająca oszacować jakość artefaktu FAZA INCEPTION Cele • ustalenie zakresu produktu • określenie głównych scenariuszy i przypadków użycia • wskazanie potencjalnej architektury systemu • oszacowanie kosztu i harmonogramu projektu • ocena ryzyka • przygotowanie środowiska wspomagającego projektu Główne produkty • Wizja (ang. Vision) • Kontekst biznesowy (ang. Business Case) • Lista zagrożeń (ang. Risk List) • Plan wytwarzania oprogramowania (ang. Software Development Plan) • Plan iteracji (ang. Iteration Plan) • Proces wytwórczy (ang. Development Case) • Narzędzia • Słownik pojęć • Model przypadków użycia (ang. Use Case Model) • Repozytorium projektu MODELOWANIE BIZNESOWE Proces biznesowy : Zbiór działań, które łącznie dostarczają odbiorcy oczekiwany rezultat • Elementy procesu biznesowego: • odbiorcy (jeden lub więcej) • rezultat (produkt i/lub usługa – wartość!) • działania • aktorzy - ludzie lub maszyny wykonujący działania, mają przypisane role • zasoby - informacja i materiały potrzebne do wykonywania działań Proces można dekomponować na podprocesy - działania danego procesu biznesowego mogą być innymi procesami biznesowymi Perspektywy statyczne Cele • przedstawia hierarchę celów organizacji od celów strategicznych do celów operacyjnych poszczególnych podprocesów • typowy środek wyrazu: diagramy statyczne np. klas Zasoby • przedstawia strukturę zasobów organizacji takich jak ludzie, surowce, produkty, informacja • typowy środek wyrazu: diagramy statyczne np. klas Perspektywy dynamiczne Funkcjonalność • przedstawia zależności funkcjonalne między elementami procesu: podprocesami, działaniami, zasobami, produkowanie/używanie zasobów • typowy środek wyrazu: diagram przepływu (ang. workflow) Zachowanie • przedstawia kolejność wykonywania działań, reguły sterowania (zależności czasowe, zdarzenia, kryteria wejściowe i wyjściowe) • typowy środek wyrazu: diagramy stanów i sekwencji Możliwe jest połączenie perspektywy funkcjonalnej i zachowania w jednym zaawansowanym środku wyrazu, np. rozbudowanych diagramach przepływu. We wszystkich perspektywach należy ująć reguły biznesowe. WYMAGANIA Udziałowcem projektu jest każdy podmiot (niekoniecznie ożywiony), który ma uzasadnione prawo wywarcia (pośrednio lub bezpośrednio) wpływu lub może znaleźć się pod wpływem rozpatrywanego projektu (klient, wykonawca, dostawca, oprogramowanie, urządzenie współdziałające, udziałowcy pośredni). Wizja systemu: Cele systemu, Kontekst biznesowy, Udziałowcy i użytkownicy, Ogólny opis produktu, Wymagania funkcjonalne, Ograniczenia (techniczne – projektowe, realizacji projektu), Wymagania pozafunkcjonalne, Wymagania dokumentacyjne. ZARZĄDZANIE Ryzyko – możliwość wystąpienia zagrożeń Zagrożenia – sytuacje o niepożądanych konsekwencjach, obniżających sukces przedsięwzięcia Przykłady zagrożeń (na różnych etapach projektu) • Koniec: przekroczenie budżetu, przekroczenie harmonogramu • Wymagania: pominięcie istotnego udziałowca, mało precyzyjne wymagania • Projekt: źle dobrana technologia, nieskalowalna architektura • Implementacja: nowe nieznane narzędzia, utrata kodu • Testowanie: małe pokrycie zakresu produktu testami • Zarządzanie: brak doświadczenia kierownika, utrata kluczowych osób Szacowanie zagrożeń • szansa wystąpienia • skala strat – negatywnego wpływu na projekt Ocena ryzyka identyfikacja, analiza, planowanie, śledzenie, nadzór, komunikacja Planowanie jest procesem realizowanym w całym cyklu życia przedsięwzięcia. W RUP: • Plan wytwarzania oprogramowania • Plan iteracji SZACOWANIE Co szacujemy • Szacowanie kosztu • Szacowanie nakładu i nakładu pracy • Szacowanie czasu realizacji (Mo - months) • Liczby zaangażowanych osób Metody szacowania • Przez analogię • Przez eksperta lub oprogramowanie; Wide-Band Delphi • Dostępne środki • Cena do uzyskania • Mikrotechnika (oddolnie, bottom-up) • Makrotechnika (odgórnie, top-down) • Modele parametryczne (COCOMO, FPA) Harmonogram – następstwo zadań, ich rozpoczęcia i ukończenia, odwzorowane w czasie FAZA ELABORATION Główne artefakty wejściowe z fazy Inception • Wizja - kandydujące architektury • Model przypadków użycia – zakres systemu • Plan wytwarzania oprogramowania i plan iteracji – plany dalszego działania Cele • ustabilizowanie planów, wymagań i architektury • obniżenie zagrożeń związanych z wyborem architektury • zatwierdzenie architektury wspierającej zakres systemu • stworzenie prototypów • przygotowanie środowiska wspomagającego wytwarzanie Główne produkty • Definicja architektury oprogramowania (ang. Software Architecture Document) • Model projektowy (ang. Design Model) • Model danych (ang. Data Model) • Prototypy • Model implementacyjny (ang. Implementation Model) • Zalecenia do programowania (ang. Programming Guidelines) • Zestaw testów (ang. Test Suite) • Architektura automatyzacji testów (ang. Test Automation Architecture) + aktualizacja dokumentów fazy Inception: Wizja, Lista zagrożeń, Plan wytwarzania oprogramowania, Plan iteracji, Proces wytwórczy, Model przypadków użycia. Analiza zachowania Przepływ sterowania w systemie w obsłudze przypadków użycia. Identyfikacja klas analitycznych z opisu przypadku użycia • Klasy graniczne – przez te klasy system komunikuje się z otoczeniem • Klasy sterujące – klasy obejmują logikę przypadków użycia • Klasy encyjne – klasy odpowiadające danym (często trwałym) Identyfikacja odpowiedzialności klas analitycznych • atrybutów – wiedzy obiektów • metod – czynności które obiekt może wykonywać • związków – klas od których zależy dana klasa Ustalenie związków strukturalnych klas – diagram klas Ustalenie zależności zdarzeniowej MODEL PROJEKTOWY Podsystem - zbiór elementów modelu, które z zewnątrz widoczne są jak pojedyncza klasa – ma określony interfejs i zachowanie. Podsystem może zawierać: • zwykłe klasy – klasy realizujące łącznie zachowanie podsystemu, których indywidualne zachowanie nie jest bezpośrednio dostępne • realizacje interfejsów – klasy udostępniające zachowanie podsystemu na zewnątrz • inne podsystemy Pakiet – „zwykły” zbiór elementów modelu, np. klas Klasa projektowa – klasa będąca elementem projektu oprogramowania, jeżeli system programowany jest w języku obiektowym klasa projektowa odpowiada klasie w kodzie. MODEL IMPLEMENTACYJNY Model implementacyjny opisuje strukturę komponentów produktu Komponent może być • plikiem źródłowym • plikiem wykonywalnym • biblioteką • plikiem pomocniczym (np. release notes) • stroną aplikacji internetowej • całą aplikacją (komponent złożony) [ Pobierz całość w formacie PDF ] |