Formularz subskrypcji artykułów

(jeże­li sub­skry­bu­jesz mój ser­wis zoba­czysz tak­że swój pro­fil, opi­sy tema­tów publi­ka­cji pod formularzem)

Publikacje powsta­ją nie­re­gu­lar­nie: są to jeden, cza­sa­mi dwa tek­sty każ­de­go mie­sią­ca. Zawierają opi­sy wybra­nych pozy­cji lite­ra­tu­ro­wych, opi­sy pro­ble­mów jakie napo­ty­kam w toku audy­tów u klien­tów i ich roz­wią­za­nia, oraz efek­ty prac badawczych.

Listy wysyłkowe – opisy

Na blo­gu gene­ral­nie piszę o ana­li­zie biz­ne­so­wej, sys­te­mo­wej, mode­lach biz­ne­so­wych orga­ni­za­cji i mode­lo­wa­niu sys­te­mów infor­ma­cyj­nych. Jednak nie­któ­re publi­ka­cje mają inny cha­rak­ter, szcze­gó­ły poniżej.

Analiza biznesowa i wymagania

W tej czę­ści uka­zu­ją arty­ku­ły z obsza­ru mode­lo­wa­nia biz­ne­so­we­go, sze­ro­ko poję­tej ana­li­zy biz­ne­so­wej i mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, doku­men­to­wa­nia logi­ki biz­ne­so­wej. Pojawiają się wzmian­ki o nota­cjach BPMN, SBVR, BMM. 

Projektowanie architektury systemów

W tej czę­ści uka­zu­ją się arty­ku­ły z zakre­su inży­nie­rii sys­te­mów, opro­gra­mo­wa­nia, na pozio­mie ana­li­zy i doku­men­to­wa­nia logi­ki dzie­dzi­no­wej sys­te­mów oraz pro­jek­to­wa­nia ich archi­tek­tu­ry. Pojawiają się wzmian­ki o nota­cjach UML i SysML. 

Jestem developerem

Moimi klien­ta­mi są i fir­my małe i bar­dzo duże. Od cza­su do cza­su wysy­łam zapy­ta­nia ofer­to­we od moich klien­tów, tak zwa­ne RFI. Wysyłam je gdy klient zle­ci mi prze­pro­wa­dze­nie tego pro­ce­su, cza­sa­mi też spon­sor nie chce na tym eta­pie wyja­wiać sie­bie jako nabywcy. 

Drugim eta­pem jest zawsze roze­sła­nie kon­kret­nych zapy­tań ofer­to­wych RFP do firm wybra­nych przez spon­so­ra pro­jek­tu spo­śród ofe­ren­tów RFI. 

Jeżeli repre­zen­tu­jesz deve­lo­pe­ra lub inte­gra­to­ra opro­gra­mo­wa­nia, a meto­dy doku­men­to­wa­nia wyma­gań jakie tu opi­su­ję są dla Ciebie zro­zu­mia­łe (zapo­znaj się z przy­kła­da­mi) i akcep­tu­jesz taką for­mę współ­pra­cy, dodaj się do tej listy. Wysyłam na nią tak­że pyta­nia o dostęp­ność ryn­ko­wą okre­ślo­nej technologii. 

Jestem ​„C‑level” menedżerem

Od wie­lu lat moi spon­so­rzy (zarzą­dy firm i dyrek­to­rzy zama­wia­ją­cy moje usłu­gi) mają moje peł­ne wspar­cie na eta­pie wybo­ru dostaw­cy i nego­cjo­wa­nia umów: po opra­co­wa­niu doku­men­ta­cji do pro­jek­tu wspie­ram moich klien­tów pro­wa­dząc tak­że nad­zór autor­ski nad pra­ca­mi dostaw­ców, pro­wa­dzę sta­łą aktu­ali­za­cję powsta­łej dokumentacji. 

