wymagania na oprogramowanie

Read more about the article 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 dalejUser Stories, czym jest?
Read more about the article 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 dalejInżynieria wymagań
Read more about the article Analiza wymagań – zrozumienie

Analiza wymagań – zrozumienie

Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać "jaki ma być ten program", bo popycha projekt w stronę chaotycznych oczekiwań. I tu  jest sedno: analiza nie powinna być tylko pasmem wywiadów, którego produktem będę setki stron zapisów z ankiet i przeprowadzonych rozmów. Analiza, to duża praca, której celem powinno być zrozumienie a nie tylko opisanie. (Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie). Wymagania najczęściej dzielimy na funkcjonalne i…

Czytaj dalejAnaliza wymagań – zrozumienie

Recepta na porażkę

recepta na porażkę: Wymagania zbieraj wyłącznie jako efekt burz mózgów i wywiadów z przyszłymi użytkownikami oraz ich przełożonymi, niech wszyscy spiszą je w postaci tabeli np. w arkuszu kalkulacyjnym i edytorze tekstu. Organizuj długie spotkania warsztatowe, po których powstają kolejne wiersze w tabelach. Wszystkie dodatkowe ustalenia załatwiaj mailem ad-hoc. Tak powstałą listę nazwij Wymagania i daj do realizacji. Projekty informatyczne to zawsze nowy cel i nowa droga ale dobrze znane środowisko. Dlatego wzorce jak najbardziej mają sens, ale nie recepty bo te tu nie mają zastosowania. Antywzorce, hm..., znamy statystyki i mimo to stale podejmowane sa nowe projekty, w których kluczową metodyką pracy jest warsztat-dyktafon, to czy zapisujemy to jako slajdy prezentacji czy z pomoc nawet bardzo dobrego narzędzia CASE nie ma żadnego znaczenia jeżeli faktycznie zapisujemy jedynie to, opis i obrazki, co podyktuje Święty User. Na zakończenie jedno zdanie: pojawienie się metod zwinnych (rok 2001, Agile Manifesto) nie zmieniło tej czarnej statystyki nawet o jotę, więc nic wskazuje na to, że są one w czymkolwiek lepsze. Wiadomo zaś, że stosowanie metod formalnych jest bardzo skuteczne ale kosztowniejszej od opisanych wyżej maili, arkuszy i tekstów. Jednak jeżeli średnie przekroczenie kosztów dochodzi do 200% to znaczy, że jednak metody formalne są per saldo znacznie tańsze... a są stosowane tam, gdzie "ryzyko jest duże" a przynajmniej ryzyko nie jest ignorowane. Czemu jednak tak rzadko stosuje się metody formalne? Bo jest różnica pomiędzy wiedzieć a umieć... Jeżeli więc ktoś mówi, "nie rób tego tak, bo to się raczej nie uda" (powyższe statystyki) to warto tego posłuchać i zapytać o pozostałe 20% bardziej udanych projektów.

Czytaj dalejRecepta na porażkę
Read more about the article Utopia – czyli model ideału pomaga w projektach

Utopia – czyli model ideału pomaga w projektach

Ten wpis adresuję przede wszystkim menedżerom nie tylko IT. Analitycy i programiści spokojnie mogą go pominąć, chyba, że ...;) chcą wiedzieć dlaczego powinny powstawać idealne projekty, kiedy mogą czasem wykonać niekoniecznie idealną implementację i dlaczego nie należy pomijać etapu idealnego projektowania. [...] Na zakończenie przyznam, że wśród moich niedoszłych klientów i programistów mam wielu wrogów. To Ci, którzy uważają, że analizy i projektowanie całości (co by tu słowo całość nie miało oznaczać) na samym początku są bez sensu, bo i tak wymagania biznesu się zmienią, więc i program będzie się zmieniał. Ja wtedy pytam: zmieniał czy rozszerzał? Jeżeli wymagania się zmieniają to raczej sygnał, że nie zostały na początku przemyślane... Biznes także ma skłonności do zaciągania opisywanego długu... Na koniec w kwestii wrogów pół żartem i pół serio: Chińczycy hołdują powiedzeniu: ?jak posiedzisz wystarczająco długo nad brzegiem rzeki, to zobaczysz trupy swoich wrogów płynące z prądem". No więc sobie siedzę. ... i nie raz je oglądam... a siedzę sobie analizując i projektując... ;) i nie jestem tu sam...

