Projekt aplikacji – przykład

Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

Czytaj dalej… Projekt apli­ka­cji – przy­kład”

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten arty­kuł moż­na czy­tać na dwa spo­so­by: ana­li­ty­cy czy­ta­ją od dechy do dechy po kolei ;). Menedżerowie i tak zwa­ny biz­nes czy­ta­ją od razu koniec, to jest część Na zakoń­cze­nie, gdy uzna­ją, że nie wie­rzą w te wnio­ski (wyrok) to zaczy­na­ją od począt­ku czy­li czy­ta­ją uzasadnienie :).

Niedawno napi­sa­łem:

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. (Źródło: Analiza a mode­lo­wa­nie czy­li ile abs­trak­cji a ile rze­czy­wi­sto­ści | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej per­spek­ty­wy powie­my sobie teraz o eta­pach ana­li­zy i pro­jek­to­wa­nia w inży­nie­rii, nie tyl­ko opro­gra­mo­wa­nia, w opar­ciu o MDA ([[Model Driven Architecture]], www​.omg​.org/​mda, pole­cam tak­że poję­cie [[model dri­ven engi­ne­ering]]). Dobra infor­ma­cja dla czy­tel­ni­ków: na koń­cu się wszyst­ko wyja­śni, moż­na pomi­nąć część o MDA 🙂

MDA

Pięć lat temu, jeden z arty­ku­łów o mode­lo­wa­niu i pro­jek­to­wa­niu, koń­czy­łem tymi słowami:

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biz­ne­su czy­li dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tek­ście wła­śnie na MDA. Czymże to jest? Na stro­nach OMG znaj­dzie­my: Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revi­sed MDA Guide edi­ted in Boston on 18 June 2014 reflects all AB edits requ­ested at the Reston and Boston AB meetings. (Źródło: OMG Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0)

Skorzystam z kil­ku cyta­tów i napi­sze co nie­co o MDA. Poniżej klu­czo­we tezy, nie mia­łem tu ambi­cji lite­ral­ne­go tłu­ma­cze­nia tego doku­men­tu, cho­dzi­ło mi o pryncypia.

This guide descri­bes the Model Driven Architecture (MDA) appro­ach as defi­ned by the Object Management Group (OMG). MDA pro­vi­des an appro­ach for deri­ving value from models and archi­tec­tu­re in sup­port of the full life cyc­le of phy­si­cal, orga­ni­za­tio­nal and I.T. sys­tems (A ?System?, in this con­text, is any arran­ge­ment of parts and the­ir inter­re­la­tion­ships, wor­king toge­ther as a who­le.). The MDA appro­ach repre­sents and sup­ports eve­ry­thing from requ­ire­ments to busi­ness mode­ling to tech­no­lo­gy imple­men­ta­tions. By using MDA models, we are able to bet­ter deal with the com­ple­xi­ty of lar­ge sys­tems and the inte­rac­tion and col­la­bo­ra­tion betwe­en orga­ni­za­tions, people, har­dwa­re, software.

Stosowanie mode­li pozwa­la znacz­nie lepiej radzić sobie ze zło­żo­no­ścią wiel­kich sys­te­mów jaki­mi są orga­ni­za­cje oraz funk­cjo­nu­ją­ce w nich związ­ki mię­dzy ludź­mi, opro­gra­mo­wa­niem i infra­struk­tu­rą. Fakt, że bada­ne orga­ni­za­cje współ­pra­cu­ją z inny­mi, dodat­ko­wo kom­pli­ku­je tę całość.

Models as com­mu­ni­ca­tions vehicles

A fun­da­men­tal value pro­po­si­tion for models and mode­ling is to faci­li­ta­te a team or com­mu­ni­ty coming to a com­mon under­stan­ding and/or consensus.

Jedną z głów­nych ról mode­li, poza ich ana­li­zą, jest komu­ni­ka­cja: komu­ni­ku­je­my innym człon­kom zespo­łu (tak­że klien­tom) to co zro­zu­mie­li­śmy i to cze­go ocze­ku­je­my. Tak więc mode­le są zarów­no opi­sem rze­czy­wi­sto­ści powsta­łym w toku jej zro­zu­mie­nia, są tak­że opi­sem tego co ma powstać, jeże­li chce­my tę rze­czy­wi­stość stworzyć.

[?]Abstraction deals with the con­cepts of under­stan­ding a sys­tem in a more gene­ral way; said in more ope­ra­tio­nal terms, with abs­trac­tion one eli­mi­na­tes cer­ta­in ele­ments from the defi­ned sco­pe; this may result in intro­du­cing a higher level view­po­int at the expen­se of remo­ving deta­il. A model is con­si­de­red more abs­tract if it encom­pas­ses a bro­ader set of sys­tems and less abs­tract if it is more spe­ci­fic to a sin­gle sys­tem or restric­ted set of systems. [?]

Podstawową rze­czą w ana­li­zie jest redu­ko­wa­nie szcze­gó­łów i uogól­nia­nie. Człowiek nie jest w sta­nie ana­li­zo­wać cze­goś co skła­da się z setek detali.

Model Analytics

Once models are cap­tu­red as seman­tic data vario­us ana­ly­tics can be exe­cu­ted across tho­se models inc­lu­ding model vali­da­tion, sta­ti­stics and metrics. Analytics assi­sts in deci­sion making, moni­to­ring and quali­ty asses­sment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele poję­cio­we i ana­li­tycz­ne słu­żą do zro­zu­mie­nia bada­nej rze­czy­wi­sto­ści. Modele two­rzo­ne (pro­jek­to­wa­nie) słu­żą do testo­wa­nia pomy­słów i podej­mo­wa­nia decy­zji, dalej zaś sta­no­wią opis cech wyma­ga­ne­go roz­wią­za­nia. Modele wyko­ny­wal­ne to inne mode­le ale bazu­ją na mode­lach ana­li­tycz­nych. Poniżej, na bazie MOF ([[Meta Object Facility]]), poka­za­no trzy pozio­my abs­trak­cji (poziom zero­wy to rzeczywistość).

poziomy-abstrakcji

Abstrakcja to uprosz­czo­ny” (pozba­wio­ny zbęd­nych szcze­gó­łów) model okre­ślo­nej rze­czy­wi­sto­ści. Metamodel to mecha­nizm two­rze­nia tej rze­czy­wi­sto­ści w tym tak­że model poję­cio­wy (wię­cej w dal­szej części).

Model (M1) więc jest albo wyni­kiem (pro­duk­tem) ana­li­zy bada­nej rze­czy­wi­sto­ści, albo wyni­kiem (pro­duk­tem) pro­ce­su jej pro­jek­to­wa­nia (pro­jek­to­wa­nia rozwiązania). 

Model Simulation and Execution

Models as data can dri­ve simu­la­tion engi­nes that can assist in both ana­ly­tics and exe­cu­tion of the desi­gns cap­tu­red in models. Simulation assi­sts in the human under­stan­ding of how a mode­led sys­tem will func­tion as well as a way to vali­da­te that models are cor­rect. Models can, in some cases be direc­tly exe­cu­ted ? serving as the ?sour­ce code? for high­le­vel appli­ca­tions that imple­ment pro­ces­ses, data repo­si­to­ries and servi­ce end­po­ints. Model exe­cu­tion pro­vi­des a direct and imme­dia­te path to reali­zing a design with a mini­mum of tech­ni­cal deta­ils being expo­sed. DBMS Schema and pro­cess models are well-known cate­go­ries of (par­tial­ly) exe­cu­ta­ble models.[?]

Modele symu­la­cyj­ne słu­żą do testo­wa­nia hipo­tez i podej­mo­wa­ni decy­zji. Modele wyko­ny­wal­ne, w tym two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wykonywalnymi.

Cztery produkty

Te dwa opi­sa­ne na począt­ku eta­py do ana­li­za sys­te­mo­wa orga­ni­za­cji (potocz­nie ana­li­za biz­ne­so­wa”) oraz imple­men­ta­cja roz­wią­za­nia. Produkty to …

MDA to archi­tek­tu­ra mają­ca trzy pozio­my mode­lo­wa­nia, nazy­wa­ne od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is use­ful to iden­ti­fy par­ti­cu­lar ?lay­ers? of an archi­tec­tu­re with respect to its level of abs­trac­tion. While the­re can be any num­ber of archi­tec­tu­ral lay­ers, a bro­ad cate­go­ri­za­tion of this con­cept is:

  • Business or doma­in models ? models of the actu­al people, pla­ces, things, and laws of a doma­in. The ?instan­ces? of the­se models are ?real things?, not repre­sen­ta­tions of tho­se things in an infor­ma­tion sys­tem. In MDA doma­in models have histo­ri­cal­ly been cal­led a ?CIM? for ?Computation Independent Model?.
  • Logical sys­tem models ? models of the way the com­po­nents of a sys­tem inte­ract with each other, with people and with orga­ni­za­tions to assist an orga­ni­za­tion or com­mu­ni­ty in achie­ving its goals. [model PIM]
  • Implementation models ? the way in which a par­ti­cu­lar sys­tem or sub­sys­tem is imple­men­ted such that it car­ries out its func­tions. Implementation models are typi­cal­ly tied to a par­ti­cu­lar imple­men­ta­tion tech­no­lo­gy or plat­form. [model PSM].

Model CIM opi­su­je ludzi i ich związ­ki, miej­sca, pra­wa rzą­dzą­ce tym wszyst­kim. Ten model opi­su­je real­ną, bada­ną rze­czy­wi­stość cał­ko­wi­cie abs­tra­hu­jąc od wyko­rzy­sty­wa­nych ewen­tu­al­nie posia­da­nych narzę­dzi infor­ma­tycz­nych (w przy­pad­ku start-up’u lub roz­wo­ju orga­ni­za­cji jest to przy­szła jej postać). Nie jest to model jakie­go­kol­wiek opro­gra­mo­wa­nia ani tego jak ono dzia­ła. Produktem tego eta­pu są: mode­le pro­ce­sów biz­ne­so­wych, spe­cy­fi­ka­cja reguł biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć i mode­le pojęciowe.

Model PIM opi­su­je kom­po­nen­ty apli­ka­cji, ich wza­jem­ne inte­rak­cje, logi­kę dzia­ła­nia tych kom­po­nen­tów (ta część logi­ki opi­sa­nej w mode­lu CIM, któ­ra ma być reali­zo­wa­na w apli­ka­cji). Produktem tego eta­pu są mode­le: przy­pad­ków uży­cia (w tym postać nośni­ków danych, moc­ku­p’y ekra­nów), kom­po­nen­tów, wewnętrz­ne struk­tu­ry kom­po­nen­tów (mode­le dzie­dzi­ny z per­spek­ty­wy wzor­ca MVC), inte­rak­cji, inne jeśli konieczne.

Model PSM to model będą­cy pro­jek­tem wyko­naw­czym. Jest to roz­sze­rze­nie mode­lu PIM, uszcze­gó­ło­wie­nie go wraz z dodat­ko­wy­mi ele­men­ta­mi tech­nicz­ny­mi (reali­zu­ją­cy­mi śro­do­wi­sko, bez­pie­czeń­stwo, wyma­ga­ną wydaj­ność itp.). Kod apli­ka­cji to mate­ria­li­za­cja (imple­men­ta­cja) mode­lu PSM. 

Powyższe, to czte­ry pro­duk­ty powsta­ją­ce w tym pro­ce­sie. Dlaczego pisze o dwóch eta­pach? Poniżej wyjaśnienie.

model-driven-architecture-structure

Diagram obra­zu­je produkty/fazy defi­nio­wa­ne jako MDA. Każdy pro­dukt ana­li­zy to okre­ślo­ny zestaw mode­li. Na dia­gra­mie wska­za­no jakich nota­cji uży­wa się w każ­dym z nich (tu bazu­jąc na nota­cjach rodem z OMG). Tu przy­po­mi­nam to co już nie raz pisa­łem: celem jest zro­zu­mie­nie (i two­rze­nia potrzeb­nych w danym przy­pad­ku mode­li) oraz prze­ka­za­ne tej wie­dzy, a nie two­rze­nie jakichś mode­li i doku­men­tów”. Każdy model, jego powsta­nie, ma okre­ślo­ny cel.

Jeszcze sto­sun­ko­wo nie­daw­no w moich pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, wyróż­nia­łem trzy eta­py: ana­li­za orga­ni­za­cji, spe­cy­fi­ka­cja wyma­gań oraz opra­co­wa­nie logi­ki dla dedy­ko­wa­nych kom­po­nen­tów opro­gra­mo­wa­nia. W koń­cu, po kil­ku pro­jek­tach, prze­ko­na­łem się, że ten podział nie dzia­ła”. Dlaczego?

Skoro na eta­pie CIM opra­co­wa­li­śmy mię­dzy inny­mi model logi­ki biz­ne­so­wej dla danej orga­ni­za­cji (w tym regu­ły biz­ne­so­we, słow­nik pojęć) to już ją, te logi­kę, mamy. Okazało się, że ten trze­ci etap” w zasa­dzie jest sztucz­ny, gdyż rze­tel­ne opra­co­wa­nie CIM to tak­że ta” logi­ka. Tu war­to przy­to­czyć diagram:

Swego cza­su pisa­łem tak­że o testo­wa­niu modeli:

W toku dal­szej pra­cy podej­mo­wa­na jest decy­zja o zakre­sie pro­jek­tu. Wskazując to, jakie dzia­ła­nia” ma wspie­rać lub prze­jąć na sie­bie apli­ka­cja (to są wła­śnie przy­pad­ki uży­cia), wska­zu­je­my jaka logi­ka ma być przez tę apli­ka­cję reali­zo­wa­na i kie­dy. Wskazanie zakre­su pro­jek­tu jest więc pierw­szym eta­pem defi­nio­wa­nia logi­ki apli­ka­cji. Jeżeli do tego dodać wie­dzę dzie­dzi­no­wą, np. to któ­re ele­men­ty mogą być współ­dzie­lo­ne a któ­re nie, któ­re powin­ni być cał­ko­wi­cie nie­za­leż­ne itp., powsta­nie tak zwa­ny model dzie­dzi­ny sys­te­mu (logi­ka biz­ne­so­wa i jej struk­tu­ra czy­li archi­tek­tu­ra apli­ka­cji, a kon­kret­nie czę­ści reali­zu­ją­cej logi­kę biznesową).

Na zakończenie

Jak podejść do pla­nów zaku­pu tak­że goto­we­go opro­gra­mo­wa­nia? Czy war­to je pro­jek­to­wać? Oczywiście, że war­to z pro­ste­go powo­du: nie ma zna­cze­nia to, czy przy­szłe opro­gra­mo­wa­nie będzie goto­we czy trze­ba je będzie dopie­ro stwo­rzyć. Ono ma reali­zo­wać taką logi­kę jakiej ocze­ku­je­my. Owszem, jest moż­li­wa decy­zja: sko­ro na ryn­ku nie ma poszu­ki­wa­ne­go pro­duk­tu a stwo­rze­nie dedy­ko­wa­ne­go jest zbyt kosz­tow­ne, to albo rezy­gnu­je­my z zaku­pu albo z okre­ślo­nej logi­ki wewnątrz orga­ni­za­cji. Jednak do pod­ję­cia takiej decy­zji musi­my tę logi­kę znać i mieć udo­ku­men­to­wa­ną (no bo jakoś musi­my ją poka­zać ofe­ren­tom). Ale dostaw­cy opro­gra­mo­wa­nia zawsze ofe­ru­ją ana­li­zę wyma­gań”… To praw­da … A ilu z nich powie, że nie mają Wam nic do zaofe­ro­wa­nia? Ale dedy­ko­wa­ne opro­gra­mo­wa­nie może zapro­jek­to­wać tyl­ko jego wyko­naw­ca”. To dla­cze­go fir­my budow­la­ne nie są dopusz­cza­ne do prac pro­jek­to­wych i architektonicznych?

Dlatego na dia­gra­mie powy­żej, jako moment wybo­ru dostaw­cy opro­gra­mo­wa­nia, wska­za­no ten w któ­rym mamy udo­ku­men­to­wa­ny model logi­ki czy­li PIM. To czy logi­ka taka jest dostęp­na w jakimś pro­duk­cie na ryn­ku czy nie, nie zmie­nia fak­tu, że i tak musi zostać ona opi­sa­na, bez cze­go taki wybór jest nie­moż­li­wy. Czym więc są (czym powin­ny być) wyma­ga­nia na opro­gra­mo­wa­nie? Niestety powin­ny być zwię­złym pro­jek­tem a nie dłu­gą listą cech.

Jeden ana­li­tyk pro­jek­tant mają­cy dobre wspar­cie narzę­dzio­we, jest w sta­nie wyko­nać ana­li­zę i pro­jekt dla dowol­nie dużej fir­my, wystar­czy, że potra­fi two­rzyć abs­trak­cje i zarzą­dzać zło­żo­no­ścią doku­men­ta­cji. Czy kil­ku ana­li­ty­ków zro­bi to nie gorzej i szyb­ciej? Nie znam takie­go przy­pad­ku.… bo im wię­cej osób pro­wa­dzi taką ana­li­zę tym wię­cej pra­cy wyma­ga koor­dy­na­cja i pra­ca nad spój­no­ścią całości.

Na zakoń­cze­nie cytat z pew­nej dyskusji:

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ?the expe­ri­ment? to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team pro­du­ced more than twi­ce the code of the other teams.
3. Our team achie­ved a 75% reduc­tion in cost.
4. Our team achie­ved a 66% reduc­tion in defect rate.
5. Our team was twi­ce as fast (with half the size).
We have sin­ce got­ten more effi­cient and more advan­ced, so I don?t know what the num­bers are now.
(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

Systems Engineering Fundamentals by United States Government

Tak, taką książ­kę moż­na nabyć na Amazonie ;). Streszczenie na stro­nach sprze­daw­cy odda­je dobrze jej treść:

This book pro­vi­des a basic, con­cep­tu­al-level descrip­tion of engi­ne­ering mana­ge­ment disci­pli­nes that rela­te to the deve­lop­ment and life cyc­le mana­ge­ment of a sys­tem. For the non-engi­ne­er it pro­vi­des an ove­rview of how a sys­tem is deve­lo­ped. For the engi­ne­er and pro­ject mana­ger it pro­vi­des a basic fra­me­work for plan­ning and asses­sing sys­tem development.

Ogólnie książ­ka opi­su­je pod­sta­wo­wy kon­cep­cyj­ny etap inży­nie­rii sys­te­mów (i nie nale­ży tego utoż­sa­miać tyl­ko z bran­żą IT). Jest napi­sa­na przy­stęp­nym języ­kiem, adre­so­wa­na głów­nie dla mana­ge­rów (pierw­sze czę­ści) by zapo­znać ich z inży­nie­rią sys­te­mów i sys­te­mo­wym podej­ściem. Kierownikom pro­jek­tów poka­zu­je” czym (ewen­tu­al­nie ;)) zarządzają.

