Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

[toc]

SPEM

Autorzy spe­cy­fi­ka­cji piszą, że celem SPEM jest:

przed­sta­wie­nie wyczer­pu­ją­cej defi­ni­cji Meta-Modelu Inżynierii Procesów Oprogramowania i Systemów […]. Metamodel wyko­rzy­stu­je UML jako nota­cję i przyj­mu­je podej­ście zorien­to­wa­ne obiektowo.

Specyfikacja ta ope­ru­je na bar­dzo dużym pozio­mie ogól­no­ści (meta­mo­del), ale mimo to pre­cy­zyj­nie opi­su­je upo­rząd­ko­wa­ne podej­ście do pro­ce­su wytworzenia/dostarczenia opro­gra­mo­wa­nia. Stanowi for­mę stan­da­ry­za­cji tego pro­ce­su (inży­nie­rii oprogramowania).

Etapy procesu tworzenia systemu

Poglądowa pre­zen­ta­cja pro­ce­su SPEM i jego oto­cze­nia .

Autorzy wyróż­nia­ją: etap ana­li­zy biz­ne­so­wej, któ­re­go celem jest oce­na moż­li­wo­ści, rodzaj stu­dium wyko­nal­no­ści (OE) oraz etap opra­co­wa­nia i dostar­cze­nia roz­wią­za­nia (PA, A, DC, I). W tym dru­gim wydzie­lo­no trze­cią fazę: pro­jek­to­wa­nia i wyko­na­nia imple­men­ta­cji (DC i I). Taki podział jest zgod­ny z trze­ma typa­mi mode­li MDA (Model Driven Architecture) odpo­wied­nio: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model). Wydzielenie samo­dziel­ne­go trze­cie­go eta­pu ma fun­da­men­tal­ne zna­cze­nie: oddziel­nie pro­jek­to­wa­nia roz­wią­za­nia od jego dostar­cze­nia. Powodem jest od daw­na sta­wia­na teza, że to rynek powi­nien decy­do­wać o wybo­rze tech­no­lo­gii wyko­na­nia i dawać szan­sę na wyko­rzy­sta­nie dostęp­ne­go już na ryn­ku roz­wią­za­nia zgod­ne­go z opi­sem wyma­ga­nej logi­ki dzia­ła­nia. Innymi sło­wy decy­zja o tym, że roz­wią­za­nie (apli­ka­cja) jest dedy­ko­wa­ne, powin­na zapa­dać nie na począt­ku a dopie­ro po opra­co­wa­nie pro­jek­tu i upew­nie­niu się, że żad­ne ist­nie­ją­ce już na ryn­ku roz­wią­za­nie do nie­go nie pasuje.

Iteracyjny proces wytwarzania

Autorzy zwra­ca­ją uwa­gę, że pro­ces ten nie jest tak zwa­nym wodo­spa­dem. Na eta­pie PA (powyż­szy dia­gram) powsta­je tak zwa­na archi­tek­tu­ra wyso­kie­go pozio­mu i przy­pad­ki uży­cia (te są wywo­dzo­ne z eta­pu OE). Kolejne pro­duk­ty do mode­le i ich imple­men­ta­cje. Kolejne ite­ra­cje to roz­wój dostar­czo­ne­go rozwiązania: 

Agile jako ite­ra­cyj­no-przy­ro­sto­we podej­ście do pro­ce­su pro­jek­to­wa­nia i imple­men­ta­cji .

Struktura procesu

Ciekawą for­mę poka­za­nia tego zapro­po­no­wa­li auto­rzy specyfikacji:

MOF – poziomy abstrakcji

Modele powsta­ją­ce w wyżej opi­sa­nym pro­ce­sie zosta­ły tak­że nało­żo­ne” na spe­cy­fi­ka­cję MOF (Meta Object Facility): 

W dużym skró­cie: M3 to wspól­ny meta­mo­del nota­cji w OMG. Poziom M2 to meta-mode­lo­wa­nie (kla­sy obiek­tów), to obszar reali­za­cji ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo, to tu defi­nio­wa­ny jest SPEM. M1 to fra­me­wor­ki i ich pro­duk­ty. Pokazano to na przy­kła­dzie poniżej:

