Tym razem artykuł adresowany do zaawansowanych analityków.

Ta specyfikacja (SPEM) jest datowana na 2008 rok. Stanowi sobą tło dla MDA oraz uzasadnia wzorce projektowane oparte na przypadkach użycia (mikroserwisy, Use Case 2.0, inne podobne). Podstawowa różnica między specyfikacją SPEM a specyfikacją UML polega na tym, że UML to profile MOF stanowiące opisy notacji i systemów pojęciowych. SPEM to metamodel procesu wytwórczego oprogramowania czyli generalne zasady budowania procesów wytwarzania i dostarczania oprogramowania.

[toc]

SPEM

Autorzy specyfikacji piszą, że celem SPEM jest:

przedstawienie wyczerpującej definicji Meta-Modelu Inżynierii Procesów Oprogramowania i Systemów […]. Metamodel wykorzystuje UML jako notację i przyjmuje podejście zorientowane obiektowo.

Specyfikacja ta operuje na bardzo dużym poziomie ogólności (metamodel), ale mimo to precyzyjnie opisuje uporządkowane podejście do procesu wytworzenia/dostarczenia oprogramowania. Stanowi formę standaryzacji tego procesu (inżynierii oprogramowania).

Etapy procesu tworzenia systemu

Autorzy wyróżniają: etap analizy biznesowej, którego celem jest ocena możliwości, rodzaj studium wykonalności (OE) oraz etap opracowania i dostarczenia rozwiązania (PA, A, DC, I). W tym drugim wydzielono trzecią fazę: projektowania i wykonania implementacji (DC i I). Taki podział jest zgodny z trzema typami modeli MDA (Model Driven Architecture) odpowiednio: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model). Wydzielenie samodzielnego trzeciego etapu ma fundamentalne znaczenie: oddzielnie projektowania rozwiązania od jego dostarczenia. Powodem jest od dawna stawiana teza, że to rynek powinien decydować o wyborze technologii wykonania i dawać szansę na wykorzystanie dostępnego już na rynku rozwiązania zgodnego z opisem wymaganej logiki działania. Innymi słowy decyzja o tym, że rozwiązanie (aplikacja) jest dedykowane, powinna zapadać nie na początku a dopiero po opracowanie projektu i upewnieniu się, że żadne istniejące już na rynku rozwiązanie do niego nie pasuje.

Iteracyjny proces wytwarzania

Autorzy zwracają uwagę, że proces ten nie jest tak zwanym wodospadem. Na etapie PA (powyższy diagram) powstaje tak zwana architektura wysokiego poziomu i przypadki użycia (te są wywodzone z etapu OE). Kolejne produkty do modele i ich implementacje. Kolejne iteracje to rozwój dostarczonego rozwiązania:

Struktura procesu

Ciekawą formę pokazania tego zaproponowali autorzy specyfikacji:

MOF – poziomy abstrakcji

Modele powstające w wyżej opisanym procesie zostały także “nałożone” na specyfikację MOF (Meta Object Facility):

W dużym skrócie: M3 to wspólny metamodel notacji w OMG. Poziom M2 to meta-modelowanie (klasy obiektów), to obszar realizacji analizy i projektowania zorientowanego obiektowo, to tu definiowany jest SPEM. M1 to frameworki i ich produkty. Pokazano to na przykładzie poniżej:

Role i produkty

Z perspektywy analizy i projektowania istotne są role i główne tak zwane artefakty:

Jak widać kluczowa jednostką pracy (work breakdown structure) jest przypadek użycia. Nie ma tu analityka Biznesowego :).

Przypadki użycia i ich statusy

Zależnie od podejścia (‘High Ceremony’ lub ‘Low Ceremony’) zarządzamy siedmioma lub trzema statusami przypadków użycia (ja osobiście stosuję wersje z trzema).

Opisałem tu po krótce kluczowe elementy SPEM, zainteresowanym detalami polecam zapoznanie się z oryginałem.

Podsumowanie

Podsumowując można to przedstawić tak:

Powyższy diagram pokazuje:

• Wymagania (cele) biznesowe jako cele konkretnego projektu (określony problem jaki organizacja ma do rozwiązania),
• Analiza i projektowanie:
  • Audyt i analiza
    • Model motywacji biznesowej (jako test spójności wizji projektu),
    • Dziedzinowe teksty czyli “proza” i formularze stosowane w organizacji,
    • Na bazie tekstów dziedzinowych budowana jest ontologia (słownictwo i związki pojęciowe, jakie zostaną użyte w modelach)
    • Na bazie modelu Motywacji biznesowej powstają Modele procesów biznesowych, te korzystają z Ontologii,
  • Projektowanie rozwiązania
    • Przypadki użycia wywodzone z procesów biznesowych,
    • Struktury dokumentów wywodzone z procesów biznesowych (ich produkty), odwołują się do Przypadków Użycia i są ich częścią (implementacja usług),
    • Architektura wywodzona z treści dokumentów,
    • Każdy przypadek ma własną implementację zbudowaną jako scenariusze komunikacji między komponentami (architektura).
• Przypadki użycia i ich architektura implementacji są bazą dla wykonania tej implementacji czyli działającego oprogramowania.

Na zakończenie

Czy to trudne? No nie jest to łatwe z uwagi na warstwę abstrakcyjną stanowiącą fundament całości projektu: trzeba ją rozumieć. Czy to wodospad? Nie. Pierwsze dwa etapy to od kwartału do połowy roku, zależnie od skali projektu, gdzie w przypadku większego projektu iteracyjne implementacje usług mogą zostać rozpoczęte w toku prac nad projektem.

Czy świat tak realizuje projektu? Owszem, np. tak: Use Case 2.0.

Pytania?

Piszcie tu pod artykułem.

Źródła