Tu tyl­ko kil­ka słów. Najpierw po raz kolej­ny cytat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

A teraz dia­gram obra­zu­ją­cy pro­ces inży­nie­rii sys­te­mo­wej” na bazie jed­nej z ilu­stra­cji w tej książce:

Proces inżynierii systemowej

Mamy tu trzy klu­czo­we eta­py, powią­za­ne iteracyjnie:

  1. Analiza wyma­gań, cho­dzi tu o wyma­ga­nia biznesowe.
  2. Analiza funk­cjo­nal­no­ści, cho­dzi tu o usta­le­nie do jakich rze­czy» sys­tem jest potrzeb­ny (prze­zna­czo­ny).
  3. Projektowanie czy­li pró­ba opra­co­wa­nia kon­struk­cji, mecha­ni­zmu dzia­ła­nia tego systemu.

Trzeci punkt to wła­śnie klucz do suk­ce­su: zanim zacznie­my kon­stru­owa­nie (np. pisa­nie kodu) war­to opra­co­wać to roz­wią­za­nie «na papie­rze”. To po pierw­sze pozwa­la unik­nąć ogrom­nych kosz­tów roz­po­zna­nia bojem” a po dru­gie daje jako pro­dukt bar­dzo dobrą (na wyso­kim pozio­mie abs­trak­cji ale kom­plet­ną) doku­men­ta­cję dzia­ła­nia systemu.