Czytaj dalejUtopia – czyli model ideału pomaga w projektach

Gdzie się realizują wymagania

Bardzo często spotykam, pewnie nie ja jeden, specyfikacje wymagań zawierające zapisy "oczekiwań użytkowników". Bardzo często słyszę także, że to przyszły użytkownik oprogramowania powinien być źródłem wymagań. nic bardziej błędnego.. [...] Więc np. wymaganie "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" (także cytat z pewnej specyfikacji systemu CRM) jest pustym stwierdzeniem. Po pierwsze jak te rabaty są naliczane, po drugie czy aby na pewno mechanizm pozwala na "dowolne rabaty"... Jak to opisać? Tu powinny się pojawić np. tablice decyzyjne a nie lakoniczne "dowolne rabaty". Na zakończenie uwaga: jeżeli planujemy kupić gotowe oprogramowanie, to ono już (gdzieś tam) istnieje, i specyfikowanie szczegółów opisujących dokładnie elementy pracy z interfejsem użytkownika i enigmatyczne opisy tego jak "system liczy", jest bezwartościowe. Raczej wywoła listę tak zwanych kastomizacji (zwanych gdzieniegdzie zabójcami projektów :)). Tak jednak właśnie wyglądają najczęściej specyfikacje pisane rękami przyszłych użytkowników: opiszą oni to z czym się stykają i co znają ale w ogóle nie opiszą wnętrza, którego najczęściej po protu nie rozumieją (i nie muszą bo to nie ich rola), wtedy specyfikacje systemów CRM pisane rękami przyszłych użytkowników - np. sprzedawców - zawierają właśnie bezwartościowe zapisy w rodzaju: "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" a nie zawierają opisu jak te rabaty wyliczać. Odpowiadając na tytułowe pytanie: wymagania (funkcjonalne) realizują się w modelu dziedziny systemu, którego nie zawiera większość znanych specyfikacji wymagań... a warunkiem poprawnego wyboru oprogramowania są oczekiwania co do efektów przetwarzania.

Czytaj dalejGdzie się realizują wymagania
zmiany vs. stagnacja

Tablice decyzyjne – fakty a nie procesy

Tak więc, reguły biznesowe to ogólno-organizacyjne ograniczenia. Tablice decyzyjne to rodzaj "wiedzy" wpisanej w punkty podejmowania decyzji. Na modelach (diagramach) procesów biznesowych modelujemy jedynie skutki, czyli reakcje na podjęte - zgodnie z tablicą - decyzje. Gdyby modelować powyższe na diagramie np. BPMN, mielibyśmy bramkę z czterema wyjściami, każde wyjście reprezentował by wiersz Działań. Jak widać spodziewać się należy tu bramek XOR (alternatywa wyłączna) lub OR (alternatywa "zwykła"). Na diagramach BPMN za bramką byłyby czynności nazwane tak jak działania w wierszach. Aby nie komplikować nazewnictwa tych diagramów, tablica decyzyjna użyta z diagramem BPMN miała by wiersze Działań nazwane np. odpowiednio Wariant-1, Wariant-2 itd. a czynności były by umieszczone już na diagramie. Tego typu tablice doskonale nadają się do modelowania systemów rabatowych, lojalnościowych, wartości kredytów kupieckich, wag scoringu kredytów i wielu innych, w których kombinacje skończonej liczby czynników tworzą deterministyczną, skończoną liczbę dopuszczalnych zachowań. Na diagramie procesu powołujemy się wyłącznie na nazwę tablicy (np. kojarząc ją z konkretną czynnością) zamiast modelować skomplikowane przebiegi. Dlaczego? Bo warto pamiętać, że decyzja - nawet bardzo skomplikowana - nie jest procesem a zaistniałym faktem, odpowiedzią na zastane warunki Jak widać, reakcja kierowcy na sygnalizator, to nie proces a fakt. Jest to konkretna reakcja na konkretną kombinację kolorów świateł na sygnalizatorze. W przypadku analizy wymagań, stosowanie tablic decyzyjnych, jako narzędzia specyfikowania pewnych zachowań systemu, jest bardzo wygodne bo po pierwsze: jest jednoznaczne, po drugie tablice decyzyjne to już standardowe narzędzie w inżynierii oprogramowania i nie trzeba wymyślać ich implementacji (np. w postaci maszyny stanowej: reguły to zdarzenia a działania do przejścia).