Zebrałem ogrom­ne doświad­cze­nie nie tyl­ko w mode­lo­wa­niu biz­ne­so­wym, ana­li­zie i pro­jek­to­wa­niu sys­te­mów, ale tak­że w obsza­rze zarzą­dza­nia, nego­cjo­wa­nia umów, pra­wa autor­skie­go w IT i ochro­ny know-how, któ­rym to doświad­cze­niem tak­że dzie­lę się na tym blogu. 

Nauka i badania

Wybrane arty­ku­ły to pośred­nie wyni­ki moich badań lub pre­prin­ty moich publi­ka­cji nauko­wych, to lista dla osób zain­te­re­so­wa­nych nimi. 

Visual Paradigm

Jestem part­ne­rem mery­to­rycz­nym wolon­ta­riu­szem, pro­du­cen­ta opro­gra­mo­wa­nia Visual Paradigm. Od cza­su do cza­su wysy­łam infor­ma­cje doty­czą­ce nowych wer­sji i ich aktu­ali­za­cji, metod i tech­nik pra­cy z tym opro­gra­mo­wa­niem, uzu­peł­niam tłu­ma­cze­nie pol­skiej wersji.

?Cechy wyróż­nia­ją­ce nowo­cze­sną teo­rię orga­ni­za­cji to jej poję­cio­wo-ana­li­tycz­na pod­sta­wa, jej opar­cie się na danych uzy­ski­wa­nych z badań empi­rycz­nych, ale przede wszyst­kim jej syn­te­ty­zu­ją­cy, inte­gra­cyj­ny cha­rak­ter. Te cechy wyróż­nia­ją­ce są zawar­te w filo­zo­fii, któ­ra akcep­tu­je zało­że­nie, że jedy­nym spo­so­bem bada­nia orga­ni­za­cji jest trak­to­wa­nie ich jako sys­te­mów? (Kostrzewski et al., 1979).

Wprowadzenie

Wbrew ocze­ki­wa­niom, tak zwa­ne zwin­ne meto­dy (agi­le mani­fe­sto, 2001 r.) nie popra­wi­ły jako­ści pro­jek­tów infor­ma­tycz­nych, nie raz zaś spo­wo­do­wa­ły wzrost kosz­tów i wydłu­ża­nie ter­mi­nów, a z uwa­gi na sys­tem roz­li­czeń ​„czas i mate­riał”, nie pozwa­la­ją na pla­no­wa­nie budże­tu pro­jek­tu. Średnie i duże pro­jek­ty IT to nadal w ponad 80% poraż­ki .

Sprawdzają się jed­nak trud­niej­sze, ale znacz­nie sku­tecz­niej­sze, meto­dy zorien­to­wa­ne na mode­lo­wa­nie (ana­li­za sys­te­mo­wa i pro­jek­to­wa­nie) oraz rezy­gna­cja z mono­li­tycz­nej archi­tek­tu­ry sys­te­mów na rzecz archi­tek­tu­ry kom­po­nen­to­wej, wdra­ża­nej meto­da­mi ite­ra­cyj­no-przy­ro­sto­wy­mi . Metody te pozwo­li­ły na pro­jek­to­wa­nie roz­wią­zań infor­ma­tycz­nych i wdra­ża­nie ich w takt zmie­nia­ją­cych sie potrzeb. Pozwalają one tak­że na pla­no­wa­nie kosz­tów i ter­mi­nów już od począt­ku pro­jek­tu . Tak powsta­je tak zwa­na Specyfikacja SWS (Specyfikacja Wymagań Systemowych). 

Model Based Systems Engineering

Modelowanie pole­ga na abs­tra­ho­wa­niu od szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm .

MBSE to skrót od Model Based Systems Engineering (ang. inży­nie­ria sys­te­mów opar­ta na mode­lo­wa­niu) . System to nie tyl­ko ​„sys­tem infor­ma­tycz­ny”, to tak­że cała orga­ni­za­cja, a nawet Państwo. 

