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

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?

Know-how a Zasada Kerckhoffs’a i bezpieczeństwo

Wprowadzenie Tematem numer jeden, niemalże w każdym moim projekcie, jest model biznesowy i tajemnica przedsiębiorstwa. Z perspektywy lat muszę powiedzieć, że to fobia wielu (jak nie większości) przedsiębiorców i nie tylko przedsiębiorców. Nie dlatego, że chcą coś chronić, ale dlatego co i jak chronią. Nie raz już pisałem, że firmy nie raz, najpierw podpisują z dostawcami rozwiązań i konsultantami umowy o poufności, a potem wyzbywają praw do swojego know-how na ich rzecz: W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię…

Czytaj dalejKnow-how a Zasada Kerckhoffs’a i bezpieczeństwo

Prawo autorskie i prawa pokrewne

Każdy analityk to nie tylko pisarz ;), to także, a nawet przede wszystkim, projektant. To także ktoś, kto dba o prawa (powinien!) swoich klientów. Dlatego gorąco polecam każdemu, kto w projektach tworzy dokumenty, lub jest odpowiedzialny za ich tworzenie, tę lekturę. W szczególności rozdziały I do V, opisujące istotę praw autorskich i pokrewnych, prawa pokrewne i ochronę baz danych. Często słyszę, że to domena prawników, otóż nie. Domeną prawnika jest pilnowanie zgodności dokumentów z szeroko-pojętym prawem cywilnym (autorskim owszem także), ocena ryzyka podpisania danej umowy itp. Jednak niestety prawnicy (z…

Czytaj dalejPrawo autorskie i prawa pokrewne

Jawność ofert – zawsze mów prawdę

Na prawdę uważam, że ukrywanie treści ofert to sygnał: "jestem kanciarzem" (podobnie jak niepodpisywanie ich imieniem i nazwiskiem autora). Nie widzę nawet jednego powodu by np. cena była "know-how" firmy... jeżeli ktoś tak uważa to ... współczuję. Prawdziwe know-how spokojnie chroni prawo autorskie czy patentowe, tajemnica firmy - a np. szczegóły organizacyjne firmy (tajemnica), to raczej nie jest przedmiot oferty ani zapytania.

Czytaj dalejJawność ofert – zawsze mów prawdę

Tablice decyzyjne

Wiele firm ma problemy zarządcze nie dlatego, że są źle zarządzane, ale dlatego, że stopień złożoności tych firm jest zbyt duży by podejmować je na wyczucie. W obecnych czasach decyzje muszą być podejmowane w relatywnie krótkim czasie bo rynek nie czeka, jednak jakość tych decyzji nie powinna być zła. Dlaczego bywa zła? Bo decyzje są nie raz podejmowane z niepełnym zrozumieniem sytuacji. Podejmowana decyzja, by była możliwie najlepsza, wymaga pełnego zrozumienia, tego czego dotyczy (co chyba nie jest dziwne). Jeżeli dotyczy firmy, nie powinno się podejmować decyzji bez pełnego zrozumienia potencjalnego wpływu tej decyzji na firmę. W przeciwnym wypadku skutki są dość losowe, czyli nie zarządzamy a staramy się zarządzać.[...] Analiza biznesowa organizacji poprzedzająca np. wdrożenie nowego oprogramowania, powinna polegać na wykonaniu audytu i uporządkowaniu reguł decyzyjnych oraz opracowaniu modeli procesów biznesowych by je zweryfikować. Drugi krok to ocena, jakiej wiedzy oczekujemy od ludzi (ich umiejętności i wiedza). Dokumentujemy ją z obawy przed "błędem ludzkim". Tu zwracam uwagę na to, że wymaganiem na oprogramowanie może być tablica decyzyjna, jeżeli planujemy automatyzację jakiejś czynności. Proces biznesowy nie jest wymaganiem, to co najwyżej kontekst wykonywanych czynności.

Czytaj dalejTablice decyzyjne

Koniec treści

Nie ma więcej stron do załadowania