Czytaj dalejTablice decyzyjne – fakty a nie procesy
Read more about the article Ile tego ma być … analiza i model procesów biznesowych

Ile tego ma być … analiza i model procesów biznesowych

Tak więc analiza organizacji i opracowanie jej modelu to trudna, praca, nie raz długa, ale nie powinny to opasłe księgi. Dobry model organizacji to właśnie broszurka, która odpowiada na pytanie "dlaczego". Jeżeli wynikiem analizy są opasłe księgi to znaczy, że mamy jedynie dziesiątki nagrań kolejnych partii szachów a nie reguły tej gry... a wtedy nadal nie wiemy "dlaczego". Co ciekawe, każda organizacja ma, lub powinna mieć, taką instrukcję: jest to lista stanowisk (struktura organizacyjna) i reguły gry w postaci wewnętrznych zarządzań i procedur. Ale powinna ona być spójna i kompletna. Przypomnę, że każda organizacja jakoś funkcjonuje, a mało która ma mapy procesów biznesowych. Po co więc te modele procesów? Wróćmy do wspomnianej na początku "piramidy". Jej szczyt to cele, model biznesowy: chcemy grać w szachy i wygrywać. Jej najniższa warstwa to figury i reguły gry. Czym jest środkowa warstwa, czym są te modele procesów biznesowych? Dobry szachista ma pewne z góry przewidziane scenariusze, są to "gotowe" rozwiązania na pewne powtarzająca się sytuacje na szachownicy. One oczywiście nie są w stanie zastąpić szachisty, ale bardzo ułatwiają mu grę, raz przećwiczone i uznane za "dobre" i skuteczne scenariusze, stosuje zawsze gdy napotka "standardową sytuację". Organizacje także je mają, to właśnie procesy biznesowe, ale nie jest to recepta na pracę firmy, takiej nie jesteśmy w stanie stworzyć. Procesy biznesowe, te udokumentowane by służyły firmie, to wszystkie te przewidywalne, powtarzające się scenariusze, które stanowią tak na prawdę nasze organizacyjne know-how. Cała reszta to kompetencje naszych pracowników a tych nie modelujemy, z nich korzystamy.

Czytaj dalejIle tego ma być … analiza i model procesów biznesowych
Dom bez planów

Proces zbierania i analizy wymagań u developera

Analiza Biznesowa i specyfikacja wymagań opracowana metodą opisywaną tu i na stronach OMG, jest od tej ostatniej (grupa konsultantów i sesje warsztatowe) znacznie tańsza. W czasie trwa podobnie, jednak robi to z reguły jedna osoba (tak! ale przy założeniu ma stosuje zaawansowane narzędzia CASE nie tylko do tworzenia diagramów ale także do ich weryfikacji śladowania zarządzania spójnością modeli itp.), a efektem jest projekt logiczny a nie dopiero lista wymaganych cech. Korzyść jest więc podwójna. Jeżeli zrobi to Analityk wynajęty przez Klienta a nie Dostawcy, to wszelkie prawa (know-how) do projektu pozostają po stronie nabywcy. Można powiedzieć, że to trudne i kosztowne. Trudne owszem, wymaga doświadczenia i wiedzy zarówno z zakresu zarządzania jak i inżynierii oprogramowania. Per saldo, wliczając w to koszty modyfikacji na etapie wdrażania i odkrywania wymagań (wady specyfikacji nie poddającej się weryfikacji) jest to proces zawsze tańszy (badania kierowników projektów wskazują, że zła jakość wymagań generuje dodatkowe koszty rzędu 60% wartości projektu, koszt takiej analizy nie przekracza zaś 20%). Do tego pojawiają się potencjalne koszty nieujawnione klientowi: prawa autorskie do projektu i aplikacji. Jeżeli firma będąca wykonawca oprogramowania robi analizę swojego klienta i potem mu sprzedaje prawa do jej wyników wraz z dostarczanym oprogramowaniem, to jest to klasyczny przypadek anegdoty o konsultantach, którzy zapytani o to która jest godzina, proszą Cie o Twój zegarek, odpowiadają na pytanie która godzina i wystawiają fakturę za usługę i także za zwracany Ci Twój zegarek.

