May 2011 – Page 3 – JZ IT Consulting Ltd

Sprawna Inżynieria Oprogramowania – role w projekcie

Post author:Jaroslaw Zelinski
Post published:18 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

W projektach informatycznych najczęściej spotykamy: analityka wymagań (AW), analityka systemowego (AS), dewelopera w tym architekta systemu (D). W zasadzie trudno powiedzieć co jest produktem każdego z nich. Najczęściej AW dostarcza jakiś opis tego czego oczekuje klient, AS robi porządkuje to zrobił AW np. z pomocą przypadków użycia a D bierze to do ręki i musi zaprojektować i wykonać oprogramowanie. Jak widać, odpowiedzialność za to co powstanie jest rozmyta. Klient najpierw przekazuje swoje oczekiwania AW zaś otrzymuje produkt od D. Konia z rzędem temu, kto mi powie jak tego dokonać bez permanentnych iteracyjnych wyjaśnień i bombardowania Klienta pytania w rodzaju "co Państwo mieli na myśli pisząc...".

(nie)przemyślany zakup w policji

Post author:Jaroslaw Zelinski
Post published:17 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

No cóż, analiza biznesowa to nie tylko IT. Projektów z poza tej dziedziny mam mało, to raczej rodzynki. Prawdopodobnie dlatego, że "analiza wymagań" kojarzy się najczęściej z oprogramowaniem a to duży błąd. Dlaczego? Cóż, wymagania to wymagania, są uniwersalne i nie muszą być od razu "informatyczne". Ale metody analizy pozostają te same, o ile chce się je zastosować. Po co? Jak zawsze: by uniknąć ryzyka złego wyboru, złej decyzji.

Komunikacja osmotyczna czyli po Brzytwie przypadków użycia

Post author:Jaroslaw Zelinski
Post published:14 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

osobiście i bardzo subiektywnie uważam, że nawet jeśli dowolną kupę mało spójnego tekstu rozłożymy na wiersze i kolumny dowolnej ilości tabel (to się czasem nazywa czasem nadawaniem tekstowi struktury) to taki tekst nadal będzie mało spójny. Przypadki użycia jako tabelaryczna forma zapisu "user story" lub wymagań funkcjonalnych, nie uzyskają spójności poprzez sam fakt ich stabelaryzowania. Przypadki użycia zaś jako efekt analizy całości zachowań i świadomego wyboru części z nich to jest dopiero spójny i kompletny opis wymagań. Bo jak to ktoś powiedział: kompletna lista najładniejszych kobiet w danym mieście to nie lista spotkanych ładnych w ostatnim miesiącu a lista wybranych spośród wszystkich w tym mieście. Taka lista ma sens bo nie grozi nam to, ze następnego dnia w tym mieście spotkamy inna ładniejszą. Jeżeli ktoś Ci przyniesie specyfikację przypadków użycia do systemu i nie będzie potrafił jednoznacznie odpowiedzieć na pytanie dlaczego jest ich akurat tyle a nie np. jeden mniej lub dwa więcej albo dlaczego akurat te a nie inne, to najprawdopodobniej znaczy to, że podczas wdrożenia na pewno "spotkasz kilka innych ładniejszych kobiet".

Etyka w biznesie/marketingu

Post author:Jaroslaw Zelinski
Post published:14 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Jeśli okaże się, że normy korporacyjne są sprzeczne z jego normami, to jak powiedział Krzysztof, ?Take it or leave it?. Normy korporacyjne w sposób eufemistyczny nazywają to, co my nazywamy…

A na grzyba nam Pan Analityk?

Post author:Jaroslaw Zelinski
Post published:12 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Przecież analizę zrobimy sami, a jak nie - to zrobi to dostawca. Tak często rozpoczyna się tak zwana "Droga do klęski". Rzemieślnicy produkujący ?przed Kopernikiem? skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem modelu geocentrycznego i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy. Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale nie dyktafon a zaawansowane metody, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.