Hurtownie danych czyli “Systemy od historii”

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale…

Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny, bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO złożycie “dedykowany system” pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu “innych podmiotów w branży”.

Czytaj dalej Hurtownie danych czyli “Systemy od historii”

Czynniki sukcesu w projektach programistycznych

Pojawia się próba diagnozy. Pełna tak zwana śladowalność wymagań (nazwana tu hipertracebility) jest podobno kosztowna i trudna do utrzymania. Zaraz potem: niedbałość w definiowaniu wymagań – no to w końcu dokładnie czy nie? Kolej na analityków: zrzucanie odpowiedzialności ? analitycy tworzą dokument wymagań i wypychają go do programistów. Oczywiście jest to problem, co z tym? Analityk powinien ponosić odpowiedzialność za swój produkt do końca projektu. Założenie, że można stworzyć skończony dokument wymagań. Otóż można ale o tym za chwilę. Poza ważnymi elementami zarządzania takim projektem, w tym zarządzaniem zespołem autorzy wskazali jedną z głównych moim zdaniem przyczyn: brak dokumentu HLD (projektu wysokopoziomego).

Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów.

Czytaj dalej Czynniki sukcesu w projektach programistycznych

Udziałowcy projektu czyli który diagram UML …

Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu.

UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań.

Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią “korzeń” modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Czytaj dalej Udziałowcy projektu czyli który diagram UML …

Historia pewnego mojego klienta

Zalecenie dla zamawiających: zawsze patrze na ręce wykonawcy… prośba do programistów: Jak piszecie kod, którego celem jest szyfrowanie transmisji, renderowanie obrazków itp. to róbcie to jak najlepiej potraficie ale jak implementujecie model dziedziny to dajcie mu spokój, to nie Wasz problem, po protu skopiujcie go, a jak Wasz analityk nie potrafi Wam dać takiego modelu obiektowego to zmieńcie analityka…Po drugie wykonawca, który składając ofertę zaakceptował projekt (wymagania) a potem neguje treść tego projektu … kim jest?

Czytaj dalej Historia pewnego mojego klienta

Jolt Award: Visual Paradigm for UML

[singlepic id=228 w=320 h=240 float=right] Nie tylko ja jestem zdania, że używanie zaawansowanych systemów wspomagających prowadzenie analiz jest cechą analityków (firm), którzy przekroczyli pewien próg profesjonalizmu. Zapewne pojawią się tu zarzuty…

Czytaj dalej Jolt Award: Visual Paradigm for UML

Jak zdobyć nasze maile? Jak ich nie wysłać?

No cóż, nie jest rzadkością zrobienie literówki w adresie, nie jest także złe zaadresowanie listu w sytuacji gdy wszechobecne funkcje podpowiadania adresata wstawią w pole Do: kogoś innego z naszej listy kontaktów. Nie trzeba wielkiego pośpiechu czy nieuwagi by się to przytrafiło. Umieszczanie w stopce sentencji w rodzaju “jeżeli nie jesteś adresatem tego listu powiadom o tym nadawcę i zniszcz treść przesyłki” jest dość naiwne jeśli niechcący wyślemy super ofertę nie temu klientowi…

To zjawisko to klasyczny przykład czynnika ludzkiego, z którym poważni ludzie nie dyskutują tylko szukają sposobu jak mu zaradzić. Na pewno nie jest skutecznym sposobem administracyjny zakaz mylenia się z dużą karą za pomyłkę: po protu nikt się nie przyzna, i mało który przypadkowy adresat doniesie sam na siebie.

Jak zaradzić problemowi?

W sumie nie aż tak trudno: nie używać poczty elektronicznej do wysyłania ważnych dokumentów. Czyli?

Zamiast ryzykować wysłanie mailem ryzykownej treści, np. negocjowanej umowy, bezpieczniej jest umieścić plik w repozytorium i udostępnić uprawnionej osobie (stosowanie kompresji zip na hasło jest tylko półśrodkiem). Może to być system zarządzania przepływem pracy, nieskomplikowane repozytorium z funkcją monitorowania, inne. Możliwości jest wiele, ważne by nie “przedobrzyć” z procedurami.

Jak nie trudno się domyśleć, i tu warto wykonać rzetelną analizę wymagań, procesów komunikacyjnych wewnątrz firmy z jej otoczeniem, analizę ryzyk. Jednak o wymaganiach w tym poście już nie napiszę 🙂 zaś moi klienci wiedzą, że używam w ważnych przypadkach, systemu wymiany dokumentów zamiast poczty od ponad trzech lat.

Czytaj dalej Jak zdobyć nasze maile? Jak ich nie wysłać?

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że “nie święci garnki lepią”) dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi “projektowania” czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.

Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: “wiedza organizacji” tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalej Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!