wymagania na oprogramowanie – Page 6

Co zrobić przed wyborem dostawcy usług IT?

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

Jednak powyższy fragment, waga procesu opisu wymagań, stanowi tylko 8% całości tekstu, którego autorem jest firma dostarczająca dedykowane rozwiązania. Dlaczego? Może rzecz w tym, skoro analiza potrzeb (patrz powyżej) powinna być wykonana przed wyborem rozwiązania i jego dostawcy to wniosek nasuwa się sam: nie robi tego ten dostawca i słusznie. Tak więc z dużym prawdopodobieństwem można przyjąć, że "określanie potrzeb" nie jest mocną stroną firm, które dostarczają konkretne rozwiązania :). Skoro więc "Punktem wyjścia w procesie doboru dostawcy usług IT jest precyzyjne określenie własnej potrzeby w tym zakresie ", to gorąco zachęcam Państwa do precyzyjnego określania swoich potrzeb przed wyborem partnera, który je zrealizuje.

Raport: Zarządzanie wymaganiami 2011

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

Ponad 80% projektów programistycznych ma przekroczone termin i budżet. Największą trudnością w tych projektach okazało się jasne zrozumienie tego, czego tak naprawdę klient potrzebuje, oraz udokumentowanie jego wymagań. Do przechowywania wymagań użyty był głównie word i excel oraz email. Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. ( 2011 State of Requirements Management Report.) Jak widać brzmi znajomo z dwóch powodów: problemy znane każdemu i powody niestety także. Ciśnie mi się na usta "a nie mówiłem"... Czyli jednak wiemy że problemem projektów z zakresu inżynierii oprogramowania są zbyt proste metody i narzędzia zarządzania wymaganiami (pakiet biurowy), które w większości są stosowane. Wiemy, że modelowanie jest najskuteczniejsza metodą analizy i projektowania a mimo to nie stosuje się tych metod szukając stale "drogi na skróty". Dlaczego dostawcy oprogramowania nie stosują metod powszechnie jednak uznawanych za skuteczne?

FURPS i SMART na widłach

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

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?

Urzędnikom i ustawodawcy zawdzięczamy utratę 100 mln euro

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

Koszt analizy i opracowania to ok. 20% wartości implementacji i mieści się nie raz nawet w kwocie nie wymagające przetargu (co istotnie skraca czas całości). Po drugie mając projekt, wycena implementacji nie jest już wróżeniem z fusów z narzutem 200-500% na wszelkie niewiadome (powszechna praktyka wielu firm developerskich, z bożej łaski integratorów). Zlecenie całości (analiza, projektowanie, wykonanie) jednej firmie nie raz kończy się tak: Wykonawca został wybrany w trybie zamówienia z wolnej ręki, ze względu na ochronę praw wyłącznych firmy Sygnity SA. Wykonawca został wybrany zgodnie z prawem polskim, natomiast zastrzeżenia Komisji wynikają z faktu, że w owym czasie polskie prawo nie było dostosowane do unijnego

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

Post author:Jaroslaw Zelinski
Post published:28 April 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Dlaczego takich analiz wykonuje się mało? No cóż, nie są one w interesie dostawcy, który twierdzi, że jego system np. ERP jest "na pewno dobry". Po drugie wiele firm uznaje, że ich nie dotyczy ryzyko projektowe i pomijają analizy, a te są przecież niczym innym jak obniżeniem ryzyka niepowodzenia takich projektów. Pamiętajmy, że ponad 80% projektów wdrożeniowych w IT to projekty z silnie przekroczonymi budżetami i terminami, część z nich (szacuje się je na ok. 16%) to projekty zaniechane z tego powodu. Każdy z Państwa sam musi sobie odpowiedzieć na pytanie: czy 20% budżetu jest warte tego by chronić pozostałe 80%.