PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Model V:

Zalety:

• Przenosi wszystkie zalety cyklu kaskadowego;

• Wysoka jakość produktu końcowego;

• Obniżenie ryzyka popełnienia błędu o charakterze krytycznym;

• Obniżenie kosztu utrzymania systemu;

Wady:

• Przerost dokumentacji;

• Duże nakłady pracy, czasu i kosztu realizacji systemu;

• Możliwe zniechęcenie zespołów wytwórczych, konflikty;

Prototypowanie:

• Jeśli są problemy z identyfikacją wymagań;

• Pojęcie prototypowania konstrukcji - ocena weryfikacji założeń budowy / działania systemu;

Zalety:

• Wspomaganie identyfikacji wymagań (bez specyfikacji);

• Zwiększenie układu klienta w procesie wytwórczym;

• Walidacja logiczna, demonstracyjna rozwiązań;

• Ocena koncepcji konstrukcyjnych;

• Poprawa cech jakościowych;

• Zbliżony koszt do cyklu klasycznego przy innym rozkładzie;

Wady:

• Klient nie rozumie, czemu ma zarzucić działający prototyp;

• Tendencje do kopiowania nieadekwatnych rozwiązań z prototypów;

Spiralny cykl życia systemu:

• Planowanie:

• Wstępne wymagania i planowanie projektu;

• Planowanie na podstawie ocen użytkownika;

• Analiza ryzyka:

• Analiza ryzyka oparta na wstępnych wymogach;

• Analiza ryzyka oparta na reakcji użytkownika;

• Konstrukcja:

• Kolejne prototypy - ku wersji docelowej;

• Ocena użytkownika:

• Oceny dokonywane przez użytkowników;

Zalety:

• Bardzo elastyczny (zmiany otoczenia, alokacja zasobów niestabilność wymagań);

• Nieustanna walidacja;

• Niskie ryzyko niepowodzenia (zakres, jakość);

Wady:

• Długotrwałe dochodzenie do rozwiązania docelowego;

• Dodatkowe koszty tworzenia kolejnych prototypów;

• Kłopoty z zarządzaniem;

• Presja na zmniejszenie jakości;

Podejście przyrostowe:

• Model tradycyjny (w chwili t 100% systemu jest ukończone w 60%)

• Model przyrostowy (w chwili t 60% systemu jest ukończone w 100%)

• Słabo zidentyfikowane problemy;

• Klient nie chce długo czekać na rezultaty;

• Duża skala;

Zalety:

• Każdy przyrost:

• Dodaje nową funkcjonalność;

• Może być realizowany niezależnie;

• Może być testowany niezależnie;

• Jest relatywnie krótki (kilka miesięcy);

• Intensywność prac daje się regulować;

• Funkcjonalność ta jest na bieżąco walidowane przez użytkowników;

• Po każdym przyroście można zakończyć budowę systemu (ucierpi zakres, nie jakość);

• Wymagania mogą być tylko częściowo zidentyfikowane;

• Klient szybko otrzymuje jakiś rezultat;

Wady:

• Niestety czasochłonny;

• Kłopoty z dekompozycją usług;

• Może skłaniać do pracy z przestarzałymi rozwiązaniami;

Problemy tradycyjnych cykli życia oprogramowania:

• Procesy wytwórcze są mocno sformalizowane i ukierunkowane na korygowanie ludzkiej natury - błędy;

• Zwykle wymagają rozbudowanej dokumentacji;

• Często pomijają iteracyjny charakter prac;

• Nie wykorzystują należycie doświadczeń, wiedzy, produktów poprzednich projektów;

• Z nielicznymi wyjątkami, nie wykorzystują zintegrowanego wsparcia narzędziowego;

Efekt?

• Jeszcze więcej procedur!!!

• Kompleksowe biblioteki metodologicznej;

• Reguły, wzorce, dobre praktyki;

• Proponowane dokumenty;

• Podejście "lekkie", agilne

• Maksymalne uproszczenie;

• Bardzo intensywny kontakt z klientem;

