Business Analysis – diagram klas UML i bazy danych

pyta­nie o dia­gram klas jako repre­zen­ta­cja [rela­cyj­nej] bazy danych to świa­dec­two kom­plet­ne­go nie­zro­zu­mie­nia ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo (żeby nie powie­dzieć igno­ran­cji). Jest to tak­że świa­dec­two bra­ku zna­jo­mo­ści lite­ra­tu­ry, bo fak­tycz­nie, jak zauwa­ża autor powyż­szych słów, nie ma ofi­cjal­nych mate­ria­łów (orga­ni­za­cja stan­da­ry­zu­ją­ca) mówią­cych o mode­lo­wa­niu danych dia­gra­ma­mi klas nota­cji UML. Do mode­lo­wa­nia danych uży­wa­my nota­cji ERD (ang. [[Entity Relationship Diagram]], dia­gram związ­ków encji).

Czytaj dalej Business Analysis – diagram klas UML i bazy danych

Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Tak więc przy­pad­ka­mi uży­cia opi­su­je­my abs­trak­cję jaką jest [[Model Dziedziny Systemu]]. Są one wte­dy pro­ste, zawie­ra­ją sce­na­riusz, któ­ry w skró­cie ma postać: aktor ini­cju­je usłu­gę, sys­tem pre­zen­tu­je for­mu­larz do wypeł­nie­nia, aktor wypeł­nia go i potwier­dza, sys­tem potwier­dza ode­bra­nie danych i poka­zu­je wynik swo­jej pra­cy (lub komu­ni­ka­ty o błę­dach). Tu sku­pia­my się na opi­sie tego jakie usłu­gi są wyma­ga­ne od sys­te­mu. Kolejny etap to kom­pli­ko­wa­nie” każ­de­go sce­na­riu­sza w posta­ci pro­jek­to­wa­nia, dla każ­de­go przy­pad­ku uży­cia, róż­ne­go rodza­ju wizar­dów lub wpro­wa­dza­my ogra­ni­cze­nia zwią­za­ne z upraw­nie­nia­mi użyt­kow­ni­ków. Ten etap to pra­ca pro­jek­tan­tów UX i gra­fi­ków, spe­cja­li­stów od ergo­no­mii itp. 

Czytaj dalej Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Wymagania pozafunkcjonane czyli jaka architektura

Jak wspo­mnia­łem, wie­lu dostaw­ców opro­gra­mo­wa­nia jak Rejtan, bro­ni się przed ujaw­nia­niem archi­tek­tu­ry, swo­ich pro­duk­tów. Głównym powo­dem jest zapo­bie­ga­nie przed­wcze­sne­go wyja­wie­nia opi­sa­nych wyżej wad sys­te­mów z gru­bym klien­tem (znacz­nie rza­dziej spek­ta­ku­lar­ny pomysł, w koń­cu mamy jed­nak jakieś stan­dar­dy). Przypadki, w któ­rych zakup sys­te­mu był rela­tyw­nie niski ale koszt utrzy­ma­nia, roz­wo­ju i dosto­so­wa­nia nie raz wręcz ogrom­ny, to z regu­ły wła­śnie zakup sys­te­mu w tej kosz­tow­nej architekturze.
Jak sta­rać się tego uni­kać? Na eta­pie defi­nio­wa­nia wyma­gań poza-funk­cjo­nal­nych, żądać takich cech jak opi­sa­ne powy­żej czy­li wła­snie: dostęp do cało­ści przez prze­glą­dar­kę WWW, niskie wyma­ga­nia na łącza przy zdal­nej pra­cy i pra­cy w sie­ci roz­pro­szo­nej tery­to­rial­nie, oddzie­le­nie kom­po­nen­tu z wła­sną dedy­ko­wa­ną logi­ką biznesową.

Czytaj dalej Wymagania pozafunkcjonane czyli jaka architektura

Kolejna wpadka IT: obiektowość

