Autor: Jarosław Żeliński

Ten autor napisał 873 artykuły
Read more about the article Analiza nie musi być przedwdrożeniowa

Analiza nie musi być przedwdrożeniowa

Wprowadzenie

W ramach jednego z moich niedawnych projektów badawczych celem analizy nie było opracowanie wymagań na oprogramowanie (tego typu projekty to najwyżej ok. 70% mojej aktywności) a rozwiązanie pewnych problemów informacyjnych. Z uwagi na ochronę know-how klienta, opis ten został mocno okrojony do istoty problemu oraz metody jego rozwiązania, nie ma tu z oczywistych powodów opisu rozwiązania (ale ważne jest to, że rozwiązanie znaleziono). Wartość jednak ma to, że czytelnik może się tu odnaleźć i sam przekonać, co jest źródłem pewnych problemów, czy i jak można je rozwiązać.

W poniższym tekście pojęcie system odnosi sie do systemu dokumentów i formularzy czyli do informacji i zarządzania nią.

(więcej…)

Czytaj dalejAnaliza nie musi być przedwdrożeniowa
Read more about the article Krótka historia pewnego wymagania

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
Read more about the article Kod open source, prawa do niego i jego wartość

Kod open source, prawa do niego i jego wartość

Na stronach portalu LindekIn ukazał sie bardzo dobry artykuł autorstwa Marcina Maruty z kancelarii Maruta Wachta sp.j., na temat oprogramowania open source: Barierą technologiczną jest brak dostępu do kodu źródłowego, niezbędnego dla wprowadzania zmian i rozwoju oprogramowania. Barierą prawną jest natomiast bardzo szeroki zakres ochrony programów komputerowych, który sprawia że jakakolwiek forma korzystania z programu, w tym jego modyfikowanie, wymagają uzyskania zgody uprawnionego. Ruch Open Source, wyrósł ze sprzeciwu wobec takiego stanu rzeczy, stawia sobie za cel tworzenie i popularyzowanie programów ?otwartych?, ?wolnych?, a więc dostępnych wraz z kodem źródłowym…

Czytaj dalejKod open source, prawa do niego i jego wartość
(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Wprowadzenie W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, że Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat dokumentów . Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie:…

Czytaj dalejKoncepcja wzorca projektowego dla systemów w chmurze
Read more about the article Bazy NoSQL jako implementacje wzorców struktur informacji

Bazy NoSQL jako implementacje wzorców struktur informacji

Dane niestrukturalne stanowią ponad 80% składowanych danych, to oznacza, że model relacyjny pozwala opisać i przetwarzać tylko ułamek posiadanej informacji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE) [toc] Wstęp W podsumowaniu niedawnego artykułu o NoSQL w chmurze, napisałem: Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmurze - NoSQL - Jarosław Żeliński IT-Consulting - Systemy Informacyjne) Artykuł sie właśnie ukazał. We wstępie napisałem:…

Czytaj dalejBazy NoSQL jako implementacje wzorców struktur informacji
Read more about the article Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases: Business & Management Book Chapter | IGI Global

Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases: Business & Management Book Chapter | IGI Global

Jaroslaw Zelinski (Independent Researcher, UK)Source Title: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation Copyright: ? 2021 | Pages: 24 DOI: 10.4018/978-1-7998-8587-0.ch003 OnDemand PDF Download: Available $37.50 Current Special Offers Abstract This study presents a method for the storage of data organized in digital documents, which is proven in practice. The discussed method does not bear any disadvantages of the relational model used for data organization, such as the loss of data context and complications evoked by the lack of data redundancy. The method presented here can be used for data organization into documents…

Czytaj dalejDigital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases: Business & Management Book Chapter | IGI Global
Read more about the article Struktury formularzy jako forma wyrażania wymagań

Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten artykuł to uzupełnienie opisu: Dokument jako wymaganie.

Często jestem i ja pytany o to “Jak wyjaśnić złożone rozwiązanie techniczne interesariuszom nietechnicznym?” Jak wielu mi podobnych odpowiadam: rozmawiaj dokumentami. Sponsor projektu, przyszli użytkownicy, postrzegają swoją pracę poprzez dokumenty: ich treść i układ. Zauważyli to także inni:

A Mock-up is a slightly glorified picture, so you will be answering with at least 1001 words !

