Czym jest PIM czyli kto jest programistą

Ten arty­kuł jest adre­so­wa­ny do wszyst­kich. Biznes (praw­ni­cy tak­że) może prze­ko­nać się, że opro­gra­mo­wa­nie moż­na nary­so­wać i zro­zu­mieć. Analitycy i pro­gra­mi­ści, że to moż­li­we, a dewe­lo­pe­rzy, że nikt im nie odbie­ra pra­cy a raczej pomaga. 

Wprowadzenie

W dzi­siej­szym świe­cie inży­nie­rii naj­więk­szą war­tość mają czas i zaso­by. Czas to jak naj­szyb­sze odda­nie roz­wią­za­nia (pro­duk­tu) do użyt­ku (szyb­ka komer­cja­li­za­cja), zaso­by to koszt jakim się to odbę­dzie. Kluczem są kosz­ty: time to mar­ket”, tu kosz­tem jest opóź­nie­nie komer­cja­li­za­cji (nie­zre­ali­zo­wa­ne przy­cho­dy), kosz­tem jest tak­że samo powsta­wa­nia opro­gra­mo­wa­nia. Praktycznie od począt­ku inży­nie­rii opro­gra­mo­wa­nia zależ­ność kosz­tów od dys­cy­pli­ny i eta­pu pra­cy się nie zmie­nia, wyglą­da to jak poniżej:

Źr. Effective softwa­re deli­ve­ry. White paper. May 2009

Od same­go począt­ku prac nad opro­gra­mo­wa­niem tak napraw­dę roz­wią­zu­je­my pro­ble­my: począw­szy od pro­ble­mów z odkry­ciem co tak napraw­dę jest roz­wią­za­niem pro­ble­mu (a pro­blem trze­ba naj­pierw ziden­ty­fi­ko­wać), przez pro­ble­my zwią­za­ne z wła­ści­wym zapro­jek­to­wa­niem roz­wią­za­nia (algo­ryt­my, archi­tek­tu­ra kodu), do pro­ble­mów wybo­ru tech­no­lo­gii i imple­men­ta­cji. Patrząc od koń­ca: pomył­ki są bar­dzo kosz­tow­ne dla orga­ni­za­cji (spon­sor pro­jek­tu). Development (kodo­wa­nie i testy) to pra­ca zespo­łów ludzi, są bar­dzo kosz­tow­ne. Najtańsza jest tu pra­ca (etap) ana­li­ty­ka-pro­jek­tan­ta, to jed­nak tak­że czas (pamię­ta­my time to market”). 

Tak więc water­fall” nie wcho­dzi w grę. Praktyka jed­nak poka­zu­je, że roz­po­czę­cie od razu od kodo­wa­nia nie roz­wią­zu­je żad­ne­go pro­ble­mu bo złe pomy­sły są i będą, kory­go­wa­ne dopie­ro na eta­pie kodo­wa­nia gene­ru­ją bar­dzo duże kosz­ty. Lekarstwem jest odej­ście o mono­li­tycz­nej archi­tek­tu­ry na rzecz samo­dziel­nych kom­po­nen­tów, czy wręcz mikro­ser­wi­sów (jed­nost­ki imple­men­ta­cji to poje­dyn­cze przy­pad­ki uży­cia UML, tu rozu­mia­ne jako nie­za­leż­ne mikro-apli­ka­cje ). Dlatego opty­mal­ne wyda­je sie podej­ście: 1. ana­li­za, 2. pro­jek­to­wa­nie HLD: kom­po­nen­ty, 3. ite­ra­cyj­ne pro­jek­to­wa­nie LLD kom­po­nen­tów i ich deve­lop­ment. Osiągamy waż­ną rzecz: naj­droż­sze zaso­by: deve­lop­ment, dosta­ją do imple­men­ta­cji prze­my­śla­ne roz­wią­za­nie, nie tra­ci­my cza­su i środ­ków na kolej­ne pro­to­ty­py w kodzie. 

(wię­cej…)

Czytaj dalejCzym jest PIM czyli kto jest programistą

Jak wyjść z długu technologicznego jakim jest centralny monolityczny system

Na temat tego jakim uciążliwym długiem technologicznym jest monolityczny system napisano wiele, dzisiaj kolejne dwie ciekawe pozycje literatury: CMMI Compliant Modernization Framework to Transform Legacy Systems oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices . Pierwsza publikacja opisuje metodę zaplanowania wyjścia z długu technologicznego z perspektywy analizy biznesowej, druga opisuje możliwą realizację techniczną z perspektywy architektury aplikacji i ewolucyjnej migracji z architektury monolitycznej do komponentowej (mikro-serwisy). Czym jest monolit? Jest to system, którego architektura stanowi jeden niepodzielny blok realizujący funkcje biznesowe. Kluczową cechą i zarazem wadą,…

