Depozyt kodu źródłowego czyli co naprawdę należy chronić? Archiwum!

Wprowadzenie Bardzo często jestem pytany o to jak się zabezpieczyć kupując lub zamawiając oprogramowanie. Wielu prawników zaleca depozyt kodu źródłowego. Zdjęcie po prawej to przykładowy fragment takiego kodu. Kto zrozumiał? Często czytam: "Depozyt kodu źródłowego (ang. source code escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania." https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/ Niestety bywa to kosztowne i jest to bardzo złe rozwiązanie, bo w zasadzie przed niczym nie zabezpiecza. Depozyt kodu źródłowego jest jedną najbardziej bezwartościowych metod ochrony. Dlaczego? Są to tysiące lub setki tysięcy linii kodu, nie raz bardzo niskiej…

Czytaj dalejDepozyt kodu źródłowego czyli co naprawdę należy chronić? Archiwum!

Czym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Wstęp

Siedem lat temu (2015) arty­kuł o wyma­ga­niach i śla­do­wa­niu koń­czy­łem słowami: 

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce ??wyma­gań? to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu? Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać ??czer­wo­ne­go kolo­ru? nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Source: Dlaczego śla­do­wa­nie wyma­gań jest istot­ne w pro­jek­cie? – Jarosław Żeliński IT-Consulting

Nadal poja­wia­ją się publi­ka­cje o wyma­ga­niach, zarzą­dza­niu nimi i reali­zo­wa­niu ich. Na ryn­ku są dostęp­ne apli­ka­cje pozwa­la­ją­ce je kolek­cjo­no­wać i zarzą­dzać taką kolek­cją. I sta­le mamy do czy­nie­nia z ich – wyma­gań – nie­jed­no­znacz­no­ścią . Okazuje się, że ich zna­cze­nie sta­je sie klu­czo­we dla pro­jek­tów, tak­że z per­spek­ty­wy pra­wa (PZP i zde­fi­nio­wa­ne w zale­ce­niach UZP poję­cie potrze­ba). Tym razem sku­pię się na poję­ciach «wyma­ga­nie» i «potrze­ba» w odnie­sie­niu do pro­jek­tu rozwiązania.

(wię­cej…)

Czytaj dalejCzym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Model UML i stereotypy jako ikony

Wprowadzenie Modele UML są często postrzegane jako niezrozumiałe diagramy. Do napisania tego artykułu skłonił mnie pewien wpis na LinkedIn, w którym pokazano ciekawy schemat blokowy: źr.: Marcel van Oost, LinkedIn, https://www.linkedin.com/posts/marcelvanoost_fintech-payments-paytech-activity-7085945466286153728-GEgt Nie tylko moim zdaniem jest to bardzo obrazowe pokazanie tego jak działają te systemy płatności, szczególnie, że bardzo dobrze jest dobrany poziom abstrakcji: autorowi udało sią pokazać istotę mechanizmu realizacji tych płatności bez zbędnych detali. Pierwsze moje wrażenie, gdy zobaczyłem ten diagram to: to jest diagram komunikacji UML a obrazowe ikony na tym diagramie to stereotypy. Stereotyp czyli typ…

Czytaj dalejModel UML i stereotypy jako ikony

Diagramy w notacji UML

Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu…

Czytaj dalejDiagramy w notacji UML

Organizacja jako mechanizm czyli słoń w pokoju

The era of "sacred cows" of engineering is slowly coming to an end. Software engineering, after almost 20 years of an "agile" approach to this branch of engineering, is beginning to mature into "real engineering" with analysis, design and testing on the "drawing board" of CASE systems and MBSE approaches, which are a universal systems approach to multidisciplinary engineering (mechatronics) (Rosenberg, 2023). Organizations are also systems and their engineering: we have business process engineering, resource engineering, financial engineering. Organizations are systems and should be treated and modeled as such (Kozminski, 1979). IT systems maintenance and development costs are already more than 8% of a company's revenue, and this value is slowly but steadily growing. The discipline of their creation, implementation and management of their costs is also growing.

Czytaj dalejOrganizacja jako mechanizm czyli słoń w pokoju
Read more about the article Modelowanie systemów – organizacja jako mechanizm
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: The systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Modelowanie systemów – organizacja jako mechanizm

Wprowadzenie Pojęcie 'system' stało się bardzo popularne, głównie za sprawą "systemów informatycznych", jednak jego rodowód jest starszy i pochodzi nie od technologii a od biologii . Poza IT mamy systemy bezpieczeństwa, system ubezpieczeń, system emerytalny, system prawa, i wiele innych. Słownik języka polskiego podaje taką definicję pojęcia system: układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość narządy lub inne części żywego organizmu pełniące razem określoną funkcję uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię określony sposób wykonywania jakiejś czynności lub…

Czytaj dalejModelowanie systemów – organizacja jako mechanizm

Diagram Przypadków Użycia UML – aktor jako persona

Wstęp W niedawno napisanym artykule na temat przypadków użycia i ich definicji zgodnej z UML, wskazywałem między innymi, że: Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły] na rzecz i na żąda­nie Aktora. źr.: Diagram Przypadków Użycia UML - Jarosław Żeliński IT-Consulting Sama specyfikacja UML o aktorze, jako elemencie wokół systemu, mówi bardzo niewiele, poza rozdziałem dotyczącym przypadków użycia: Przypadki użycia są sposobem na uchwycenie wymagań systemów, czyli tego, co systemy mają robić. Kluczowymi pojęciami…

Czytaj dalejDiagram Przypadków Użycia UML – aktor jako persona
Model systemu służy do określenia składników systemu.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: the systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Modelowanie produkcji

Nie używamy notacji BPMN do modelowania tego co się dzieje na produkcji. Skoro nie BPMN to czego używamy? Wprowadzenie Analityczne modele BPMN to łańcuchy aktywności reprezentujących procedury oraz ich produkty czyli dokumenty (dane). Na tych modelach aktywność to abstrakcja reprezentująca (całą) pracę, której efekt (wynik) jest prezentowany jako treść (DataObject), czyli aktywność kopania rowu kończy się pisemnych stwierdzeniem, że rów wykopano, z ewentualnym opisem parametrów tego rowu (patrz specyfikacja BPMN i definicja atomowej aktywności w procesach ). A gdzie dokładny opis machania łopatą albo obsługi koparki? Ten opis to procedura,…

Czytaj dalejModelowanie produkcji

Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Wprowadzenie Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to "coś nowego", ale być może mają jakieś rady dla projektantów. Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się standardem…

Czytaj dalejInterface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Notacja EPC

Wprowadzenie Notacja EPC (Event-driven Process Chain) została opracowana w 1992 roku w ramach projektu badawczo-rozwojowego z udziałem SAP AG na University of Saarland w Niemczech, a jej twórcą jest dr August-Wilhelm Scheer. Stanowi ona kluczowy element koncepcji modelowania SAP R/3 w zakresie inżynierii biznesowej i dostosowania tego systemu do potrzeb klienta, została włączona także do systemu NetWeaver firmy SAP. Ostatni duży projekt z jej użyciem realizowałem w 2008 roku dla polskiego oddziału niemieckiego banku WestLB Bank Polska SA. Później już jedynie okazjonalne wsparcie merytoryczne i audyty, nadal się zdarzają. EPC…

Czytaj dalejNotacja EPC
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…

Czytaj dalejWymagania biznesowe – jak zbierać i dokumentować

Diagram Przypadków Użycia UML

Wprowadzenie 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

Koniec treści

Nie ma więcej stron do załadowania