Analityk czyli kto?

Ten artykuł to zanonimizowana korespondencja, na często pojawiający sie temat: zakres pracy analityka. O co chodzi Dzień dobry, piszę z prośbą/pytaniem czy byłby Pan w stanie polecić książkę albo inny zasób z ćwiczeniami UML oraz BPMN? Jest z tym problem bo jest mało literatury i często są to płatne publikacje naukowe. Powód jest dość prozaiczny: 1. komercyjne projektty są chronione tajemnica przedsiębiorstwa, 2. napisanie takich ćwiczeń i przykładów jest pracochłonne i mało kto to robi. Mogę polecić swoją książkę i mojego bloga ;), na blogu pod wpisami zawsze podaje wykorzystaną…

Czytaj dalejAnalityk czyli kto?

Utwór vs. projekt a własność intelektualna w inżynierii

Wprowadzenie Niedawno miała miejsce kolejna moja dyskusja na LinkedIn, która pokazała że prawo własności intelektualnej jest bardzo trudne do przyswojenia, głównie dlatego że – z uwagi na swoją „niematerialność” – wymyka się intuicyjnej i materialnej manierze postrzegania świata przez człowieka. Na to nakłada się przeświadczenie koderów, że z zasady są samodzielnymi twórcami, i niestety wielu prawników także tak uważa. Rzecz w tym, że koder zawsze jest twórcą, ale nie zawsze jest projektantem. Gdy koder nie jest projektantem, jego utwory (kod źródłowy) to utwory zależne od utworów pierwotnych, jakimi są projekty techniczne wyrażone np. z pomocą…

Czytaj dalejUtwór vs. projekt a własność intelektualna w inżynierii

Czym jest dług informacyjny

Dług informacyjny jest znacznie groźniejszy niż dług technologiczny. Same zaległości technologiczne jako takie można usunąć bez dużego ryzyka: jest to po prostu upgrade już posiadanej infrastruktury. Dług informacyjny jest znacznie bardziej niebezpieczny, bo to całkowity brak wiedzy o tym jak to zrobić bezpiecznie i co w ogóle zrobić (upgrade czy jednak wymiana systemu na nowy inny). Dług informacyjny to nie tylko nieudokumentowany system. To nieudokumentowane procesy biznesowe, procedury, reguły biznesowe, to zasoby wiedzy o organizacji jedynie w „głowach pracowników”, te zaś są najczęściej niespójne, niekompletne i bardzo często sprzeczne.

Czytaj dalejCzym jest dług informacyjny

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

Wstęp

Siedem lat temu (2015) artykuł o wymaganiach i śladowaniu 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 śladowanie wymagań jest istotne w projekcie? – Jarosław Żeliński IT-Consulting

Nadal pojawiają się publikacje o wymaganiach, zarządzaniu nimi i realizowaniu ich. Na rynku są dostępne aplikacje pozwalające je kolekcjonować i zarządzać taką kolekcją. I stale mamy do czynienia z ich – wymagań – niejednoznacznością . Okazuje się, że ich znaczenie staje sie kluczowe dla projektów, także z perspektywy prawa (PZP i zdefiniowane w zaleceniach UZP pojęcie potrzeba). Tym razem skupię się na pojęciach ‘wymaganie’ i ‘potrzeba’ w odniesieniu do projektu 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

Architektura informacji, system informacyjny a system informatyczny w organizacji

"Jeśli myślisz, że dobra architektura jest droga, spróbuj złej" Wstęp W roku 2008 pisałem (Forbs): W wie­lu fir­mach decy­zja o wdro­że­niu sys­te­mu infor­ma­tycz­ne­go bar­dzo czę­sto nie jest poprze­dzo­na żad­ny­mi przy­go­to­wa­nia­mi w rodza­ju oce­ny struk­tu­ry orga­ni­za­cji, jej zdol­no­ści do zmian czy też upo­rząd­ko­wa­niem obie­gu infor­ma­cji. Częstym grze­chem jest pró­ba ?wtło­cze­nia? w sys­tem infor­ma­tycz­ny ?sta­re­go? porząd­ku. Drugi grzech to brak opi­sa­ne­go sys­te­mu infor­ma­cyj­ne­go. W efek­cie nastę­pu­je zde­rze­nie rygo­rów papie­ro­we­go obie­gu infor­ma­cji z obie­giem danych w sys­te­mie infor­ma­tycz­nym. Rezygnacja z wie­lu czyn­no­ści (np. sta­wia­nie pie­czą­tek i pod­pi­sów) lub zamia­ny ich na inne sta­je się klu­czo­wym, bro­nio­nym jak nie­pod­le­gło­ści przez wie­lu kie­row­ni­ków…