obiek­to­wość jako pana­ceum na pro­ble­my pro­gra­mi­stów i pro­gra­mo­wa­nia to w moich oczach jak naj­bar­dziej wpad­ka. Obiektowość jako sku­tecz­ne meto­da ana­li­zy świa­ta” i jego mode­lo­wa­nia to suk­ces, ale to tyl­ko kon­ty­nu­acja roz­wo­ju ogól­nej teo­rii sys­te­mów. Obiektowość dała tej teo­rii bar­dzo dobre narzę­dzie – obiek­to­we meto­dy mode­lo­wa­nia. Specyfikowanie wyma­gań w posta­ci czar­nej skrzyn­ki się nie spraw­dza, sta­ty­sty­ki pora­żek pro­jek­tów są nie­zmien­ne od lat. Specyfikacja wyma­gań w posta­ci pro­jek­tu jest nie­mal­że dosko­na­łe (ale tyl­ko tak jak dosko­na­ły jest projekt). 

Czytaj dalej Kolejna wpadka IT: obiektowość

Wyznaczaj cele w modelu …

Poszukiwanie Świętego Graala realizacji celów osobistych albo projektów trwa. Od czasu do czasu pojawiają się "magiczne" metody na sukces. Jedna z regularnie odgrzewanych jest SMART i jej odmiany. Poniżej kolejna…

Czytaj dalej Wyznaczaj cele w modelu …

Jak połączyć prywatne z firmowym w jednym urządzeniu?

Tak więc bez­pie­czeń­stwo powin­no być raczej ele­men­tem wyma­gań w posta­ci ocze­ki­wa­ny efekt” a nie jak je zapew­nić”. Nie rozu­miem dla­cze­go tak wie­lu ana­li­ty­ków i dzia­ły IT wzbra­nia­ją się przed uzna­niem, że opro­gra­mo­wa­nie powin­no być dostęp­ne na dowol­nym urzą­dze­niu mobil­nym i że nie powin­no pozwa­lać na…, i tu okre­ślo­ne ogra­ni­cze­nia. Moim zda­niem bez­pie­czeń­stwo powin­no być defi­nio­wa­ne (wyma­ga­nia) poprzez ryzy­ka, któ­rych chce­my unik­nąć w okre­ślo­nym, biz­ne­so­wo ocze­ki­wa­nym (a nawet zasta­nym) śro­do­wi­sku, a nie poprzez narzu­ca­nie kon­kret­ne­go spo­so­bu i tech­no­lo­gii, w szcze­gól­no­ści przy­mu­su korzy­sta­nia z kon­kret­ne­go sprzę­tu czy oprogramowania. 

Czytaj dalej Jak połączyć prywatne z firmowym w jednym urządzeniu?

Tak zwane projekty internetowe

Projektując inter­ne­to­wy sys­tem obsłu­gi klien­ta tak na praw­dę roz­wią­zu­je­my dwa zupeł­nie odręb­ne pro­ble­my: musi­my zastą­pić sprze­daw­cę naszą nową stro­ną WWW oraz obsłu­żyć zda­rze­nia, któ­re wyge­ne­ru­je nasz (tu wir­tu­al­ny) sprzedawca.

Mamy więc nie­ja­ko dwa odręb­ne pro­jek­ty: opra­co­wa­nie por­ta­lu, i to jest robo­ta dla agen­cji inte­rak­tyw­nej. Drugi, to zapro­jek­to­wa­nie i wytwo­rze­nie (albo opi­sa­nie, zakup goto­we­go na ryn­ku i zin­te­gro­wa­nie) czy­sto biz­ne­so­we­go, zło­żo­ne­go, opro­gra­mo­wa­nia wypcha­ne­go” trud­ną i zło­żo­ną logi­ka biz­ne­so­wą. Dlatego takie pro­jek­ty nale­ży dzie­lić na kom­po­nen­ty, na dwa (pod)projekty, z któ­rych każ­dy moż­na (i ma to sens) reali­zo­wać odręb­ny­mi meto­da­mi pra­cy. Pierwszy (por­tal) zwin­nie, dru­gi – pla­nu­jąc i projektując.

Czytaj dalej Tak zwane projekty internetowe