Dokument i jego struktura jako metoda zarządzania danymi

[toc]

Wprowadzenie

Bardzo wiele problemów w toku wdrożeń IT rodzą wadliwie zaprojektowane struktury dokumentów. Dotyczy to w szczególności zarządzania dostępem do treści, a patrząc szerzej: do informacji. Ostatnie lata to między innymi problemy urzędów z udzielaniem dostępu do informacji publicznej, od dwóch lat dodatkowo problemy stwarza RODO. Źródłem problemów jest treść dokumentów, rozumiana jako pytanie: “Czy te informacje muszą być zawarte w tym dokumencie”. Najpierw opiszę mechanizm powstawania przyczyn problemów i sposób ich rozwiązania. W podsumowaniu wskażę jak i gdzie sobie z tym radzić.

(więcej…)

Czytaj dalejDokument i jego struktura jako metoda zarządzania danymi

Projekt aplikacji – przykład

Wstęp

Napisałem o orientacji na dokumenty w toku analiz:

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. (Wymagania na formularze czyli diagramy struktur złożonych i XML)

Dzisiaj pójdziemy dalej, omówimy to gdzie i jak zachować tę informację. Posłużę się prostym przykładem przychodni weterynaryjnej. Artykuł będzie opisem metody podejścia do analizy zorientowanej na procesy i dokumenty.

Tekst ma dwie części: pierwsza jest opisem drogi jaka prowadzi nas do zdefiniowania tego jakie dokumenty, jaką mają (mieć) zawartość i strukturę. Praktycznie jest to opis analizy i projektowania. Druga – krótka – to przykładowa architektura logiki realizacji aplikacji, pokazująca miejsce dokumentowej bazy danych w architekturze i projekcie, czyli także projektowanie.

Celem tego wpisu jest pokazanie czym może być analiza oraz jej produkt jakim jest Techniczny Projekt Oprogramowania.

(więcej…)

Czytaj dalejProjekt aplikacji – przykład

Biznesowy (kanoniczny) model danych – nie chcemy

Nadal obserwuję to, że model relacyjny i "tworzenie modeli danych na etapie analizy wymagań" (kanoniczny model danych) trzymają się twardo mimo tego, że nie wiele wnoszą do projektu a narzucają (sugerują) kiepską architekturę aplikacji z jedną relacyjna bazą danych.  Co ciekawe zaczynanie od bazy danych jest wręcz zaprzeczeniem zwinności (konieczność ukończenia projektu docelowej bazy danych przed rozpoczęciem kodowania czyli klasyka waterfall, w efekcie betonowanie stanu z dnia rozpoczęcia) mimo, że autorki artykułu piszą o sobie że są agile...) Popatrzmy na to co proponują w tym 2017 roku.: Jeśli w systemie…

Czytaj dalejBiznesowy (kanoniczny) model danych – nie chcemy

Dokumenty czy niedokumenty…. czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisałem, że analizy i projekty związane bezpośrednio z wymaganiami na oprogramowanie to "tylko" ok. 3/4 moich projektów. Jednak nawet, jeżeli projekt nie jest "nazwany" informatycznym, to zawsze jest "informacyjny" w rozumieniu zarządzania informacją (także zarządzanie wiedzą). Tym razem kilka słów na temat dokumentów. Stanowią one podstawową jednostkę informacji (i danych) w każdym systemie biznesowym. Są także źródłem danych dla hurtowni danych. Wstęp Wiele projektów związanych z dokumentami jest sprowadzanych do problemu: "jakie mamy dokumenty i co z nimi robimy?" Zaniedbuje się bardzo ważny element: odpowiedź na…

Czytaj dalejDokumenty czy niedokumenty…. czyli zarządzanie informacją i jej standaryzacja

Architekt danych ? czy na pewno zawód przyszłości?

Rola architektury danych znalazła także odzwierciedlenie w zarobkach architektów danych. Diagram 3 przedstawia średnie zarobki roczne architektów różnych specjalności w tysiącach USD (dla porównania dodano także inne specjalności z obszaru IT). Widać wyraźnie, że architekci danych są wśród najwyżej opłacanych specjalistów. (źr. Architekt danych ? zawód przyszłości?). ja obserwuje coś "obok", otóż dane są wtórne w stosunku do faktów, obecne systemy raczej odchodzą od "jednolitych współdzielonych baz danych", i nie dlatego, że RDBMS są "niemodne", a dlatego, że same dane pozbawione kontekstu, są mało wartościowe (do tego normalizacja modeli danych to proces…

Czytaj dalejArchitekt danych ? czy na pewno zawód przyszłości?

Konferencja DATA CENTER & STORAGE GigaCon ? Systemy baz danych oraz pamięci masowe dla przedsiębiorstw

Konferencja skierowana jest do szerokiego kręgu odbiorców wykorzystujących lub zamierzających wdrażać omawiane technologie i narzędzia. Osoby, które zapraszamy do udziału to osoby z branży informatycznej, bankowej i finansowej, przemysłu, telekomunikacji, ubezpieczeń, handlu oraz administracji.

Czytaj dalejKonferencja DATA CENTER & STORAGE GigaCon ? Systemy baz danych oraz pamięci masowe dla przedsiębiorstw

SDJ – Pismo nie tylko dla programistów…

Okres wakacyjny (kiedy to było …) zaowocował stosem zaległej literatury…. Dziś przyszła pora na zaległe numery Software Developer Journal. Czasopismo adresowane głównie do programistów i architektów ale jako analityk i ja także znajduje tam nie raz coś ciekawego.

(więcej…)

Czytaj dalejSDJ – Pismo nie tylko dla programistów…

Koniec treści

Nie ma więcej stron do załadowania