365 Znaleziono wyniki wyszukiwania

Szukałeś: "wymagania"
Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Jeżeli jednak okaże (analiza) się, że zakup programu ma pomóc, to należy opisać wymagania jakie taki program musi spełnić (wymagania wobec produktu). Te wymagania są podstawą do wyboru gotowego, dostępnego na rynku oprogramowania, lub decyzji o napisaniu dedykowanego, jeżeli poszukiwania nie dadzą pozytywnego rezultatu (ale etap szukania gotowego powinien dla zasady mieć miejsce). Dedykowane rozwiązanie wymaga jego zaprojektowania, to można (zalecane) zrobić przed wyborem wykonawcy lub zlecić wybranemu wcześniej wykonawcy. Wariant drugi naraża nas jednak na utratę panowania nad projektem bo wykonawca będzie forsował metody budujące mu marże a potem sam sobie świadczy nadzór autorski. Wbrew pozorom, angażowanie audytora projektu, który nie jest autorem dokumentacji wymagań nie wnosi nic, a komplikuje cały proces: taki audytor może jedynie ocenić zgodność działań projektowych z dokumentacją wytworzoną przez (audytowanego) wykonawcę, a w przypadku sporu i tak tu “władzę” ma autor projektu a nie audytor.

I teraz: ogłoszenie przetargu na całość na początku tej drogi jest jak widać idiotyzmem bo nie mamy żadnej wiedzy by ocenić wynik pracy a dostawca żadnej by cokolwiek sensownie wyceniać. Pominięcie jakiegokolwiek z tych w/w opisanych etapów to podnoszenie ryzyka projektu, co mam na dzieję widać. Każde wymaganie może być zero jedynkowe na każdym z tych etapów, wystarczy chcieć i umieć. Owszem, można je dzielić na biznesowe itp… ale to tylko sztuczne podziały, po prostu podczas realizacji mamy już tylko etap i jego wymagania. (Nieudane wdrożenie systemu biznesowego – czyli uczmy się na błędach innych | LinkedIn).

I tylko tu pojawia się pytanie jak w filmie MIŚ: a może to faktycznie ma być drogie i nieprzydatne a ja zupełnie bez sensu jestem tym zdziwiony?

Czytaj dalej Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych
User Stories, czym jest?

User Stories, czym jest?

Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy… ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową.

Czyli np. “jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT”, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz “algorytm” wyliczenia podatków.

Jeżeli programista zaczyna “lepiej wiedzieć” od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie – jako developerowi – robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach “polegnie”. Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub rozwinięć tego opisu. Czy analityk może być “pracownikiem” dostawcy? Jak sądzicie?

Czytaj dalej User Stories, czym jest?
Sabotaż dokumentacyjny

Sabotaż dokumentacyjny

Wprowadzenie Dwa lata temu cytowałem: 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…

Czytaj dalej Sabotaż dokumentacyjny
Inżynieria wymagań

Inżynieria wymagań

Wymagania interesariuszy. Moja definicja interesariusza (jedna z wielu): osoba (podmiot) zainteresowana zaistnieniem produktu, na którą pojawienie się produktu ma wpływ. Nie raz jestem pytany czy interesariusz ma prawo zgłaszania wymagań. Jeżeli ma coś do powiedzenia podczas odbioru produktu to znaczy, że ma wymagania. One mogą być jednak niejawne czyli taki interesariusz nie zgłasza wymagań ale ma wpływ na odbiór produktu, należy go koniecznie zidentyfikować. Jeżeli zaś ktoś nie ma nic do gadania przy odbiorze produktu nie jest interesariuszem (ang. stakeholder, kluczem jest tu ‘holder’ czyli dysponent mający coś do powiedzenia, mający wpływ). Tak wiec interesariusz to ktoś kto, na swoim poziomie ogólności, także musi umieć określić, kiedy uzna, że produkt spełnia jego wymagania. Jak nie potrafi, ktoś musi mu pomóc…analityk :)).

I tu rola analityka. Interesariusz spisuje co mu przyjdzie do głowy swoim językiem, analityk upewnia się, że zrozumiał, doprowadza je do postaci testowalnej i klasyfikuje “wymagania” jako “źródło: konkretny interesariusz” (bo każde wymaganie musi mieć właściciela). Proszę zwrócić uwagę, że interesariuszem jest także użytkownik jeżeli tylko ma coś go powiedzenia w projekcie :).

Czytaj dalej Inżynieria wymagań
Semantic Core czyli bat na szczegóły

Semantic Core czyli bat na szczegóły

Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem?

Ten artykuł polecam “biznesowi” który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo “takie są fakty”. […] Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia “opinia prawna” oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).

Czytaj dalej Semantic Core czyli bat na szczegóły
Pojęcia, reguły i fakty czyli o czym oni mówią…

Pojęcia, reguły i fakty czyli o czym oni mówią…

Słownik pojęć (często występuje w dokumentach jako czysto polskie słowo glossariusz ;)) bywa często przedmiotem burzliwych negocjacji, bo nie raz (a w zasadzie zawsze ;)) biznes stosuje slang, w którym to samo słowo ma różne znaczenie, zależnie od kontekstu użycia. Może to mieć sens w języku mówionym gdy pełna treść wypowiedzi daje ten kontekst, ale na poziomie analizy i projektu każde pojęcie musi mieć jedno unikalne znacznie mimo braku kontekstu (tym bardziej, że np. nazwy klas nie są elementami pełnych zdań ani opowieści :)).[…] Biznes także musi zrozumieć, że ma dwa różne elementy opisu swoich działań: praca z dokumentami i tworzenie dokumentów. Jednak uznanie tego faktu to jedno, nie wierzę w to, że biznes się tego nauczy, bo nie nauczył się formalnego opisu lub modelowania procesów podczas wdrożeń ISO, jednak uważam, że biznes nie ma takiej potrzeby. Moim zdaniem od dobrego analityka nie ma ucieczki, to inna kompetencja. Nie ma ucieczki od projektantów mody mimo istnienia kobiet chcących mieć ładne sukienki i bardzo dobrych krawców. Nikt tu nikogo nie zastąpi.

Czytaj dalej Pojęcia, reguły i fakty czyli o czym oni mówią…

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