Celem tego krót­kie­go arty­ku­łu jest poka­za­nie stan­dar­do­wej ścież­ki ana­li­zy sys­te­mo­wej i popra­wy orga­ni­za­cji, czy­li meto­dy pro­wa­dze­nia ana­li­zy sta­nu obec­ne­go i pro­jek­to­wa­nia roz­wią­zań, opar­tej na ana­li­zie fak­tów i mode­lo­wa­niu , któ­rych celem jest opra­co­wa­nie reko­men­da­cji do ulep­sze­nia orga­ni­za­cji . W 2008 roku OMG opu­bli­ko­wa­ło spe­cy­fi­ka­cję Software & Systems Process Engineering Metamodel (SPEM?), opi­su­ją­cą pro­ces prac nad budo­wą sys­te­mów, jed­nak wyglą­da na to, że pra­ce nad tą spe­cy­fi­ka­cją nie są kon­ty­nu­owa­ne. MBSE jako meto­da, wyda­je się być następ­cą tego pomy­słu (patrz: Survey of Model-Based Systems Engineering (MBSE) Methodologies) .

.

Podstawą pra­cy z mode­la­mi w ana­li­zie sys­te­mo­wej orga­ni­za­cji jest ide­ali­za­cja . Polega ona tym by w toku ana­li­zy i poszu­ki­wa­nia roz­wią­za­nia zapro­jek­to­wać ide­ał (model orga­ni­za­cji w wer­sji ide­al­nej), następ­nie opra­co­wa­niu stu­dium jego wyko­nal­no­ści, uzu­peł­nie­niu ide­ału o pozna­ne ogra­ni­cze­nia i wdro­że­nia tak zapro­jek­to­wa­ne­go sys­te­mu . Studium wyko­nal­no­ści ide­ału to ofer­ty dostaw­ców roz­wią­zań, któ­rych rola jest nie ana­li­za a opra­co­wa­nie kon­cep­cji wdrożenia. . 

Trzy poziomy modelowanie organizacji

Organizacje moż­na opi­sać na trzech klu­czo­wych poziomach:

Enterprise Level – (poziom orga­ni­za­cji) jest to poziom, na któ­rym opi­su­je się i mode­lu­je, stra­te­gie orga­ni­za­cji i jej rolę w oto­cze­niu ryn­ko­wym (ryn­ko­wy łań­cuch war­to­ści). Dotyczy to tak­że insty­tu­cji publicz­nych. Taki opis jako krót­ki doku­ment, jest czę­sto dostęp­ny na stro­nach WWW orga­ni­za­cji w zakład­ce ​„O nas”, w pro­spek­tach emi­syj­nych, sta­tu­tach itp. Model powsta­je w toku for­ma­li­za­cji tego opisu. 

Business Process Level – to środ­ko­wy poziom, na któ­rym two­rzo­ny jest abs­trak­cyj­ny model orga­ni­za­cji w posta­ci tak zwa­ne­go wewnętrz­ne­go łań­cu­cha war­to­ści (pro­ces biz­ne­so­wy). Znakomita więk­szość orga­ni­za­cji nie ma takie­go doku­men­tu lub jest on nie­ak­tu­al­ny. Powodem tego sta­nu rze­czy jest to, że bie­żą­cej pra­cy ope­ra­cyj­nej jest on nie­po­trzeb­ny. Model taki przy­no­si jed­nak ogrom­ne korzy­ści w przy­pad­ku podej­mo­wa­niu decy­zji o zmia­nach. Jest to wte­dy pod­sta­wo­wy mate­riał obni­ża­ją­cy ryzy­ko wszel­kich decy­zji o jakich­kol­wiek zmia­nach orga­ni­za­cyj­nych lub pla­no­wa­nych wdrożeniach.