Bardzo często widuję wymagania spisywane jako tak zwana lista funkcji lub funkcjonalności. Pojęcia te mają takie definicje w języku polskim:

funkcja ?zadanie, które spełnia lub ma spełnić jakaś osoba lub rzecz?, ?możliwość wykonania określonej operacji przez urządzenie lub program komputerowy?

Funkcjonalność jest definiowana jako funkcja czegoś w jakimś systemie.

(więcej…)

Czytaj dalejStruktury formularzy jako forma wyrażania wymagań
Read more about the article Repozytorium w chmurze – NoSQL

Repozytorium w chmurze – NoSQL

Wprowadzenie Coraz częściej czytamy o środowiskach "chmurowych" (nadal nie mogę się przekonać do pisania tego bez cudzysłowu). Nawet tak zaawansowane jak Amazon WS czy AZURE, są nadal bardzo często wykorzystywane tylko jako hosting aplikacji. Oba te serwisy można wykorzystywać jako sieciowy dysk, środowisko systemowe (Windows, Linux), bazę danych SQL, ale także jako bazy NoSQL. Jednym z najistotniejszych elementów systemów informacyjnych (patrz: information science) jest utrwalanie danych (pamiętajmy, że dane to zapisy, a informacja to to, co rozumie człowiek, który je czyta). Niedawno nawiązywałem do problemu utrwalania danych. Poprawna obiek­to­wa archi­tek­tu­ra…

Czytaj dalejRepozytorium w chmurze – NoSQL
Read more about the article Na co zwrócić uwagę przygotowując się do wyboru systemu w 2021?

Na co zwrócić uwagę przygotowując się do wyboru systemu w 2021?

Jak dobrze przygotować się do projektu aby nie wpaść w spirale kosztów? WPROWADZENIE Każdy kolejny rok to kolejne rozpoczynane projekty wdrożeniowe, ale także i kolejne zakończone wdrożenia systemów informatycznych (system). Warto podkreślić, że zakończone wdrożenie nie zawsze oznacza zrealizowany planowany zakres wdrożenia (31% projektów tak się kończy). Zakończone wdrożenie to także bardzo często przerwane wdrożenie (19% projektów) [patrz: Henry Portman, Review Standish Group ? CHAOS 2020: Beyond Infinity, Henny Portman's Blog - On Portfolio, Programme and Project Management, 06.01. 2021]. Uważam, że właśnie te przerwane projekty powinny być podstawowym wyznacznikiem…

Czytaj dalejNa co zwrócić uwagę przygotowując się do wyboru systemu w 2021?
Read more about the article Dokument a kumulacja faktów: OOAD i model dziedziny systemu

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
Struktura projektu UML

V-model i iteracyjne budowanie systemów

Wprowadzenie Ten artykuł to krótki wpis o tak zwanym V-modelu. Jest to model wytwarzania oparty na pętli analizy, projektowania, testowania i przekazania do użytku. Oparty jest połączeniu dwóch cykli życia: projektowania i wytwarzania. jest stosowany w szeroko pojętej inżynierii systemów, nie koniecznie oprogramowania. W branży IT znana jego postać wygląda np. tak: V-Model is also referred to as the Verification and Validation Model. In this, each phase of SDLC must complete before the next phase starts. It follows a sequential design process the same as the waterfall model. The testing…

Czytaj dalejV-model i iteracyjne budowanie systemów
Read more about the article Czy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?

Czy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?

O integracji i unikaniu kastomizacji monolitów poprzez wdrażanie dziedzinowych podsystemów napisałem tu wiele. Tym razem kilka komentarzy do krótkiego tekstu pewnego dostawcy monolitu ERP. Tekst krótki więc cytowanie stanowi niemalże jego połowę ale cóż, prawo cytowania treści bezpośrednio komentowanych... Artykuł Choć wyspecjalizowane pod konkretny obszar systemy oferują szerokie możliwości i najłatwiej je dopasować do potrzeb organizacji, może okazać się, że wraz z rozwojem firmy przestaną być efektywne. (źr.: 6 przesłanek, które mogą wskazywać, że powinieneś wdrożyć kompleksowe oprogramowanie) Pierwsze zdanie to prawda, a drugie (zaczynając sie od "może") sugeruje, że…

Czytaj dalejCzy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy
Starsze wpisy