Niedawno cyto­wa­łem arty­kuł o poraż­ce sys­te­mu e‑border, tym razem innych cytat:

The Home Office had a con­cept, not a well-deve­lo­ped set of requ­ire­ments. Concepts need a reali­ty check; other­wi­se, you could be cha­sing a dre­am! Even tho­ugh the pro­gram ran a pilot to eva­lu­ate the feasi­bi­li­ty of the con­cept, the National Audit Office report (2015) cla­ims that it did not cover all aspects of the solu­tion. Consequently, the pro­gram­me was exe­cu­ted with an unte­sted con­cept and unk­nown requ­ire­ments, which led to dispu­tes. (Źródło: Blueprints Are Not Requirements!)

Jedną z głów­nych przy­czyn poraż­ki było roz­po­czę­cie reali­za­cji pro­jek­tu wyłącz­nie na bazie wizji, bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia tego co na praw­dę ma powstać i w jakich warun­kach”. Patrząc na zobra­zo­wa­ny powy­żej pro­ces inży­nie­rii sys­te­mo­wej wyko­na­no wyłącz­nie pierw­szy etap (wyma­ga­nia biz­ne­so­we) i przy­stą­pio­no do reali­za­cji pro­jek­tu bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia, od razu zaczę­ły powsta­wać pro­to­ty­py… Projekt e‑border zakoń­czył się spek­ta­ku­lar­ną porażką.

