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

Czy podpisywanie umów o poufności ma jeszcze sens?

Bardzo częste zapisy w umowach z dostawcami oprogramowania, mówiące że wszelkie wartości intelektualne powstające w trakcie projektu, przechodzą na własność dostawcy oprogramowania są potężnym nadużyciem, żeby nie powiedzieć: kradzieżą know-how. 

Czytaj dalejCzy podpisywanie umów o poufności ma jeszcze sens?

Koniec treści

Nie ma więcej stron do załadowania