Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn: "People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you’ve worked through a set of user stories? No. Not even close!" ["Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!".](https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/) Świat od dekad boryka się…

Czytaj dalejWymagania biznesowe – jak zbierać i dokumentować

Diagram Przypadków Użycia UML

Wstęp Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji – podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…

Czytaj dalejDiagram Przypadków Użycia UML

Projektowanie i dokumentowanie architektury oprogramowania – trzy książki

Architektura Projekty informatyczne się rozrastają, cała branża ewoluuje. Ostatnie 20 lat doświadczeń pokazało, że owszem sztuką jest stworzyć i wdrożyć oprogramowanie, ale jeszcze większą sztuką jest je konserwować, zmieniać i rozwijać. Wiele firm boryka się z powtarzanymi długotrwałymi i kosztownymi "analizami przedwdrożeniowymi" poprzedzającymi każdy kolejny projekt wdrażania zmian. To skutek braku aktualnej dokumentacji posiadanego systemu. To jak planowanie nowej budowy w mieście nie mając aktualnych planów urbanistycznych tego miasta: każdy nowy projekt to ponowne dokumentowanie stanu obecnego, tylko dlatego, że ktoś nie udokumentował zmian wprowadzonych ostatnim razem (być może poprzednio…

Czytaj dalejProjektowanie i dokumentowanie architektury oprogramowania – trzy książki

Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu informatycznego. 

Obecnie klu­czo­wym pyta­niem jest: Jak zin­te­gro­wać, a nie: Czy zintegrować. 

Pogodzenie się z tym, że świat sys­te­mó ERP już nigdy nie będzie tak pro­sty jak w cza­sach main­fra­me­’ów, czy­li jed­nej cen­tral­nej apli­ka­cji, jest nieuniknione. 

Czym jest obec­nie inte­gra­cja? To wymia­na danych a nie ich współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych w cza­sach obec­nych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia sys­tem poin­te­gro­wa­ny” jako kry­ty­kę budo­wy sys­te­mu ERP z kom­po­nen­tów i inte­gra­cji jako wymia­ny danych. Autor tego okre­śle­nia naj­praw­do­po­dob­niej nadal żyje w świe­cie mainframe. 

(wię­cej…)

Czytaj dalejIntegracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Cyfrowa Transformacja a dziedzictwo IT

Wstęp

Transformacja cyfro­wa, jest przez dostaw­ców tech­no­lo­gii infor­ma­tycz­nych, naj­czę­ściej defi­nio­wa­na jako inte­gra­cja tech­no­lo­gii cyfro­wej z dzia­łal­no­ścią fir­my. Poniżej wybra­ne defi­ni­cje, któ­re naj­czę­ściej znaj­du­je­my w sieci:

Transformacja cyfro­wa defi­niu­je się jako inte­gra­cję tech­no­lo­gii cyfro­wej ze wszyst­ki­mi obsza­ra­mi funk­cjo­no­wa­nia fir­my. Dzięki niej moż­li­we jest wyko­rzy­sta­nie gro­ma­dzo­nych danych do two­rze­nia inno­wa­cyj­nych usług i posze­rze­nia dotych­cza­so­wej oferty.

Cyfrowa trans­for­ma­cja to nic inne­go jak inte­gra­cja tech­no­lo­gii cyfro­wej we wszyst­kich obsza­rach dzia­łal­no­ści fir­my oraz zmia­na spo­so­bu, w jaki dzia­łasz i zapew­niasz klien­tom war­tość. To tak­że zmia­na kul­tu­ro­wa, któ­ra wyma­ga od orga­ni­za­cji cią­głe­go rzu­ca­nia sobie wyzwań, eks­pe­ry­men­to­wa­nia, ale rów­nież godze­nia się z poraż­ką. Transformacja cyfro­wa jest pro­ce­sem nie­unik­nio­nym, nie­za­leż­nie od roz­mia­ru przedsiębiorstwa.

Transformacja cyfro­wa odno­si się do pro­ce­sów i stra­te­gii wyko­rzy­sta­nia tech­no­lo­gii cyfro­wej do rady­kal­nej zmia­ny spo­so­bów, w jakie przed­się­bior­stwa pro­wa­dzą dzia­łal­ność i obsłu­gu­ją klien­tów. Termin ten stał się w epo­ce cyfry­za­cji wszech­obec­ny. Spowodowane jest to tym, że każ­da orga­ni­za­cja ? nie­za­leż­nie od jej roz­mia­ru i bran­ży ? coraz bar­dziej opie­ra się na danych i tech­no­lo­gii, aby zwięk­szać wydaj­ność swo­jej dzia­łal­no­ści i zapew­niać war­tość swo­im klientom.

Ogólne idee wie­dzy jako fun­da­men­tu nowej gospo­dar­ki i infor­ma­cji jako naj­waż­niej­sze­go zaso­bu wypeł­nia­ją się tre­ścią i rodzą nowe poję­cia: smart devi­ces i weare­ables, Big Data, mobil­ność, chmu­ra obli­cze­nio­wa, plat­for­my spo­łecz­no­ścio­we, bio- i nano­tech­no­lo­gie, Internet of Things, ener­gia odna­wial­na czy sha­re economy?

Dominuje inte­gra­cja tech­no­lo­gii cyfro­wej z dzia­łal­no­ścią fir­my”. Osobiście jestem zwo­len­ni­kiem tezy, że nie tyle fir­my co gene­ral­nie czło­wie­ka. Czym jest tu sama inte­gra­cja tech­no­lo­gii z dzia­łal­no­ścią czło­wie­ka? Maszyny nie myślą, jed­nak prze­twa­rza­ją dane. Człowiek nada­je zna­cze­nie danym, potra­fi je tak­że prze­kształ­cać. Cyfrowa trans­for­ma­cja to pro­ces prze­no­sze­nia prze­twa­rza­nia danych z czło­wie­ka na maszy­ny: to już nie my ludzie wyszu­ku­je­my doku­men­ty w archi­wach, robi to elek­tro­nicz­ne archi­wum, nie my ludzie obsłu­gu­je­my klien­tów za ladą, coraz czę­ściej robi to Internetowy Sklep. Cyfrowa trans­for­ma­cja to wła­śnie pro­ces prze­no­sze­nia czę­ści pra­cy z czło­wie­ka na maszyny. 

Aby trans­for­ma­cja cyfro­wa była w ogó­le moż­li­wa, musi­my prze­nieść te dane (tre­ści, infor­ma­cje) z papie­ru do kom­pu­te­ra”, w spo­sób nie­nisz­czą­cy obec­nych moż­li­wo­ści i pozwa­la­ją­cy na two­rze­nie nowych. 

Trzeba też zni­we­lo­wać posia­da­ny dług tech­no­lo­gicz­ny. Dług tech­no­lo­gicz­ny to posia­da­ne dzie­dzic­two, to zapóź­nie­nie, to pozo­sta­wa­nie w tyle za trwa­ją­cym postę­pem tech­no­lo­gicz­nym. Dług taki ma bar­dzo wie­le firm. Co z nim zro­bić i jak z nie­go wyjść?

(wię­cej…)

Czytaj dalejCyfrowa Transformacja a dziedzictwo IT

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użyt­kow­ni­ka. Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

(wię­cej…)

Czytaj dalejKastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Opracowanie analizy potrzeb i wymagań w zamówieniach publicznych

Niedawno ukazały się Wskazówki dla Zamawiających... (streszczenie i dokument do pobrania poniżej). Rada Zamówień Publicznych, doceniając wagę analizy potrzeb i wymagań, o której mowa w art. 83 ustawy z dnia 11 września 2019 r. (Dz.U. z  2019 r. poz. 2019 ze zm.),  dla przygotowania i przeprowadzenia procesu zakupowego udzielenia zamówień klasycznych o wartościach równych i przekraczających progi unijne zgodnie z celami nowej ustawy, jakimi są w szczególności podniesienie efektywności oraz konkurencyjności udzielanych zamówień, a także otwarcie na nowe propozycje rynkowe, przygotowała wskazówki interpretacyjne nowego przepisu, mając nadzieję, iż okażą się one przydatne…

Czytaj dalejOpracowanie analizy potrzeb i wymagań w zamówieniach publicznych

Krótka historia pewnego wymagania

Wprowadzenie Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: "projektowanie to waterfall". Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję "Dokumenty analizy biznesowej" albo "Dokumenty wymagań" zawierające setki pozycji o treści "system powinien...", nie raz wykonane przez krytyków "water fall", którzy reprezentując developera deklarującego metody "agile", "zabezpieczają się" przez odpowiedzialnością za zakres projektu. Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków "user story" ani detaliczna…

Czytaj dalejKrótka historia pewnego wymagania

Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten arty­kuł to uzu­peł­nie­nie opi­su: Dokument jako wyma­ga­nie.

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. Zauważyli to tak­że inni:

A Mock-up is a sli­gh­tly glo­ri­fied pic­tu­re, so you will be answe­ring with at least 1001 words ! 

Bardzo czę­sto widu­ję wyma­ga­nia spi­sy­wa­ne jako tak zwa­na lista funk­cji lub funk­cjo­nal­no­ści. Pojęcia te mają takie defi­ni­cje w języ­ku polskim: 

funk­cja ?zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz?, ?moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez urzą­dze­nie lub pro­gram komputerowy?

Funkcjonalność jest defi­nio­wa­na jako funk­cja cze­goś w jakimś systemie. 

(wię­cej…)

Czytaj dalejStruktury formularzy jako forma wyrażania wymagań

Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potrafi zabić ;) czyli czym jest dokument oraz fakt i obiekt. Czym się różni zakup kilku produktów, w tym samym sklepie, w np. godzinnych odstępach czasu, od zakupu wszystkich razem? Poza formą udokumentowania, niczym: w sklepie to samo i tyle samo zeszło ze stanu magazynu, a my wydaliśmy w obu przypadkach tyle samo pieniędzy (o promocjach później)! W pierwszym przypadku mamy kilka faktów zakupu, w drugim, jeden, ale zawsze tyle samo obiektów (produkt). Faktura (paragon) to dokument opisjący fakt, przedmiot sprzedaży jest obiektem. Tu obiektem…

Czytaj dalejDokument a kumulacja faktów: OOAD i model dziedziny systemu

Koniec treści

Nie ma więcej stron do załadowania