analiza wymagań na oprogramowanie

Read more about the article Wymagania na coś dużego – w czym problem?

Wymagania na coś dużego – w czym problem?

Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły. I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów? Jak to robić lepiej? Po pierwsze nie kupować "dużych i drogich zintegrowanych systemów" bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać. Niestety nie ma prostej odpowiedzi jak to robić "dobrze". Chyba, że będzie to propozycja następującego procesu: analiza biznesowa zdefiniowanie celu zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), zmierzamy w kierunku tak zwanej [[architektury korporacyjnej]] zidentyfikować oczekiwane od oprogramowania usługi (wymagania), podzielić je na odrębne obszary dziedzinowe, dla każdego obszaru dziedzinowego poprowadzić odrębny projekt wyboru rozwiązania. wybrać rozwiązania. Zwracam uwagę drobny szczegół: wybory produktu dokonujemy na końcu, nigdy na początku!

Continue ReadingWymagania na coś dużego – w czym problem?

FURPS i SMART na widłach

Co to znaczy, że wymagania są zweryfikowane? To znaczy, że z powodzeniem przeprowadzono test polegający na wykonaniu wszystkich czynności modelu procesu biznesowego. Skąd to wiemy? Bo na wejściu modelu procesu "podano" prawdziwe dokumenty, udało się na modelu wskazać wszystkie czynności wymagane do obsłużenia tego dokumentu i nie było innych zbędnych, otrzymaliśmy taki sam rezultat (wynikowy dokument i jego stan) jak w naturze oraz na liście przypadków użycia są wszystkie te i tylko te, które były potrzebne by ten proces bez błędu przeszedł do końca. Jak to się robi? Przeczytaj o tym tu. Jeżeli dokument wymagań nie spełnia tych kryteriów, to jak sam Hume twierdzi, jest on bezwartościowy, nie niesie żadnej wiedzy gdyż poszczególne wymagania są: albo niezrozumiałe, albo zrozumiałe lecz nie uzasadnione, albo zrozumiałe i zasadne lecz banalne (np. mają być Sprecyzowane). Tak więc wiemy co to znaczy FURPS i SMART (powyższe skróty). Odbierając dokumenty analiz zadawajcie pytanie: a skąd wiemy, że te wymagania (które ktoś spisał) są FURPS i SMART i co to oznacza?

Continue ReadingFURPS i SMART na widłach
Read more about the article IIBA czyli “jak to niektórzy robią w Ameryce”

IIBA czyli “jak to niektórzy robią w Ameryce”

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem? Wczoraj na sali i w kuluarach padły między innymi takie odpowiedzi: dostawcy oprogramowania bardzo często nie potrafią takiej analizy wykonać bo nie mają wymaganych kompetencji, ale potrafią programować i tylko na to się godzą. dostawcy oprogramowania doskonale wiedzą, że istnieje ryzyko że ich produkt nie spełnia wymagań więc bardzo często nie dopuszczają do takich analiz forsując od razu wdrożenie (wręcz tępią w projektach zewnętrznych analityków!). klienci mają stale do czynienia z dostawcami a bardzo rzadko z niezależnymi analitykami i bardzo często przyjmują wiarę w to co mówią dostawcy.

Continue ReadingIIBA czyli “jak to niektórzy robią w Ameryce”