Czytaj dalejArchitektura informacji, system informacyjny a system informatyczny w organizacji

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

Value-stream mapping czyli strumień wartości jaki wytwarza firma tworząc swój produkt

Wprowadzenie Skrót VSM zaczyna się od pewnego czasu pojawiać także w inżynierii oprogramowania, ma on jednak stary, ponad 30-letni rodowód. Mapowanie strumienia wartości (ang. Value-stream Mapping, VSM), znane od 30 lat, ostatnio także jako mapowanie przepływu materiałów i informacji (ang. material- and information-flow mapping). Jest to metoda mająca swoje początki w Lean Management, służąca do analizy stanu obecnego i projektowania stanu przyszłego dla serii zdarzeń, które prowadzą produkt lub usługę od zamówienia do momentu dostarczenia klientowi. Mapa strumienia wartości to graficzne podejście, które pokazuje wszystkie krytyczne kroki w określonym procesie…

Czytaj dalejValue-stream mapping czyli strumień wartości jaki wytwarza firma tworząc swój produkt

Czym są testy oraz kto i co testuje

Robię to zawsze a najrzadziej o tym pisze, bo to "takie oczywiste", a co to takiego? TESTY. Dobrze opracowane testy to ciekawa i wyrafinowana forma sprawdzania tego czy dostajemy to co chcemy dostać, to za co płacimy (nie raz słono). Czym są (powinny być) kryteria akceptacji? To właśnie wymagania, pozostaje pytanie: Które? Jeżeli to będą pierwotne wymagania biznesowe jest źle (patrz: Przypadki użycia to nie wymagania). Wiec co? Wymaganiem jest model: zamawiana konstrukcja, mechanizm działania. V-model czyli wprowadzenie Ogólnym, najczęściej przytaczanym modelem opisującym cykl wytwarzania w inżynierii jest tak zwany…

Czytaj dalejCzym są testy oraz kto i co testuje

User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

Wprowadzenie

O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu.

Co proponuję? To co proponuję wielu doświadczonych praktyków na świecie:

Proces MBSE powstawania systemu
(więcej…)

Czytaj dalejUser Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

Regulamin Usługi jako potrzeby czyli prawnik jako analityk

Why is this happening? The methods of project execution by most IT vendors haven't changed in 30 years: talks, interviews, coding, expensive tools (C++, Java). We've known for 20 years that writing a program in C++/Java is twice as much work compared to an identical result achieved with scripting languages (Prechelt, 2003; 2000). The continuing popularity of C++/Java has its origin: most of the large systems in the fin/tech industry were created in the 1990s, and they are not being upgraded and only added functionality despite the fact that it is no secret how to migrate to newer technologies and architectures (Laigner, Kalinowski, Diniz, Barros, Cassino, Lemos, Arruda, Lifschitz & Zhou, 2020). The reasons are quite mundane: as long as there is demand, technology suppliers have no interest in upgrading their products and are selling a permanent technological debt (Rosoff, 2011).

Czytaj dalejRegulamin Usługi jako potrzeby czyli prawnik jako analityk
Read more about the article Diagram aktywności UML c.d. – algorytmy
David Harel. (2001). Rzecz o istocie informatyki. Algorytmika. (Zbigniew Weiss & Piotr Carlson, Trans.; Wydanie trzecie). PWN.

Diagram aktywności UML c.d. – algorytmy

Technical Description of Software, as documentation of the mechanism of its operation, requires precision because it constitutes documentation of know-how (it can also be part of patent documentation). Such documentation cannot be source code of a specific (one of many on the market) programming language, as it must be a "dry" description of the mechanism of operation, and not an example of one of many possible implementations. This is also pointed out by the author of the above-mentioned book. Therefore, the documentation of the system, it is not its example implementation ("working code"), it is the essence of its operation expressed as an abstract model.

Czytaj dalejDiagram aktywności UML c.d. – algorytmy

Koniec treści

Nie ma więcej stron do załadowania