Inżynieria wymagań

Jak widać, z zupełnie z innej strony “odkryliśmy” coś co nazywamy architekturą korporacyjną. Skoro każda analiza wymagań w istniejącej organizacji, to każdorazowa analiza od poziomu motywacji biznesowej projektu, przez wymagane usługi aplikacyjne, integracje aż do platform sprzętowo-systemowych, to mamy nic innego, jak projekt dokumentowania architektury korporacyjnej. I na koniec bardzo ważna moja uwaga: za jakość wymagań odpowiada i ponosi konsekwencje w 100% kupujący, nigdy dostawca!

Czytaj dalej Inżynieria wymagań

Symulacja procesów i działań w BPMN

W dużym skrócie: nie warto dublować kompetencji bo to nomen omen powielanie ich kosztów. Jeżeli firma ma wdrożone procedury kontrolingowe, to naturalnym jest przekazanie danych (produktu) modelowania i optymalizacji procesów, zamiast wzajemne konkurowanie, tym bardziej, że dane z kontrolingu zawsze – jak sądzę – zostaną uznane za bardziej wiarygodne . Bardzo dobrym “narzędziem” łączącym kontroling, modelowanie procesów i zasoby (nie tylko IT) jest architektura korporacyjna, ale to materiał na kolejny artykuł ;).

Czytaj dalej Symulacja procesów i działań w BPMN

Czym zajmuje się ustawodawca w IT

Obecne ustawy idą w kierunku ustalania metody projektowania systemów teleinformatycznych, opisywania ich szczegółów, metod powstawania. Po co na poziomie ustawy definiować np. pojęcie minimalnych wymagań skoro nie zdefiniowano tego minimum? To już elementy metodyki specyfikowana i tworzenia oprogramowania. Znacznie lepiej by było, gdyby powstał dokument będący np. metodyką dla projektów finansowanych ze środków publicznych. Po co tworzyć ustawowy proces tworzenia systemów teleinformatycznych?

Wydaje mi się, że stwierdzenie czy jakikolwiek dokument spełnia ustawowe “minimalne wymagania dla systemu teleinformatycznego” jest niemożliwe bo jak? Jakim testem? Co miało by być wzorcem dla audytu?

Ma jednak sens moim zdaniem, by wymagania na systemy były dokumentowane w postaci testów akceptacyjnych. Te są wymierne i “zerojedynkowe”. Nie udawałoby się prawnikom dostawców oprogramowania wykazywać zgodności dostarczonego oprogramowania z wymaganiami w postaci OPZ (Opis Przedmiotu Zamówienia) w brzmieniu np. “system ma być wygodny w użyciu” bo każdy go jakoś tam jest wygodny. Należało by w drodze takich testów stwierdzić, czy oprogramowanie daje pożądane efekty. Tu nie będzie pola do popisu dla interpretacji prawnych, często niejednoznacznych zapisów w OPZ-tach.

I na koniec: ustawodawca w moich oczach wykazuje, że nie ma kompetencji by tworzyć prawo. Zamiast tworzyć reguły, zaczyna opisywać konkretne metody ich realizacji a to zły kierunek. Po drugie te zbyt szczegółowe regulacje w ustawach wyglądają często na efekty złego lobbingu dostawców technologii. Może warto, by przy rządzie powstał jakiś THINK TANK ukierunkowany na systemowe, całościowe podejście do IT w administracji publicznej. Myślę, że Analiza Systemowa i [[Architektura Korporacyjna]], jako całościowe podejście, a nie lokalne w poszczególnych urzędach, jest na to sposobem. Niestety chyba nie mamy w rządzie kompetentnych ludzi…

Czytaj dalej Czym zajmuje się ustawodawca w IT

Mega projekty czyli jak zjeść słonia

Uszczegóławianie wymagań odkładamy “na ostatni moment”. W ten sposób “kwartał po kwartale” doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może “wylecieć” z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów.

Pierwszy etap ma pewną cechę: tworzy jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem.

Dlatego z reguły nie mają sensu:

wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM),
projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian),
mega projekty ERPII czyli “all in one” dla firmy w ramach jednego projektu.
Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku…

Czytaj dalej Mega projekty czyli jak zjeść słonia

Czym się różni PlantUML i Mermaide od narzędzi CASE

Wprowadzenie Często jestem pytany: "Panie Jarku, czy Pan używa AI?". Tak, np. do szybkiego przeglądu publicznie dostępnych popularnych treści. Np. zadałem tytułowe Copilotowi. Tak odpowiedział: "PlantUML i Mermaid różnią się…

Czytaj dalej Czym się różni PlantUML i Mermaide od narzędzi CASE

Dlaczego projekty IT tak często się nie udają

Zależnie od szacunków (czyli od tego jak zdefiniowano sukces) 60 - 80% projektów IT to nieudane projekty. Pod pojęciem projektu IT rozumiemy tu systemy dla firm: szeroko pojęte systemy biznesowe.…

Czytaj dalej Dlaczego projekty IT tak często się nie udają

Żywa Dokumentacja

Czym jest Żywa Dokumentacja Jakie są najczęstsze problemy w nieudanych projektach? […] 83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania…

Czytaj dalej Żywa Dokumentacja