Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
Jeżeli nie potrafisz czegoś narysować to znaczy że nadal tego nie rozumiesz. Jeżeli potrafisz coś narysować to potrafisz to także zbudować.
Czy zakup nowego ERP, CRM, WMS albo MES rzeczywiście rozwiąże problemy firmy? Jako partner kanału Platforma Przedsiębiorców zostałem poproszony o rozmowę. Przesłanie rozmowy: A może największy błąd powstaje jeszcze zanim ktokolwiek wybierze system? Pytanie brzmiało: Jak naprawdę powinno wyglądać przygotowanie przedsiębiorstwa do wdrożenia oprogramowania. Rozmawiamy o tym, dlaczego firmy zaczynają projekty IT od wyboru narzędzia zamiast od zrozumienia problemu, skąd biorą się setki i tysiące wymagań, kiedy customizacja staje się pułapką oraz dlaczego źle skonstruowana umowa może być dla zamawiającego ogromnym ryzykiem. Poruszamy również temat odpowiedzialności za projekt, testów odbiorczych,…
Wprowadzenie Aplikacje Jira i Confluence firmy Atlassian są bardzo popularne nie tylko w działach IT. Obie wspierają między innymi prace analityczne i projektowe na poziomie zadań (Jira) i treści (Confluence). Producent pakietu CASE Visual Paradigm, od wersji 17.3 wspiera integrację swojego pakietu z tymi aplikacjami, w efekcie w tych środowiskach możliwa stała się pełna integracja zespołu projektowego wykonawczego z analitykami i projektantami. Płynna integracja z Atlassian Confluence Zastosowanie: Agile Development: Udostępnianie zaktualizowanych przepływów pracy i diagramów UML w dokumentacji sprintu. Zarządzanie produktem: Osadzanie modeli procesów na stronach specyfikacji produktu. Architektura…
Wprowadzenie W marcu 2021 w artykule Struktury formularzy jako forma wyrażania wymagań skupiłem się na detalach treści formularzy ekranowych, jako elementach specyfikowania przypadków użycia. Artykuł ten sprowokował pytania o związki między formularzami, ich przepływy oraz niekończące się pytania o cel stosowania związków extend i include używane często niepoprawnie w celu pokazania "przepływu ekranów". Dlatego napisałem post będący rodzajem kontynuacji tego tekstu. W toku analizy biznesowej, a potem projektowania oprogramowania, powstają różne produkty: modele procesów biznesowych, modele architektury systemów, scenariusze integracji, definicje interfejsów, i inne. Większość ich jest niezrozumiała dla przeciętnego…
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:
Ten często aktualizowany przeze mnie wpis, stał się niemalże kompletnym opisem metodyki projektowania oprogramowania. Nie jest to "moja metodyka", to dorobek dziesiątek autorów, z którego ja także korzystam (artykuł zaopatrzyłem w bogaty spis literatury źródłowej i kilka ciekawych referatów konferencyjnych). Polecam szczególnie moim studentom oraz obecnym i potencjalnym klientom, bo to opis produktu jaki ode mnie dostaną (polecam także wpis: Moja rola w projektach). Prowadzę również warsztaty analizy i projektowania. Programming is not solely about constructing software—programming is about designing software. [Programowanie nie polega wyłącznie na tworzeniu oprogramowania - programowanie…
Separacja kontekstu dziedziny oraz separacja synonimów jako metoda zapewnienia jednoznaczności modeli obiektowych. Streszczenie: Przedstawiono metodę pozwalającą zapewnić jednoznaczność modeli obiektowych mimo istnienia synonimów w słownictwie analizowanego problemu. Wykorzystano znaną juz metodę separowania kontekstów, autor proponuje dodatkowy prosty metamodel (profil UML) pozwalający na bezpieczne użycie tego samego pojęcia zarówno jako nazwy obiektu jak i nazwy cechy obiektu. Słowa kluczowe: UML, profil, metody obiektowe, kontekst ___ Wprowadzenie Wielu autorów piszących o projektowaniu oprogramowania zwraca uwagę na problemy związane z kontekstem i synonimami pojęć w badanej dziedzinie. Jednym z popularniejszych autorów, zwracających uwagę na…
Obiekty to nie są proste "złączone dane i logika". To obdarzone odpowiedzialnością elementy większej całości. Mało jest w branży inżynierii oprogramowania książek, które praktycznie się nie starzeją. Jedną z nich, moim zdaniem, jest książka Object Design Roles, Responsibilities and Collaboration, autorzy: Rebecca Wirf-Brock i Alan McKean. Wydali ją pierwszy raz w 2002 roku. Autorzy w bardzo przystępny sposób pokazują zarówno teoretyczne jak i praktyczne aspekty analizy obiektowej (OOA, Object-oriented Analysis ) i projektowania obiektowego (OOD, Object-oriented design, łącznie często stosowany skrót OOAD). Mimo, że od pierwszego wydania minęło już 17…
Od czasu do czasu wpadają mi do skrzynki email “niuslettery”, które gdzieś tam czasem zamawiam, głównie z powodów poznawczych. Oto jeden z nich…
Nie jest tajemnicą, że na rynku mamy różne metody pracy i wszystkie mają swoich zwolenników i przeciwników czy może raczej krytyków. Tym razem przedmiotem “badania” był sposób opisania problemu i wnioski jakie autor wyciągnął.
Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę! Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy i "nieuchronność" kary za niepowodzenie. W efekcie Dostawca szybko staje się "Panem projektu", bo…
Architektura reprezentuje ważną decyzję projektową, która wpływa na kształt systemu, przy czym waga decyzji mierzona jest kosztami zmian, które wprowadza. — Grady Booch Jeśli myślisz, że dobra architektura jest droga, spróbuj złej Foote, B., & Yoder, J. (2003). Big Ball of Mud . https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud Wprowadzenie Tym razem troszkę cięższy kaliber, czyli dywagacje o tym co powszechnie jest określane jako metody obiektowe i o tym skąd "konflikty i nieporozumienia" między programistami i analitykami projektantami. Ten artykuł to streszczenie i rozwinięcie referatu: https://youtu.be/KHHj8lNW57I Paradygmaty Literatura przedmiotu zawiera wiele różnych sposobów grupowania metod programowania w paradygmaty.…
Wprowadzenie Niedawno pisałem o pewnej innej książce, jej autor opisał systemowe podejście do analizy przedsiębiorstwa. Napisałem między innymi wtedy, że: Rzecz w tym, że pojęcie ?analiza systemowa? jest używane najczęściej (jak obserwuję, prawie zawsze) w znaczeniu analizy i projektowania oprogramowania (systemy IT) co jest błędem.Tak zwane ?całościowe myślenie? (holistyczne) to uznanie, że system to nie tylko oprogramowanie. (Źródło: Systems Thinking czyli analiza systemowa organizacji | Jarosław Żeliński IT-Consulting) Tak więc pora na ciąg dalszy. Ogólna Teoria Systemów Książka ta, Ogólna Teoria Systemów , czekała u mnie na swój czas, i…
W większości chyba firm, z powodów historycznych, niemalże każdy kierownik i dyrektor ma nieco inny próg kwotowy samodzielnej akceptacji poniesionego koszu. Zapisanie w postaci wymagań a potem implementacja, takiego systemu przepływu dokumentów kosztowych, bywa koszmarem. Koszmar ten jest bardzo kosztowny z uwagi na swoją złożoność i brak ogólnych zasad. Powoduje to, że zamiast uzyskania automatyzacji i znacznego wzrostu efektywności uzyskuje się bardzo złożony i pracochłonny (kosztowny) system zamrażający zastany stan rzeczy, jedyną korzyścią czasami bywa to, że z raportów wiemy, że to na prawdę długo trwa. A to tylko jeden aspekt opisu organizacji i wymagań na oprogramowanie.
Jeśli planujecie Państwo usprawnienia w procesach lub myślicie o nowych ERP lub zmianach w systemach juz posiadanych, chętnie podpowiem kilka rozwiązań, które mogą pomóc.
Opracowuję również szczegółowe algorytmy i logikę działania aplikacji, które stanowią fundament dla zespołu developerskiego. Dzięki temu wdrożenie przebiega szybciej, a oprogramowanie powstaje bez zgadywania. Po zakończeniu projektu zapewniam stałe wsparcie: aktualizacje modeli, rozwój funkcjonalności oraz dostosowywanie architektury do nowych potrzeb firmy.