Czytaj dalejProces zbierania i analizy wymagań u developera
Read more about the article Duży monolityczny ERP czy integracja

Duży monolityczny ERP czy integracja

Tym razem krótko. Praktycznie za każdym razem moje rozmowy z potencjalnymi klientami dotykają problemu: jeden zintegrowany system ERP czy kilka dziedzinowych rozwiązań. Ja zawsze powtarzam to samo: im większy monolityczny system tym większym ograniczeniem i kosztem staje się dla firmy, tym większe uzależnienie od jednego dostwcy. Na rynku ścierają się stale dwie grupy opinii: "duży ERP jest lepszy bo od jednego dostawcy i od razu zintegrowany", kontra teza "duży ERP monolityczny wymaga wielu prac dostosowawczych i bardzo trudno zmienić w nim jedno nie ingerując w resztę". [...] "lepszym rozwiązaniem będzie wdrożenie systemów dziedzinowych i ich zintegrowanie"...

Czytaj dalejDuży monolityczny ERP czy integracja
to samo dla każdego

Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

Analiza biznesowa obejmuje wyłącznie obszar strategii i procesów biznesowych. Wdrożenie poprzedzane jest analizą całej organizacji, wydzielenie w niej niezależnych obszarów dziedzinowych (np. rachunkowość, zarządzanie procesami pracy, zarządzanie wiedzą, portal klienta, zarządzanie i sterowanie produkcją, zarządzanie procesem sprzedaży, inne). Każdy obszar cechuje się tymi trzema poziomami: strategia, procesy, realizacja. Na etapie analizy potrzeb prowadzimy audyt i modelowanie procesów. Zakładamy, że szczegóły tego ?jak pracujemy? i tak ulegną zmianie po wdrożeniu nowego narzędzia pracy, więc pomijamy je na tym etapie (zostaną określone podczas wdrożenia). Jeżeli analiza wykaże, że istnieje obszar niestandardowy w organizacji, tylko dla tego obszaru prowadzi się szczegółową analizę, gdyż w tym obszarze będzie (najprawdopodobniej) wdrażane rozwiązanie dedykowane. Tak więc zintegrowany system ERP II nie musi oznaczać "jedno rozwiązanie od jednego dostawcy". Po pierwsze trudno jest szczegółowo wyspecyfikować taki system, po drugie nie raz okazuje się, ze "systemy od wszystkiego są do niczego"...

Czytaj dalejKilka uwag na temat systemów ERP II, ich historii i metod ich wyboru
Read more about the article Modelowanie biznesowe c.d. – know-how, gdzie ono jest?
źr. Busnes Process Trends http://www.bptrendsassociates.com/

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście). Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami "utrudniającymi". Główny ciąg (oczekiwany) zaznaczono szarą strzałką. Pozostałe "atrakcje" to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma "rombów", bramek decyzyjnych bo one są cechą "procesów decyzyjnych", procedur, a te to reguły biznesowe i "wiedza o biznesie" a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że "tylko tak wolno tę pracę wykonać". Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Pojawia się rola czyli wykonawca (tu rola działu HR - opis kompetencji pracowników), on posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać "maszyny" (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.

Czytaj dalejModelowanie biznesowe c.d. – know-how, gdzie ono jest?

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy
Starsze wpisy