Stosowane metody analizy biznesowej i projektowania

Jeżeli czegoś nie potrafisz narysować, to znaczy, że nadal tego nie rozumiesz, jeżeli coś jest trudne do narysowania, to tym bardziej będzie to trudne do realizacji.(JarosŁaw Żeliński) Wprowadzenie Podstawowe pojęcie…

Czytaj dalej Stosowane metody analizy biznesowej i projektowania

Open Source w biznesie

otwar­tość opro­gra­mo­wa­nia (kodu) czy­ni go bar­dziej wia­ry­god­nym, otwar­tość kodu skła­nia jego twór­ców do pod­no­sze­nie jego jako­ści (wstyd zabra­nia par­ta­ni­ny ;)), to czy jest dar­mo­wy czy nie, zale­ży wyłącz­nie od mode­lu biz­ne­so­we­go sprze­da­ży: twór­ca sam usta­la czy zara­bia na licen­cjo­no­wa­niu kodu czy na swo­jej wie­dzy i pra­cy, zamy­ka­nie kodu”, to kwe­stia subiek­tyw­ne­go uzna­nia twór­cy kodu, czy sta­no­wi on (treść) chro­nio­ne know-how (jego prze­wa­gę kon­ku­ren­cyj­ną) czy nie… ale war­to dodać, że prze­wa­ga sto­ją­ca na takiej tajem­ni­cy ma jed­nak gli­nia­ne nogi (jak każ­da prze­wa­ga bazu­ją­ca w 100% na tajemnicy). 

Czytaj dalej Open Source w biznesie

Najczęściej popełniane błędy podczas wdrożenia ERP

Przy piątku naszło mnie na zestawienie pewnych treści (cytaty). Podczas codziennej "prasówki" wpadłem na artykuł "Najczęściej popełniane błędy podczas wdrożenia ERP", oto cytat pierwszy: - Największym błędem popełnianym przy wdrożeniach…

Czytaj dalej Najczęściej popełniane błędy podczas wdrożenia ERP

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy. Faktycznie, czy­tel­ni­cy mają wie­le racji, jest on dość bli­ski imple­men­ta­cji”. Niejednokrotnie lep­szym pomy­słem” jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy deve­lo­pe­ro­wi. […] Nieco inne podej­ście, to któ­re sto­su­ję obec­nie, opi­su­ję poni­żej. Zachowując pod­sta­wo­we zna­cze­nia tych trzech klas, dosto­so­wa­łem je do wzor­ca MVVC. Jest to o tyle wygod­ne i waż­ne, że sto­so­wa­nie wzor­ca BCE wyłącz­nie do mode­lo­wa­nia logi­ki biz­ne­so­wej wyma­ga zacho­wa­nia her­me­ty­za­cji kom­po­nen­tu Model. W takim ukła­dzie boun­da­ry nie będzie ele­men­tem kom­po­nen­tu View a Modelu. Jego rola to stwo­rze­nie dedy­ko­wa­ne­go inter­fej­su do model np. pomię­dzy kom­po­nen­tem View lub Controlerem. Dzięki temu moż­li­we jest stwo­rze­nie odręb­ne­go inter­fej­su dla View na duży ekran i odręb­ne­go dla View na np. małych ekra­nach smart­fo­nów. Tak więc jest moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą tak to ma dzia­łać” a nie tyl­ko tak to ma wyglą­dać”, bo to dru­gie jest przy­czy­ną wie­lu problemów…

Czytaj dalej Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Polityki

[strona główna] Polityki strony Wydawcą Strony WWW pod adresem URL: http://IT-Consulting.pl wraz z podstronami (dalej Strona) oraz autorem publikowanych treści, jest Jarosław Żeliński prowadzący działalność gospodarczą na terenie Wielkiej Brytanii…

Czytaj dalej Polityki

Komunikacja czyli analiza i projektowanie oraz jak to zostanie odebrane

Wiele firm pro­gra­mi­stycz­nych ma eta­to­wych, tak zwa­nych ana­li­ty­ków wyma­gań, jed­nak oni z regu­ły nadal nie są pro­jek­tan­ta­mi. Raczej zapi­su­ją, w z góry usta­lo­ny spo­sób, to co mówi Zamawiający (z regu­ły zresz­tą bez peł­ne­go zro­zu­mie­nia co powie­dzia­no). Bywa, że pro­jek­tan­ta lub pro­gra­mi­stę wysy­ła się w roli ana­li­ty­ka. To też nie dzia­ła z tych samych powo­dów komu­ni­ka­cyj­nych, co potwier­dza praktyka.

Czy wyko­naw­ca może mieć dobre­go ana­li­ty­ka pro­jek­tan­ta? Może mieć, nie­je­den nawet ma ale… z jakie­goś powo­du uzna­no, w znacz­nie star­szej niż inży­nie­ria opro­gra­mo­wa­nia, bran­ży budow­la­nej, że Wykonawca nie powi­nien być auto­rem tego co nale­ży wyko­nać dla Zamawiającego. Zamawiający tak­że nie powi­nien być pro­jek­tan­tem. Dlaczego? Każda fir­ma (jej Prezes) dąży do mak­sy­ma­li­za­cji swo­je­go zysku (tu ren­tow­no­ści nasze­go pro­jek­tu), inte­re­sy Zamawiającego i Wykonawcy są więc sprzecz­ne dla­te­go wyma­ga­na jest trze­cia rola: nie­za­leż­ny pro­jek­tant. I tak wła­snie to wyglą­da w pro­jek­tach budow­la­nych, w któ­rych archi­tekt to osob­ny pod­miot. Zachowuje on tak­że pra­wo nad­zo­ru autor­skie­go nad reali­za­cją swo­je­go pro­jek­tu by tak­że na eta­pie reali­za­cji pano­wać nad nim. W trak­cie reali­za­cji nadal inte­re­sy Zamawiającego i Wykonawcy sprzecz­ne – Zamawiający mak­sy­ma­li­zu­je funk­cjo­nal­ność czy­li for­su­je wzrost kosz­tów to zaś nisz­czy zysk Wykonawcy, któ­ry sta­ra się tę funk­cjo­nal­ność minimalizować.

Czytaj dalej Komunikacja czyli analiza i projektowanie oraz jak to zostanie odebrane

User story – kłopoty

Tak więc wyma­ga­nia na opro­gra­mo­wa­nie powin­ny być okre­ślo­ne przez dia­log biz­ne­so­wy zaś spe­cy­fi­ka­cja opro­gra­mo­wa­nia przez dia­log tech­no­lo­gicz­ny. I tu łyż­ka dzieg­ciu: wie­le razy byłem świad­kiem gdy to zama­wia­ją­cy psuł pro­jekt uwa­ża­jąc, że wie lepiej jak się two­rzy opro­gra­mo­wa­nie. Zjawisko to (tu bar­dzo nie­bez­piecz­ne dla życia ludzi) tak­że zna inży­nie­ria budow­la­na dla­te­go pra­wo budow­la­ne wyma­ga pro­jek­tu archi­tek­ta a jego pro­jekt chro­ni nie tyl­ko pra­wo budow­la­ne ale tak­że i autorskie.

Czytaj dalej User story – kłopoty