Implementation Level – to poziom opi­su­ją­cy szcze­gó­ły reali­zo­wa­nej pra­cy i wyko­rzy­sty­wa­nych narzę­dzi. To obszar tre­ści doku­men­tów takich jak: zakre­sy obo­wiąz­ków pra­cow­ni­ków i ich kom­pe­ten­cji, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry, zarzą­dze­nia i regu­la­cje wewnętrz­ne, pod­ręcz­ni­ki uży­wa­nia sprzę­tu i opro­gra­mo­wa­nia oraz wie­le innych doku­men­tów o podob­nych cha­rak­te­rze. Dokumenty te są potrzeb­ne w bie­żą­cej pra­cy, jed­nak szyb­kie i sku­tecz­nie podej­mo­wa­nie decy­zji na ich pod­sta­wie ich tre­ści jest prak­tycz­nie nie­moż­li­we z uwa­gi na ich ilość i szczegółowość. 

Analiza biz­ne­so­wa pole­ga na audy­cie doku­men­tów ist­nie­ją­cych, czy­li tych z pozio­mu pierw­sze­go i trze­cie­go na powyż­szym dia­gra­mie, i opra­co­wa­niu na ich pod­sta­wie Modelu Procesów Biznesowych (środ­ko­wa war­stwa). Model ten to mecha­nizm funk­cjo­no­wa­nia orga­ni­za­cji, jej abs­trak­cyj­ny obraz, pozwa­la­ją­cy zapla­no­wać przy­szłe wdro­że­nie i prze­wi­dzieć jego efekty.

W toku ana­li­zy ma czę­sto miej­sce stan­da­ry­za­cja opi­su dzia­ła­nia i stra­te­gii. Jej celem jest for­ma­li­za­cja opi­su orga­ni­za­cji, bez cze­go nie jest moż­li­we doko­na­nie jakich­kol­wiek porów­nań np. z kon­ku­ren­cją, wyzna­cze­nie celów biz­ne­so­wych i wska­za­nie w orga­ni­za­cji miejsc mają­cych wpływ na te cele. 

Enterprise Level – Model biznesowy organizacji 

Strategia orga­ni­za­cji i jej rola w oto­cze­niu ryn­ko­wym są klu­czo­we dla zro­zu­mie­nia osią­ga­nych przez orga­ni­za­cję efek­tów. Mimo tego, że więk­szość orga­ni­za­cji dys­po­nu­je takim opi­sem, są one wyko­na­ne nie­for­mal­ny­mi meto­da­mi, tak róż­ny­mi, że jakie­kol­wiek porów­na­nie dwóch orga­ni­za­cji lub tej samej na prze­strze­ni lat jest prak­tycz­nie nie­moż­li­we. Dlatego opra­co­wa­no stan­dard zwa­ny Model Motywacji Biznesowej .

Standard ten sta­no­wi sobą pewien okre­ślo­ny sys­tem klu­czo­wych pojęć i związ­ków mię­dzy nimi. Jego celem jest stan­da­ry­za­cja pojęć takich jak: misja i wizja, stra­te­gia i tak­ty­ka, wewnętrz­ne i zewnętrz­ne czyn­ni­ki wpły­wu, cele i mier­ni­ki osią­ga­nia celu. 

Business Process Level – Model procesów biznesowych organizacji

Jest to model pozio­mu Business Process Level. To zna­czy, że nie ma tu miej­sca na szcze­gó­ły opi­sa­ne w doku­men­tach na pozio­mie Implementation Level. Model pro­ce­sów biz­ne­so­wych ma (powi­nien mieć) jedy­nie odno­śni­ki do szcze­gó­łów trze­ciej war­stwy, w szcze­gól­no­ści do pro­ce­dur, repre­zen­to­wa­nych na tym pozio­mie w posta­ci (abs­trak­cyj­nych) nazwa­nych aktywności.

Jednym z naj­bar­dziej zna­nych wzor­ców opi­su tego pozio­mu jest tak zwa­ny Wewnętrzny Łańcuch Wartości M. Portera, jest on nadal pod­sta­wo­wą wie­dzą każ­de­go absol­wen­ta stu­diów MBA. Model ten zakła­da podział pro­ce­sów na wspie­ra­ją­ce (admi­ni­stra­cja) i ope­ra­cyj­ne. Konkurencyjność i spraw­ność ope­ra­cyj­na ma dwa obsza­ry: w obsza­rze admi­ni­stra­cji, ści­śle regu­lo­wa­nym pra­wem, w zasa­dzie kon­ku­ru­je­my kosz­ta­mi, ale w obsza­rze ope­ra­cyj­nym, dają­cym znacz­nie więk­szą swo­bo­dę jego kształ­to­wa­nia, kon­ku­ren­cyj­ność to efekt spraw­no­ści orga­ni­za­cji, archi­tek­tu­ry pro­ce­sów biz­ne­so­wych i informacji. 