Czytaj dalejJak wyjść z długu technologicznego jakim jest centralny monolityczny system

Ontologia – zastosowanie w inżynierii oprogramowania

Ontologia jako narzędzie tworzenia "modeli świata", jest bardzo dobrym narzędziem do projektowania danych, zorganizowanych w łatwe do zarządzania w bazach NoSQL, dokumenty. Wstęp Niedawno napisałem: Czy opra­co­wa­nie onto­lo­gii jest łatwe? Nie, nie jest. Czy zła onto­lo­gia szko­dzi? Tak, potra­fi dopro­wa­dzić do fia­ska pro­jek­tu infor­ma­tycz­ne­go. źr.;: Ontologia czyli jak się to robi Po co to wszystko? Obecnie często mówimy o Big Data, czyli o masowo gromadzonych danych. Ich gromadzenie wymaga opracowania struktury ich gromadzenia i zarządzania nimi, bez tego powstanie "stos nieskatalogowanych dokumentów". Proces gromadzenia danych jest stratny, więc dane te…

Czytaj dalejOntologia – zastosowanie w inżynierii oprogramowania

Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Wprowadzenie Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to "coś nowego", ale być może mają jakieś rady dla projektantów. Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się standardem…

Czytaj dalejInterface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Marsz ku klęsce – Poradnik dla projektanta systemów

Lektura na Nowy Rok... Co prawda wydana w 2007 roku, ale właśnie sobie o niej przypomniałem.. Ta książka Yourdona leży u mnie na półce niemalże od dnia jej wydania, gdy ją przypadkiem upolowałem, zaraz po jej ukazaniu się w księgarniach. Napisanie o niej odkładam od lat, bo praktycznie nie ma tam obrazków UML, opisów wzorców itp.. Od jej przeczytania mówię sobie: jutro o niej napiszę... i to trwało do tego momentu. To książka w całości napisana prozą, bez obrazków, w której autor dzieli sie swoimi przemyśleniami na temat architektury systemów,…

Czytaj dalejMarsz ku klęsce – Poradnik dla projektanta systemów

Opis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

(wię­cej…)

Czytaj dalejOpis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

(wię­cej…)

Czytaj dalejDiagram aktywności UML – kiedy

Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy . Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a…

Czytaj dalejPrzyczyny nieplanowanych kosztów wdrożeń

Mało który deweloper używa UMLa zgodnie ze specyfikacją…

Od cza­su do cza­su wpa­da­ją mi do skrzyn­ki ema­il niu­slet­te­ry”, któ­re gdzieś tam cza­sem zama­wiam, głów­nie z powo­dów poznaw­czych. Oto jeden z nich…

Nie jest tajem­ni­cą, że na ryn­ku mamy róż­ne meto­dy pra­cy i wszyst­kie mają swo­ich zwo­len­ni­ków i prze­ciw­ni­ków czy może raczej kry­ty­ków. Tym razem przed­mio­tem bada­nia” był spo­sób opi­sa­nia pro­ble­mu i wnio­ski jakie autor wyciągnął.

(wię­cej…)

Czytaj dalejMało który deweloper używa UMLa zgodnie ze specyfikacją…

Zwinne projektowanie interfejsu użytkownika

W ostatnim artykule zwracałem uwagę między innymi na bardzo ważny element analizy i projektowania jakim jest abstrahowanie od detali, ponieważ:  ...analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku ?zabity? ich ilością. [1] Nieco wcześniej (2013 r.) pisałem o tym, kiedy uzgadniać detale, które i gdzie one są:  Cała logika biznesowa jest wykonywana wewnątrz aplikacji (informacje o ewentualnych błędach pojawią się po zatwierdzeniu formularza), np. upust może być sprawdzony (albo naliczony) dopiero po skompletowaniu danych wymaganych do jego wyliczenia, czyli będzie to kilka różnych pól (najmniej dwa…

Czytaj dalejZwinne projektowanie interfejsu użytkownika

Wymagania ? Zarządzanie wersjami

Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania. Stosowane są trzy metody (grupy metod) specyfikowania wymagań: Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody). Specyfikowanie tak zwanej "czarnej skrzynki" (przypadki użycia). Specyfikowanie tak zwanej "białe skrzynki" (przypadki użycia + model dziedziny systemu). Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i…

Czytaj dalejWymagania ? Zarządzanie wersjami

Koniec treści

Nie ma więcej stron do załadowania