Rational Unified Process - dyscypliny:

• Modelowanie biznesowe;

• Specyfikacja wymagań;

• Analiza i projektowanie;

• Programowanie;

• Testowanie;

• Wdrożenie;

• Zarządzanie konfiguracjami i zmianami;

• Zarządzanie projektem;

• Przygotowanie środowiska;

Fazy Rational Unified Process:

	ROZPOCZĘCIE	OPRACOWANIE	BUDOWA	PRZEKAZANIE
CELE	Ustalenie zakresu; Ustalenie ograniczeń;	Model dziedziny; Walidacja architektury;	Otrzymanie funkcjonalnych wersji systemu; Minimalizacja kosztów wytworzenia; Osiągnięcie adekwatnej jakości;	Wdrożenie systemu w środowisku docelowym; Akceptacja systemu;
CZYNNOŚCI	Formułowanie zakresu; Prototypowanie; Planowanie; Szacowanie ryzyka;	Analiza dziedziny problemowej; Określenie architektury systemowej; Opracowanie środowiska wytwarzania;	Zarządzanie zasobami; Optymalizacja procesu; Wytwarzanie/pozyskiwanie komponentów; Testowanie; Ocena kolejnych wydań;	Testowanie; Integracja; Konwersja danych; Szkolenia;
PRODUKTY	Dokument wizji systemu; SWS; Lista przypadków użycia; Słownik systemu; Plan; Dokument oceny ryzyka;	Model przypadków użycia (80%) Model architektury; Prototyp; Uściślony plan; Uściślony dokument oceny ryzyka;	Produkt zintegrowany z docelową platformą; Podręcznik użytkownika; Dokumentacja wydania;	Działający system;

Model - Driven Architecture:

• Standard budowy systemów organizacji OMG;

• Integracja dobrych praktyk:

• Modelowanie;

• Oprogramowanie pośredniczące (middleware);

• Metadane;

• Mobilność;

• Architektura;

Model - Driven Development:

• Model CIM (Computation Independent Model):

• Poziom biznesowy;

• Logika i zawartość informacyjna systemu;

• Model PIM (platform-Independent Model):

• Funkcjonalność realizowana informatycznie;

• Mechanizmy komunikacji, szeregowanie zadań, itd.;

• Charakter uniwersalny;

• Model PSM (platform - Specyfic Model):

• Ujmuje elementy charakterystyczne dla danej platformy;

Korzyści:

• Wzrost produktywności architektów, projektantów, programistów administratorów;

• Obniżenie kosztów wytwarzania i zarządzania aplikacjami;

• Zwiększenie przenośności i współdziałania;

• Model biznesowy i technologie ewoluują dotrzymując kroku zmianom platform;

Wielokrotne użycie:

Co może być zasobem?

• Dla potrzeb analizy:

• Modele dziedziny;

• Specyfikacje wymagań;

• Wzorce testów;

• Formularze;

• Dla potrzeb projektowania:

• Architektury biznesowe;

• Wzorce rozwiązań architektonicznych;

• Komponenty składowe rozwiązań projektowych;

• Komponenty programowe:

• Biblioteki;

• Pliki wykonalne;

• Pliki konfiguracyjne;

• Zestawy danych testowych;

• Elementy GUI (formatki, kontrolki);

• Wiedza i doświadczenie ludzi;

Podeście agilne:

Agile Manifesto :

• Ludzie i interakcje są ważniejsze niż procesy i narzędzia;

• Działające oprogramowanie jest ważniejsze od kompletnej dokumentacji;

• Współpraca z klientem jest ważniejsza od negocjacji kontraktów;

• Reagowanie, adaptacja do zmieniających się potrzeb ą ważniejsze niż utrzymanie planów;

• Cenimy wartości po prawej stronie tych zdań, ale te po lewej cenimy wyżej;

Przykłady:

• SCRUM;

• XP (Extreme Programming);

Podejście agilne - kiedy?

• Nieduże projekty;

• Małe zespoły;

• Nie ma konieczności sporządzania dokumentacji utrzymaniowej;