Z ww. powo­du w toku ana­li­zy i mode­lo­wa­nia sku­pia­my sie na obsza­rze ope­ra­cyj­nym, gdyż obszar wspar­cia admi­ni­stra­cyj­ne­go, z powo­du ści­słej zależ­no­ści od pra­wa, moż­na wes­przeć stan­dar­do­wym opro­gra­mo­wa­niem, łatwo dostęp­nym na ryn­ku. Ewentualne dedy­ko­wa­ne modu­ły są pro­jek­to­wa­ne wła­śnie dla obsza­ru ope­ra­cyj­ne­go, bo to tu wystę­pu­ją róż­ni­ce mię­dzy orga­ni­za­cja­mi i tu powsta­je prze­wa­ga kon­ku­ren­cyj­na (jeże­li doty­czy to orga­ni­za­cji kon­ku­ru­ją­cej na ryn­ku). Kluczem na tym eta­pie jest wska­za­nie miejsc do uspraw­nie­nia i opra­co­wa­nie roz­wią­za­nia. Próby kom­plek­so­we­go wdra­ża­na ​„jed­ne­go sys­te­mu do wszyst­kie­go” naj­czę­ściej koń­czą się nie­ste­ty źle (kom­plek­so­we wdro­że­nia mono­li­tów ERPII mają bar­dzo złą reno­mę). Model Portera odno­si sie jed­na­ko­wym stop­niu do firm ryn­ko­wych jak i do insty­tu­cji publicznych. 

Więcej w arty­ku­le Analiza orga­ni­za­cji i opra­co­wa­nie Mapy Procesów.

Implementation Level – wdrożenie

Ten poziom i jego doku­men­ta­cja, to tak na praw­dę efekt pra­cy ope­ra­cyj­nej i pro­dukt wdro­że­nia norm jako­ści i pro­ce­dur, stra­te­gii zatrud­nie­nia, sys­te­mu infor­ma­tycz­ne­go itp. (patrz Operational Resources w poprzed­nim pod­roz­dzia­le). Tę doku­men­ta­cję two­rzą dostaw­cy roz­wią­zań oraz wewnętrz­ne służ­by admi­ni­stra­cji. Jako, że ona w róż­nych for­mach ist­nie­je w każ­dej fir­mie, sta­no­wi bazo­wy mate­riał źró­dło­wy w ana­li­zach sta­nu obec­ne­go. To dla­te­go ana­li­zę orga­ni­za­cji moż­na prze­pro­wa­dzić prak­tycz­nie w 100% bez kło­po­tli­wych i kosz­tow­nych spo­tkań warsz­ta­to­wych z pra­cow­ni­ka­mi ana­li­zo­wa­ne­go podmiotu. 

Rozwiązania informatyczne i wymagania

