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

Lektura na Nowy Rok… Co praw­da wyda­na w 2007 roku, ale wła­śnie sobie o niej przypomniałem.. 

Ta książ­ka Yourdona leży u mnie na pół­ce nie­mal­że od dnia jej wyda­nia, gdy ją przy­pad­kiem upo­lo­wa­łem, zaraz po jej uka­za­niu się w księ­gar­niach. Napisanie o niej odkła­dam od lat, bo prak­tycz­nie nie ma tam obraz­ków UML, opi­sów wzor­ców itp.. Od jej prze­czy­ta­nia mówię sobie: jutro o niej napi­szę… i to trwa­ło do tego momentu.

To książ­ka w cało­ści napi­sa­na pro­zą, bez obraz­ków, w któ­rej autor dzie­li sie swo­imi prze­my­śle­nia­mi na temat archi­tek­tu­ry sys­te­mów, ich pro­jek­to­wa­nia i tym co z tego wynika. 

Bardzo cie­ka­wie pisze o tym, czym jest zło­żo­ność opro­gra­mo­wa­nia, o tym, że zło­żo­ność sys­te­mu to sto­pień kom­pli­ka­cji mode­lu dzie­dzi­no­we­go a nie całe­go sys­te­mu”. Typowy sys­tem (tu apli­ka­cja dla biz­ne­su) skła­da się w ponad 90% z biblio­tek, z któ­rych nie­wąt­pli­wie trze­ba umieć zbu­do­wać śro­do­wi­sko apli­ka­cji, jed­nak to nie one decy­du­ją o tym do cze­go słu­ży ten sys­tem i czy w ogó­le komu­kol­wiek do cze­goś słu­ży… Z biblio­tek, na któ­re nie mamy wpły­wu, ale musi­my (chce­my) ich użyć. 

Jaki to jest skom­pli­ko­wa­ny sys­tem? Ile ma klas/komponentów by uznać go za zło­żo­ny? Gdzie jest gra­ni­ca zło­żo­no­ści małej i dużej? Czym jest archi­tek­tu­ra i po co ona nam? O tym tu przeczytacie.

Polecam tę książ­kę każ­de­mu, kto ma ambi­cję pro­jek­to­wać archi­tek­tu­rę sys­te­mów biz­ne­so­wych. Uczy poko­ry. Zwracam tu uwa­gę, że oso­ba mówią­ca o sobie ana­li­tyk biz­ne­so­wy”, któ­re­go pro­duk­tem pra­cy mają być wyma­ga­nia na opro­gra­mo­wa­nie”, to nie zbie­racz nota­tek a pro­jek­tant . Albo niech zmie­ni zawód.. 

Yourdon, E., & Bloch, J. (2007). Marsz ku klę­sce: porad­nik dla pro­jek­tan­ta sys­te­mów. Wydawnictwa Naukowo-Techniczne. https://​lubi​my​czy​tac​.pl/​k​s​i​a​z​k​a​/​1​5​9​1​8​0​/​m​a​r​s​z​-​k​u​-​k​l​e​sce
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049

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”). 

Czytaj dalej… Opis wyma­gań z uży­ciem Gherkin – czy­li duuużo kor­ni­szo­nów…”

Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w ??doku­men­ta­cji wyma­gań?. Jakim wyma­ga­niem jest ??zgod­ność z obo­wią­zu­ją­cym pra­wem?? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów ? a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z nich jest egze­kwo­wa­nie usta­lo­nych zasad.

Czytaj dalej… Odpowiedzialność admi­ni­stra­to­ra sys­te­mu”

Diagram aktywności – 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. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia kodu (dla Platform Independent Model). 

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.

Czytaj dalej… Diagram aktyw­no­ści – kie­dy”

Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzy­kiem to pro­za życia kie­row­ni­ków pro­jek­tów. Z jed­nej stro­ny doświad­czo­ny kie­row­nik pro­jek­tu powi­nien dosko­na­le radzić sobie z ryzy­kiem, z dru­giej zaś stro­ny prak­ty­ka pro­jek­tów poka­zu­je, że efek­ty są nie­ste­ty sła­be bo ok. 90% IT na świe­cie ma prze­kro­co­zne budże­ty i ter­mi­ny .

Jednym z cie­kaw­szych narzę­dzi zarzą­dza­nia ryzy­kiem jest mało popu­lar­ny tak zwa­ny sto­żek nie­pew­no­ści. Ogólna zasa­da pla­no­wa­nia mówi, że im bar­dziej w przy­szłość wybie­ga­ją pro­gno­zy tym bar­dziej są one nie­pew­ne. Jest nie tyl­ko intu­icyj­ne ale i udo­wod­nio­ne mate­ma­tycz­nie. Stożek nie­pew­no­ści to wykres poka­zu­ją­cy zwią­zek pomię­dzy kosz­ta­mi pro­jek­tu a posia­da­ną wie­dzą na eta­pie ini­cja­cji pro­jek­tu np. imple­men­ta­cji (dostar­cze­nia) opro­gra­mo­wa­nia. Poniżej jeden z przy­kła­dów jego zobrazowania:

Stożek nie­pew­no­ści

Stożek ten (sto­żek nie­pew­no­ści) to narzę­dzie empi­rycz­ne (!), obra­zu­je spo­dzie­wa­ne kon­se­kwen­cje jaki­mi są kosz­ty, gene­ro­wa­ne przez nie­pew­ność (przed­wcze­sne, nie­uda­ne pro­to­ty­py, wpro­wa­dza­nie zmian po przed­wcze­snym roz­po­czę­ciu prac imple­men­ta­cyj­nych i wdro­że­nio­wych, itp.). 

Na powyż­szym wykre­sie, czer­wo­na linia obra­zu­je kosz­ty eta­pu prac bez ana­liz i pro­jek­to­wa­nia (agi­le) a zie­lo­na kosz­ty prac poprze­dzo­nych ana­li­za­mi i pro­jek­to­wa­niem. Linie te spo­ty­ka­ją w punk­cie, w któ­rym wie­dza o osta­tecz­nej wer­sji pro­duk­tu jest już taka sama. Punkty ozna­czo­ne dia­men­tem” to kamie­nie milo­we pro­jek­tu. Wartość kosz­tu odnie­sie­nia 1.0 to sytu­acja, w któ­rej w momen­cie roz­po­czę­cia pro­jek­tu nie było­by żad­nych nie­wia­do­mych (ryzy­ko zakre­su pro­jek­tu = zero). Całkowity koszt pro­jek­tu to pola pod krzy­wy­mi (pomię­dzy daną krzy­wą a pozio­mem zero lewej osi). Praktyka poka­zu­je więc, że brak pla­no­wa­nia i pro­jek­to­wa­nia pod­no­si kosz­ty pro­jek­tu śred­nio czterokrotnie.

W przy­pad­ku apli­ka­cji będą­cej mono­li­tem wykres repre­zen­tu­je cały pro­jekt („water fall”, meto­da wodo­spa­do­wa), czy­li pro­jekt trwa­ją­cy nie raz kil­ka lat. Prawdopodobieństwo, że reali­za­cja deta­licz­nie zapla­no­wa­ne­go np. na 5 lat pro­jek­tu będzie wyma­ga­ła korek­ty pla­nów lub wpro­wa­dza­nia zmian do pro­jek­tu, gra­ni­czy obec­nie z pewnością:

W przy­pad­ku zasto­so­wa­nia metod obiek­to­wych, zorien­to­wa­nych na komponenty/mikroserwisy, wykres Stożek nie­pew­no­ści repre­zen­tu­je dostar­cze­nie jed­nej usłu­gi apli­ka­cyj­nej (przy­pa­dek uży­cia, imple­men­to­wa­nej jako kom­po­nent, patrz tak­że ite­ra­cyj­no-przy­ro­sto­we dostar­cza­nie opro­gra­mo­wa­nia jako kolej­nych usług apli­ka­cyj­nych, MVP: Minimum Value Product). Implementacja jed­nej takiej usłu­gi z regu­ły mie­ści się w jed­nym kwar­ta­le. W efek­cie prak­tycz­nie eli­mi­nu­je­my skut­ki nie­pew­no­ści, pla­nu­jąc reali­za­cję pro­jek­tu tak, by żad­ne pla­ny nie wybie­ga­ły zbyt dale­ko w przy­szłość (z regu­ły gra­ni­ca jest rok budże­to­wy). Jest to moż­li­we dzię­ki odej­ściu od mono­li­tycz­nej archi­tek­tu­ry apli­ka­cji. Realizacja pro­jek­tu wytwa­rza­nia apli­ka­cji o kom­po­nen­to­wej (np. mikro­ser­wi­sy) archi­tek­tu­rze wyglą­da jak poniżej:

Warto tu zwró­cić uwa­gę, że apli­ka­cje zbu­do­wa­ne w opar­ciu o jed­ną i cen­tral­ną bazę danych w mode­lu rela­cyj­nym (RDBMS) są wła­śnie typo­wy­mi mono­li­ta­mi, np. więk­szość powszech­nie zna­nych dużych sys­te­mów ERP. Duże sys­te­my rela­cyj­nych baz danych są z tego powo­du od daw­na krytykowane:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

W tym przy­pad­ku ofer­ty (obiet­ni­ce) dostaw­ców tego typu sys­te­mów (mono­li­ty) to zie­lo­na linia na dia­gra­mie Stożek nie­pew­no­ści, a fak­tycz­ne kosz­ty tych wdro­żeń, pole­ga­ją­ce na bie­żą­cej, pro­wa­dzo­nej ad-hoc adap­ta­cji, to linia czer­wo­na, co potwier­dza­ją sta­ty­sty­ki .

Źródła

Little, T. (2006). Schedule esti­ma­tion and uncer­ta­in­ty sur­ro­un­ding the cone of uncer­ta­in­ty. Software, IEEE, 23, 48 – 54. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​6​.82
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. Prentice Hall.

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ął.

Czytaj dalej… Mało któ­ry dewe­lo­per uży­wa UMLa zgod­nie ze spe­cy­fi­ka­cją…”