Czego moglibyśmy się nauczyć od naukowców?

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu...Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała jak trzeba! Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta...

Czytaj dalejCzego moglibyśmy się nauczyć od naukowców?

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Stosowanie analizy systemowej, modelowania oraz formalnych notacji do tworzenia modeli, powoduje, że wyniki analiz są daleko bardziej wiarygodne. Z reguły celem pracy analityka biznesowego czy projektanta jest opracowanie opisu rekomendowanego rozwiązania. Może nim być docelowy model organizacji czy też opis oprogramowania jakie należy dostarczyć (bo nie zawsze wytworzyć!). W procesie formalnej analizy systemowej (nie jest to analiza systemu informatycznego, to analiza dowolnego systemu), powstają modele, które testujemy. Taki model to najpierw hipoteza, a po weryfikacji, jest to opis rozwiązania (projekt tego co ma powstać). Idealną sytuacją była by taka, a której mamy narzędzia do modelowania każdej analizowanej dziedziny. W klasycznej inżynierii jest to rysunek techniczny i zasady obliczania wytrzymałości, sformalizowany system tworzenia schematów elektrycznych i elektronicznych i wiele innych (zależnie od dziedziny), notacje UML w inżynierii oprogramowania. W sferze zarządzania mieliśmy do niedawna biała plamę, teraz mamy już BMM czy ArchiMate. Moim zdaniem utrzymywanie, że można coś skutecznie analizować metodami nieformalnymi świadczy raczej o niewiedzy i braku kompetencji.

Czytaj dalejNowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Ten straszny diagram klas

Warto zwrócić uwagę na to, że diagram klas diagramowi nie równy, to samo narzędzie może posłużyć do dwóch różnych celów w tej samej dokumentacji. Widać także (mam nadzieję), że próba pokazania na jednym diagramie zarówno systemu pojęć jak i sposobu ich przetwarzania, jako informacji w systemach informatycznych, jest raczej błędnym podejściem. Wydaje mi się, że podejmowanie takich prób świadczy o niezrozumieniu różnicy pomiędzy systemem pojęciowym a modelem przetwarzania informacji. W szczególności gdy dotyczy to systemów obiektowych.

Czytaj dalejTen straszny diagram klas

Diagram klas – czyli “re-inżynieria” analizy biznesowej. C.d. model dziedziny

Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.

Czytaj dalejDiagram klas – czyli “re-inżynieria” analizy biznesowej. C.d. model dziedziny

Diagram klas czyli reinżynieria analizy biznesowej c.d. Przypadki użycia i granice systemu

Tworzenie modelu procesów ma dwa zadania: weryfikacja spójności i kompletności opisu Zamawiającego oraz stworzenie podstawy do określenia zakresu projektu i wyspecyfikowania wymagań funkcjonalnych czyli tak zwanych przypadków użycia.

Czytaj dalejDiagram klas czyli reinżynieria analizy biznesowej c.d. Przypadki użycia i granice systemu

Diagram klas czyli reinżynieria analizy biznesowej

Dlaczego podnoszę pracochłonność analizy wymagań i projektuję model koncepcyjny do testów? Ano po to by błędy i niespójności odkryć teraz, bo na etapie implementacji ich usuwanie będzie nawet 100 razy droższe. Czy takie błędy są w projektach o uproszczonych analizach biznesowych (lub wręcz pominiętych?) Ci co mają takie projekty za sobą wiedzą doskonale, że są i to prawie zawsze...

Czytaj dalejDiagram klas czyli reinżynieria analizy biznesowej

Po co dokumentować – wnioski po dyskusji na forum

Dokumentacja stanowi także element zarządzania wiedzą. Gdy nie ma dokumentacji nowy człowiek w zespole zajmuje czas kolegów, którzy muszą mu "opowiedzieć" o projekcie, jak jest dokumentacja, czyta ją sam nie obniżając efektywność pracy kolegów.Tak więc dla jasności: nie neguję typowej dla SCRUM czy XP wersji postępowania, a tylko wskazuje na sytuacje gdy preferowane są inne. Co do Agile podsumuję moje podejście: PMI czy Prince2 to dla mnie raczej formalny spis treści "projektu" ale dla każdego rzeczywistego projektu sam dobieram te elementy tego spisu, które mi pomogą i tak pojmuję zwinność projektową.

Czytaj dalejPo co dokumentować – wnioski po dyskusji na forum

Modelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje

Tak więc stosowanie formalnych notacji i zasad obniża ryzyko projektu. Nie wyeliminuje go, bo model i jego jakość zależy bardzo od jego twórcy (modelowanie to jednak sztuka a nie rzemiosło), jednak łamanie zasad lub stosowanie nieformalnych diagramów stanowi kluczowe ryzyko projektów na etapie analizy.

Czytaj dalejModelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Czytaj dalejProjektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

Specyfikacja wymagań a bezpieczeństwo

Gdybym miał coś zasugerować w kwestii opisanego na początku problemu z wyciekiem danych to wykonanie analizy obecnej funkcjonalności posiadanego oprogramowania, wskazanie wszystkich ryzykownych punktów i dopiero od tego momentu szukał rozwiązania, przy czym nie szukałbym winnego, (bo to będzie teraz trudno udowodnić i jak już wspomniano najpewniej popsuje atmosferę w firmie) a po prostu pozatykałbym jak najszybciej wszystkie dziury.

Czytaj dalejSpecyfikacja wymagań a bezpieczeństwo

Na forach czyli znowu modelowanie

Wąskim gardłem jest przejście z procesów na model dziedziny i przypadki użycia, które to tak na prawdę powinny być sprowadzone jeden do jednego do modułów (klas) wykonawczych np. widoku i kontrolera wzorca MVC (który bardzo lubię :)) a model dziedziny wchodzi jeden do jednego w Model w MVC.

Czytaj dalejNa forach czyli znowu modelowanie

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