Jedną z nota­cji OMG jest SysML. Jest to dedy­ko­wa­ny dla inży­nie­rii sys­te­mów pro­fil UML. Odnosząc się do pro­ce­su inży­nie­rii sys­te­mo­wej powy­żej, powsta­ją w tej nota­cji kolej­ne diagramy:

  1. dia­gram wyma­gań (lub ich specyfikacja),
  2. dia­gram przy­pad­ków uży­cia i ich specyfikacja,
  3. model dzie­dzi­ny (mecha­nizm dzia­ła­nia sys­te­mu: dia­gra­my kom­po­nen­tów, klas i obiek­tów) oraz mode­le zacho­wa­nia sys­te­mu (dia­gra­my sekwen­cji, komu­ni­ka­cji, sce­na­riu­sze przy­pad­ków użycia).

Powyższe to wyma­ga­ne mini­mum dla popraw­ne­go wyspe­cy­fi­ko­wa­nia sys­te­mu zanim powsta­nie choć jeden wiersz kodu czy wykop pod fundament.

Z infor­ma­cji jakie posia­dam, od lat rząd USA nie pono­si takich spek­ta­ku­lar­nych pora­żek pro­jek­to­wych jak euro­pej­skie rzą­dy, jed­nak w przy­pad­ku pro­jek­tów kor­po­ra­cyj­nych już tak różo­wo nie jest :), wpad­ki mają wszystkie:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