Role i produkty

Z per­spek­ty­wy ana­li­zy i pro­jek­to­wa­nia istot­ne są role i głów­ne tak zwa­ne artefakty:

Jak widać klu­czo­wa jed­nost­ką pra­cy (work bre­ak­down struc­tu­re) jest przy­pa­dek uży­cia. Nie ma tu ana­li­ty­ka Biznesowego :). 

Przypadki użycia i ich statusy

Zależnie od podej­ścia («High Ceremony» lub «Low Ceremony») zarzą­dza­my sied­mio­ma lub trze­ma sta­tu­sa­mi przy­pad­ków uży­cia (ja oso­bi­ście sto­su­ję wer­sje z trzema).

Opisałem tu po krót­ce klu­czo­we ele­men­ty SPEM, zain­te­re­so­wa­nym deta­la­mi pole­cam zapo­zna­nie się z oryginałem.

Podsumowanie

Podsumowując moż­na to przed­sta­wić tak:

SPEM, opra­co­wa­nie wła­sne autora.

Powyższy dia­gram pokazuje: 

  • Wymagania (cele) biz­ne­so­we jako cele kon­kret­ne­go pro­jek­tu (okre­ślo­ny pro­blem jaki orga­ni­za­cja ma do rozwiązania),
  • Analiza i projektowanie:
    • Audyt i analiza
      • Model moty­wa­cji biz­ne­so­wej (jako test spój­no­ści wizji projektu), 
      • Dziedzinowe tek­sty czy­li pro­za” i for­mu­la­rze sto­so­wa­ne w organizacji,
      • Na bazie tek­stów dzie­dzi­no­wych budo­wa­na jest onto­lo­gia (słow­nic­two i związ­ki poję­cio­we, jakie zosta­ną uży­te w modelach)
      • Na bazie mode­lu Motywacji biz­ne­so­wej powsta­ją Modele pro­ce­sów biz­ne­so­wych, te korzy­sta­ją z Ontologii,
    • Projektowanie roz­wią­za­nia
      • Przypadki uży­cia wywo­dzo­ne z pro­ce­sów biznesowych,
      • Struktury doku­men­tów wywo­dzo­ne z pro­ce­sów biz­ne­so­wych (ich pro­duk­ty), odwo­łu­ją się do Przypadków Użycia i są ich czę­ścią (imple­men­ta­cja usług),
      • Architektura wywo­dzo­na z tre­ści dokumentów, 
      • Każdy przy­pa­dek ma wła­sną imple­men­ta­cję zbu­do­wa­ną jako sce­na­riu­sze komu­ni­ka­cji mię­dzy kom­po­nen­ta­mi (archi­tek­tu­ra).
  • Przypadki uży­cia i ich archi­tek­tu­ra imple­men­ta­cji są bazą dla wyko­na­nia tej imple­men­ta­cji czy­li dzia­ła­ją­ce­go oprogramowania.

Na zakończenie

Czy to trud­ne? No nie jest to łatwe z uwa­gi na war­stwę abs­trak­cyj­ną sta­no­wią­cą fun­da­ment cało­ści pro­jek­tu: trze­ba ją rozu­mieć. Czy to wodo­spad? Nie. Pierwsze dwa eta­py to od kwar­ta­łu do poło­wy roku, zależ­nie od ska­li pro­jek­tu, gdzie w przy­pad­ku więk­sze­go pro­jek­tu ite­ra­cyj­ne imple­men­ta­cje usług mogą zostać roz­po­czę­te w toku prac nad projektem.

Czy świat tak reali­zu­je pro­jek­tu? Owszem, np. tak: Use Case 2.0.

Pytania?

Piszcie tu pod artykułem. 

Źródła

Object Management Group. (2008). About the Software & Systems Process Engineering Metamodel Specification Version 2.0 (SPEM). https://​www​.omg​.org/​s​p​e​c​/​S​P​E​M​/​2​.​0​/​A​b​o​u​t​-​S​P​EM/

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma jeden komentarz

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.