Niestety same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych to wyłącz­nie idea jego powsta­nia (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su, dają­cą ochro­nę w posta­ci peł­ne­go pra­wa do powsta­łe­go pro­duk­tu, uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt jego kon­struk­cji, struk­tur danych i mecha­ni­zmu dzia­ła­nia, sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we.

Obecne cza­sy to wszech­obec­na cyfry­za­cja. Dlatego zna­ko­mi­ta więk­szość roz­wią­zań wspie­ra­ją­cych dzia­ła­nia orga­ni­za­cji to sys­te­my infor­ma­cyj­ne wspie­ra­ją­ce pro­ce­sy biznesowe. 

Powyżej poka­za­no (zna­ny od lat 90-tych ubie­głe­go wie­ku) model archi­tek­tu­ry sys­te­mów infor­ma­cyj­nych zorien­to­wa­nej na usłu­gi apli­ka­cyj­ne. Pokazuje on związ­ki pomię­dzy pro­ce­sa­mi biz­ne­so­wy­mi a sys­te­ma­mi infor­ma­cyj­ny­mi, któ­rych doce­lo­wo w każ­dej orga­ni­za­cji jest wię­cej niż jeden. 

Systemy infor­ma­cyj­ne tak­że mode­lu­je­my na kil­ku poziomach: 

1. Business Services – jako nazwa­ne usłu­gi biz­ne­so­we wyma­ga­ją­ce okre­ślo­nych usług apli­ka­cyj­nych, wspie­ra­ją­cych okre­ślo­ne aktyw­no­ści w pro­ce­sach, usłu­gi apli­ka­cyj­ne mode­lu­je­my jako przy­pad­ki uży­cia apli­ka­cji (są to wyma­ga­nia na rozwiązanie),
2. Components – jako nazwa­ne i wyspe­cy­fi­ko­wa­ne kom­po­nen­ty apli­ka­cyj­ne wraz z ich inte­gra­cją (jest to opis rozwiązania),
3. Operational Resources – jako model opi­su­ją­cy fak­tycz­ne ich wdro­że­nie i roz­lo­ko­wa­nie (jest to doku­men­ta­cja wdro­żo­ne­go systemu). 

Kluczowymi sto­so­wa­ny­mi stan­dar­da­mi nota­cyj­ny­mi są tu BPMN, UML, SBVR . Więcej w arty­ku­le Analiza i opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie.

Opracowanie spe­cy­fi­ka­cji wyma­gań (mode­li) nie powin­no nigdy w obec­nych cza­sach trwać dłu­żej niż kwar­tał, co ozna­cza, że im więk­szy pro­jekt tym bar­dziej spe­cy­fi­ka­cja wyma­gań jest poli­ty­ką (archi­tek­tu­rą) niż deta­licz­nym opi­sem. Detale są spe­cy­fi­ko­wa­ne już w toku wdro­że­nia w toku nad­zo­ru autor­skie­go, zgo­dzie z poli­ty­ką budo­wy i wdra­ża­nia sys­te­mu (archi­tek­tu­rą). Wycena reali­za­cji nie powin­na spra­wić kło­po­tu, żad­nej doświad­czo­nej, zna­ją­cej wzor­ce archi­tek­to­nicz­ne, fir­mie ofru­ją­cej oprogramowanie. 

Praca z dostawcami rozwiązań

Praktycznie zawsze pada pyta­nie: a co jeże­li dostaw­ca też robi ana­li­zę przed­wdro­że­nio­wą? Otóż tu już jej nie robi bo ją dosta­je. Z uwa­gi na ryzy­ko pro­jek­tu i poten­cjal­ny kon­flikt inte­re­su, Dostawca z zasa­dy nie powi­nien być auto­rem wyma­gań (pro­jek­tu rozwiązania). 

Dostawca musi opra­co­wać pro­po­no­wa­ną przez sie­bie Koncepcję Wdrożenia ofe­ro­wa­ne­go pro­duk­tu, w odpo­wie­dzi na wyma­ga­nia wyra­żo­ne w posta­ci mode­li pro­ce­sów biz­ne­so­wych, struk­tur doku­men­tów i reguł biz­ne­so­wych (Model Biznesowy Organizacji). Z uwa­gi na to, że pro­jek­ty takie zawsze reali­zo­wa­ne są meto­dą ite­ra­cy­no-przy­ro­sto­wą, w toku pro­jek­tu ma miej­sce sta­ła współ­pra­ca: Dostawca roz­wią­za­nia żąda kolej­nych deta­licz­nych infor­ma­cji o tym jak dzia­ła fir­ma Zamawiającego, Zamawiający, z moją pomo­cą (nad­zór autor­ski), odpo­wia­da odsy­ła­jąc sta­le uzu­peł­nia­ny Model Biznesowy. Dostawca doku­men­tu­je kolej­ne eta­py pro­wa­dzo­ne­go wdro­że­nia (aktu­ali­zu­je Koncepcję Wdrożenia, któ­ra sta­je się doku­men­ta­cją tego wdro­że­nia) a ja je (te doku­men­ty) wery­fi­ku­ję, i tak aż do zakoń­cze­nia wdrożenia. 

Na koniec wdro­że­nia Zamawiający dys­po­nu­je dwo­ma aktu­al­ny­mi doku­men­ta­mi: Model Biznesowy (środ­ko­wa war­stwa opi­su orga­ni­za­cji) i Dokumentacja Wdrożenia (opi­sa­ny wyżej Poziom Implementacji).

Podsumowanie

Każdy pro­jekt zwią­za­ny z reor­ga­ni­za­cją i/lub wdra­ża­niem nowe­go opro­gra­mo­wa­nia (zmian, roz­bu­do­wy) moż­na więc prze­pro­wa­dzić meto­dą ana­li­zy orga­ni­za­cji i jej mode­lo­wa­nia na z góry usta­lo­nym pozio­mie szcze­gó­ło­wo­ści. Modele te są ści­śle zin­te­gro­wa­ne z sobą, a całość ma cha­rak­ter opi­su ​„od ogó­łu do szczegółu”. 

Podejście to gwa­ran­tu­je spój­ność, kom­plet­no­ści i nie­sprzecz­ność opi­su na każ­dym eta­pie pro­jek­tu. Dzięki temu mini­ma­li­zu­je­my ryzy­ko nie­uda­ne­go wdro­że­nia a całość trwa krót­ko (żaden etap ana­li­zy nie powi­nien trwać dłu­żej niż kwar­tał!). Prosty ale obra­zo­wy przy­kład opi­sa­łem TUTAJ.

Całość lite­ra­tu­ra przed­mio­tu opi­su­je od wie­lu lat, meto­dy te są sta­le dosko­na­lo­ne. Poniżej pro­ces two­rze­nia opro­gra­mo­wa­nia jako pro­jek­to­wa­nie systemu: 

Przypadki uży­cia (use case) to wynik opi­sa­nej na począt­ku ana­li­zy biz­ne­so­wej (orga­ni­za­cja to tak­że sys­tem) i wyod­ręb­nie­nia celów biz­ne­so­wych. Mamy rok 2021 i ogrom­ny wybór dostęp­ne­go, goto­we­go opro­gra­mo­wa­nia wyma­ga­ją­ce­go jedy­nie wła­ści­we­go dobo­ru i inte­gra­cji. Tak opi­sa­ny wyżej sys­tem to struk­tu­ra i zacho­wa­nie się dobra­nych kom­po­nen­tów, nie koniecz­nie jest to ​„pisa­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia od zera”, bo to ma miej­sce coraz rza­dziej i doty­czy ewen­tu­al­nie 10 – 15% dedy­ko­wa­nych potrzeb nie­któ­rych firm. 

Obecne na ryn­ku sys­te­my wspie­ra­ją­ce ana­li­zy i pro­jek­to­wa­nie (CASE: Computer Aided System Engineering) oraz wzor­ce archi­tek­to­nicz­ne i narzę­dzia infor­ma­tycz­ne, pozwa­la­ją pro­wa­dzić ana­li­zy i mode­lo­wa­nie eta­pa­mi trwa­ją­cy­mi poje­dyn­cze tygo­dnie a nie lata. Iteracyjno-przy­ro­stwe meto­dy dostar­cza­nia opro­gra­mo­wa­nia pozwa­la­ją wdra­żać nowo­cze­sne roz­wią­za­nia w okre­sach kwar­tal­nych a nie lat. 

Poniżej pro­sty przy­kład pro­duk­tu takiej pracy:

[down­lo­ad id=„28199”]

Sprawdź aktu­al­ne kosz­ty takie­go pro­jek­tu: KOSZT.

Źródła