Polecam książ­kę 😉

Systems Engineering Fundamentals Kindle Edition by United States Government US Army (Author) (Źródło: Amazon​.com: Systems Engineering Fundamentals eBook: United States Government US Army: Kindle Store)

Analiza systemowa zdalnie

Całkiem nie­daw­no wpadł mi w oczy arty­kuł na temat zdal­ne­go pro­wa­dze­nia ana­li­zy, ostat­ni jego aka­pit brzmi:

Virtual com­mu­ni­ca­tion and faci­li­ta­tion skills will rema­in a key com­pe­ten­cy for BAs for years to come. Stop tor­tu­ring your sta­ke­hol­ders with boring, inef­fec­ti­ve con­fe­ren­ce calls. Find new and cre­ati­ve ways to alle­via­te the com­mon pain points. Please sha­re your vir­tu­al faci­li­ta­tion tips in the com­ments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?).

(w uprosz­cze­niu: zdal­nie pro­wa­dzo­na ana­li­za to klu­czo­wa przy­szła kom­pe­ten­cja ana­li­ty­ków, war­to prze­stać tor­tu­ro­wać ludzi wie­lo­go­dzin­ny­mi nud­ny­mi spo­tka­nia­mi, znajdź inna kre­atyw­ną dro­gę…).

Nie ja pierw­szy odkry­łem, że spo­tka­nia i warsz­ta­ty, to po pierw­sze ogrom­ny koszt (jeden dzień takich warsz­ta­tów to łącz­ny koszt dnió­wek wszyst­kich obec­nych na spo­tka­niu). Po dru­gie, takie zbio­ro­we dys­ku­sje naj­czę­ściej nie­ste­ty są nud­ne i męczą­ce, szyb­ko zmie­nia­ją się w nie­koń­czą­ce się nego­cja­cje, a zatwier­dza­nie nota­tek z takich spo­tkań to kolej­na dro­ga przez mękę (wysła­ne do wszyst­kich obec­nych wra­ca­ją z uwa­ga­mi, te trze­ba nanieść i roze­słać doku­ment jesz­cze raz…).

Tak zwa­ne warsz­ta­ty wyma­gań (tak zwa­ne [[sesje JAD]]) to jed­na z naj­bar­dziej wyna­tu­rzo­nych form tych spo­tkań, bo ich uczest­ni­cy wal­czą jak o ogień by zdo­być zapis sank­cjo­nu­ją­cych ich (nie­raz bar­dzo poboż­ne) życze­nia, każ­dy zgła­sza swo­je pomy­sły na imple­men­ta­cję, coraz to nowe fajer­wer­ki, pseu­do udo­god­nie­nia i oczy­wi­ście upraw­nie­nia dla sie­bie w nowej apli­ka­cji. Złośliwi mawia­ją, że obję­tość spe­cy­fi­ka­cji wyma­gań jest wprost pro­por­cjo­nal­na do cza­su trwa­nia (ilo­ści) takich warsz­ta­tów. Konsultanci zara­bia­ją też pro­por­cjo­nal­nie (koszt dnia pra­cy) a przy­szli użyt­kow­ni­cy zgła­sza­ją coraz to now­sze pomy­sły (z cza­sem coraz bar­dziej z poza zakre­su projektu).

Alternatywą dla tych zja­da­ją­cych czas i pie­nią­dze warsz­ta­tów jest ana­li­za doku­men­tów ope­ra­cyj­nych. Zawierają one z regu­ły ok. 80% wszyst­kich istot­nych infor­ma­cji (orga­ni­za­cji z zasa­dy doku­men­tu­ją istot­ne dla nich rze­czy), w toku pra­cy nad tymi doku­men­ta­mi moż­na wychwy­cić ewen­tu­al­ne bra­ki (to co jest reali­zo­wa­ne nie­for­mal­nie a war­to jed­nak zacząć doku­men­to­wać) oraz nie­po­trzeb­ne już doku­men­ty (zmie­nio­no pro­ce­du­ry a nie wyco­fa­no wzo­rów doku­men­tów). Wszelkie wąt­pli­wo­ści moż­na wyja­śniać tele­fo­nicz­nie lub na krót­kich spo­tka­niach w czte­ry oczy” z kon­kret­ną oso­bą, eks­per­tem z danej dzie­dzi­ny, kie­row­ni­kiem dzia­łu itp. Co cie­ka­we, tą meto­dą moż­na ana­li­zę z góry wyce­nić (licz­ba doku­men­tów do ana­li­zy jest skoń­czo­na więc zakres pra­cy tak­że) i pod­pi­sać z ana­li­ty­kiem umo­wę fixed price”.

Pracując w ten spo­sób uni­ka­my tak­że wszel­kich naci­sków ze stro­ny uczest­ni­ków spo­tkań. W trak­cie typo­wych zbio­ro­wych warsz­ta­tów i burz mózgów, bar­dzo czę­sto nie­ste­ty mają miej­sce, ze stro­ny uczest­ni­ków tych spo­tkań, uda­ne pró­by prze­my­ca­nia dodat­ko­wych nie­uza­sad­nio­nych upraw­nień, obro­na sta­tus quo na swo­im sta­no­wi­sku itp. Badanie doku­men­tów ope­ra­cyj­nych jest wol­ne od tego ryzy­ka. Wyjaśnianiu pod­le­ga­ją wyłącz­nie nie­ści­sło­ści w doku­men­tach. Na ich pod­sta­wie powsta­ją mode­le pro­ce­sów biz­ne­so­wych, wzo­ry doku­men­tów w tych pro­ce­sach itp. Zgłaszanie uwag do powsta­ją­cej doku­men­ta­cji ana­li­tycz­nej jest znacz­nie efek­tyw­niej­sze niż wal­ka o każ­de jej zda­nie w trak­cie warsz­ta­tów, jest tak­że znacz­nie tań­sze, bo tak zwa­ni eks­per­ci dzie­dzi­no­wi klien­ta oraz przy­szli użyt­kow­ni­cy, pra­cu­ją nad swo­imi uwa­ga­mi w chwi­lach wol­nych (nie są to narzu­co­ne ter­mi­ny spo­tkań) i zaj­muj im to znacz­ne mniej cza­su (nie musza z nikim się spie­rać). Dodatkową zale­tą jest pisem­ny ślad po każ­dej zmia­nie, po każ­dym nowym zgło­sze­niu (każ­dy sam spi­su­je swo­je uwa­gi i propozycje).

Owszem, w wie­lu orga­ni­za­cjach jest ogrom­na nie­chęć do takiej pra­cy ale zary­zy­ku­ję tezę, że jedy­nym powo­dem tej nie­chę­ci jest nie­lu­bia­na przez część ludzi odpo­wie­dzial­ność za każ­de swo­je sło­wo. Ta meto­da pra­cy wyklu­cza zbio­ro­wą odpo­wie­dzial­ność za wyni­ki zbio­ro­wo pro­wa­dzo­nej ana­li­zy wymagań.

Tą meto­da pra­cu­je już kil­ka lat, korzy­sta­jąc z elek­tro­nicz­ne­go repo­zy­to­rium doku­men­tów i sys­te­mu obie­gu doku­men­tów i tre­ści (nie korzy­stam z pocz­ty elek­tro­nicz­nej do pro­wa­dze­nia pro­jek­tów z uwa­gi na bała­gan jaki wprowadza!).

Od oko­ło dwóch lat dys­po­nu­ją bar­dzo dobrym narzę­dziem, któ­re pozwa­la na płyn­ną zdal­ną inte­rak­tyw­ną pra­cę, już nie na pozio­mie kolej­nych wer­sji wysy­ła­nej wyni­ko­wej ana­li­zy, a na pozio­mie poje­dyn­czych dia­gra­mów i ich opi­sów. Jest to bez­piecz­ne opro­gra­mo­wa­nie pozwa­la­ją­ce mi, ana­li­ty­ko­wi, zdal­nie pre­zen­to­wać bie­żą­ce efek­ty pra­cy i przyj­mo­wać na bie­żą­co uwa­gi. Narzędzia te opi­sa­łem tu:

Dla utrzy­ma­nia wyso­kiej jako­ści efek­tów pra­cy sto­su­ję spraw­dzo­ne na ryn­ku opro­gra­mo­wa­nie fir­my Visual-Paradigm. W moich pro­jek­tach nie są wyko­rzy­sty­wa­ne do pra­cy żad­ne bez­płat­ne czy spo­łecz­no­ścio­we zaso­by Internetu, gdyż dostaw­cy tych usług nie bio­rą za nie odpo­wie­dzial­no­ści, ogra­ni­cza­ją, a nie raz przej­mu­ją, pra­wa do prze­trzy­my­wa­nych tam doku­men­tów i tre­ści. Z opro­gra­mo­wa­nia fir­my Visual-Paradigm korzy­sta­ją naj­więk­sze kon­cer­ny na świe­cie (lista wybra­nych użyt­kow­ni­ków pakie­tu Visual-Paradigm. Nagrody dla Visual Paradigm). (Źródło: Analiza Biznesowa – narzę­dzia CASE, Visual-Paradigm | Jarosław Żeliński IT-Consulting)

Okazuje się, że moż­na pro­wa­dzić zwin­nie nawet takie ana­li­zy, oszczę­dzić czas człon­ków zespo­łu i innych uczest­ni­ków pro­jek­tu (tak­że inte­re­sa­riu­szy, któ­rzy mogą brać udział w takiej pra­cy). Zalety opi­sa­ne w cyto­wa­nym na począt­ku arty­ku­le mogę tyl­ko potwier­dzić. Owszem nie raz spo­ty­kam się z fir­ma­mi, któ­rych pra­cow­ni­cy pre­fe­ru­ją spo­tka­nia nad pisanie.

Kluczowym powo­dem nie­chę­ci do pisa­nia jest utra­ta moż­li­wo­ści naci­sku na ana­li­ty­ka, w celu pozy­ska­nia korzyst­nych dla sie­bie, a nie koniecz­nie dla spon­so­ra pro­jek­tu, zapi­sów w doku­men­ta­cji. Po dru­gie gru­po­we spo­tka­nia i warsz­ta­ty dra­stycz­nie roz­my­wa­ją odpo­wie­dzial­ność za udzie­la­ne informacje.

Opór przed pisa­niem to naj­czę­ściej nie­chęć do pozo­sta­wia­nia śla­dów po swo­ich uwa­gach i pro­po­zy­cjach. W wie­lu fir­mach i insty­tu­cjach publicz­nych spo­ty­kam się z ogrom­ną nie­chę­cią do takiej pra­cy. Zbiorowe spo­tka­nia i warsz­ta­ty pozo­sta­wia­ją po sobie listę życzeń, pod nią listę obec­no­ści ale nie wia­do­mo kto co zgło­sił, a to pro­wa­dzi do zupeł­ne­go bra­ku odpo­wie­dzial­no­ści uczest­ni­ków takich warsz­ta­tów za treść nota­tek jakie na nich powstają.

Tak, meto­da­mi zbio­ro­wych warsz­ta­tów, powsta­ją z regu­ły doku­men­ty bar­dzo niskiej jako­ści, bar­dzo pra­co­chłon­ne, będą­ce mało mery­to­rycz­nym zgni­łym kom­pro­mi­sem, zawie­ra­ją masę nie­spój­no­ści, są strasz­nie nad­mia­ro­we. Nie raz są to doku­men­ty mają­ce, po ok. roku albo i wię­cej pra­cy! nawet kil­ka tysię­cy stron!… któ­rych z regu­ły już nikt nigdy nie czyta!

Dobra doku­men­ta­cja ana­li­ty­ka biz­ne­so­we­go w tym wyma­ga­nia, to ok. 50 – 100 stron (naj­więk­sze moje pro­jek­ty to ok. 200 str. w tym ponad 50% to dia­gra­my) zawie­ra­ją­ce opis (mode­le) logi­ki dzia­ła­nia orga­ni­za­cji i logi­ki jaką ma reali­zo­wać przy­szłe opro­gra­mo­wa­nie. Szczegóły tech­nicz­ne (w tym model danych!) powi­nien opra­co­wać dopie­ro wyko­naw­ca, na eta­pie ana­li­zy wyma­gań (kon­cep­cja imple­men­ta­cji i wdro­że­nia), nie ma sen­su zbyt wcze­sne żąda­nie” kon­kret­nych tech­no­lo­gii, tech­no­lo­gia jest kon­se­kwen­cją wyma­gań poza-funk­cjo­nal­nych. Przypomnę, że wyma­ga­nia to warun­ki jakie ma speł­nić opro­gra­mo­wa­nie a nie deta­licz­ny pro­jekt. Owszem logi­ka dzia­ła­nia biz­ne­su, w posta­ci mode­lu dzie­dzi­ny, jak naj­bar­dziej powin­na powstać, bo to jest wyma­ga­nie: taki ma być mecha­nizm dzia­ła­nia” zama­wia­nej aplikacji.

Mam świa­do­mość, że nie wszę­dzie zasto­so­wa­nie zdal­nej pra­cy jest moż­li­we ale takich przy­pad­ków jest mało. Podstawą i wystar­cza­ją­cym ele­men­tem jest wola po stro­nie zama­wia­ją­ce­go taką usłu­gę, mam tu na myśli spon­so­ra pro­jek­tu czy­li zarząd fir­my. Zapraszam do kon­tak­tu.

Visual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Pakiet któ­re­go uży­wam (Visual-Paradigm) po ostat­nich zmia­nach ma szan­se stać się w moich oczach ide­ałem :). O jego nowej wer­sji pisa­łem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgod­ny ze spe­cy­fi­ka­cja­mi nota­cji zarzą­dza­nych przez OMG, co jest bar­dzo waż­ne. Tu zwró­cę uwa­gę na kil­ka przy­dat­nych cech.

Moim zda­niem cechą dobre­go pro­jek­tu jest nie tyl­ko dobra meto­dy­ka ale tak­że to czy dys­po­nu­je­my narzę­dzia­mi, któ­re ją wspie­ra­ją. Tymi narzę­dzia­mi są nie tyl­ko nota­cje i sys­te­my poję­cio­we ale tak­że opro­gra­mo­wa­nie CASE, któ­re powin­no speł­niać trzy klu­czo­we warun­ki: wspie­rać (a przy­naj­mniej nie ogra­ni­czać) meto­dy­kę, wyko­ny­wać jak naj­wię­cej żmud­nej pra­cy by dać czas ana­li­ty­ko­wi na pra­cę twór­czą oraz wspie­rać pra­ce gru­po­wą. Pamiętamy, że cały pro­jekt powi­nien być kom­plet­ny, spój­ny i nie­sprzecz­ny, więc tak zwa­ne śla­do­wa­nie i ana­li­zy wza­jem­ne­go wpły­wu ele­men­tów pro­jek­tu są waż­ne ale bar­dzo żmud­ne. To narzę­dzie robi je w tle automatycznie.

Jedną z naj­po­pu­lar­niej­szych i naj­sku­tecz­niej­szych tech­nik ana­li­zy wyma­gań jest mode­lo­wa­nie pro­ce­sów i mapo­wa­nie ich na przy­pad­ki użycia:

Jeżeli z jakie­goś powo­du pre­fe­ro­wa­ne są w pro­jek­cie zwin­ne meto­dy pra­cy też można:

Jak może wyglą­dać ana­li­za fir­my i spe­cy­fi­ko­wa­nie wymagań:)?

Dobre opro­gra­mo­wa­nie powin­no tak­że poma­gać w pra­cy gru­po­wej, bo ana­li­za to zawsze pra­ca w zespo­le z pra­cow­ni­ka­mi (eks­per­ta­mi) orga­ni­za­cji ana­li­zo­wa­nej. Wspólna z klien­tem pra­ca nad modelami:

Opracowanie pro­to­ty­pów ekra­nów, waż­na część wyma­gań na dedy­ko­wa­ne oprogramowanie:

Zarządzanie zada­nia­mi w projekcie:

Pisanie rapor­tów z analiz:

i wie­le innych… 🙂