Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten artykuł to uzupełnienie opisu: Dokument jako wymaganie.

Często jestem i ja pytany o to “Jak wyjaśnić złożone rozwiązanie techniczne interesariuszom nietechnicznym?” Jak wielu mi podobnych odpowiadam: rozmawiaj dokumentami. Sponsor projektu, przyszli użytkownicy, postrzegają swoją pracę poprzez dokumenty: ich treść i układ. Zauważyli to także inni:

A Mock-up is a slightly glorified picture, so you will be answering with at least 1001 words !

Bardzo często widuję wymagania spisywane jako tak zwana lista funkcji lub funkcjonalności. Pojęcia te mają takie definicje w języku polskim:

funkcja ?zadanie, które spełnia lub ma spełnić jakaś osoba lub rzecz?, ?możliwość wykonania określonej operacji przez urządzenie lub program komputerowy?

Funkcjonalność jest definiowana jako funkcja czegoś w jakimś systemie.

(więcej…)

Czytaj dalejStruktury formularzy jako forma wyrażania wymagań

Dlaczego śladowanie wymagań jest istotne w projekcie?

Wymagania to niewyczerpany temat dyskusji, blogów i sporów w projektach. Ich śladowanie już rzadziej jest takim tematem, bo mało kto to robi, a to właśnie między innymi brak śladowania prowadzi do problemów w projekcie. Typowy problem to utrata panowania nad zakresem projektu, utrata panowania nad złożonością dokumentacji i ilości "wymagań" (cudzysłów celowo, później o powodach). W konsekwencji jakość całego projektu upada, zadowolenie sponsorów także (polecam krótki wpis: Why is requirements traceability important on a project?). Dlaczego? Bo skoro wymagania mają być FURPS i SMART, to jak to osiągnąć i jak skontrolować? Jak…

Czytaj dalejDlaczego śladowanie wymagań jest istotne w projekcie?

Gdzie są te cholerne szczegóły

Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane "walidacje" prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.

Czytaj dalejGdzie są te cholerne szczegóły

Ile jest tych wymagań na system ERP

Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli). Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów (średnie przekroczenie budżetu to ponad 60%).

Czytaj dalejIle jest tych wymagań na system ERP

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pewnie wielu z Was czeka, tak przynajmniej sugerują listy do mnie i głosy na forach, a także potencjalni klienci. Ci, których niestety czasem krytykuję, także pewnie czekają. Pokażę na prostym przykładzie, proces od analizy przez wymagania aż do projektu dedykowanego oprogramowania. Całość będzie zgodna z fazami CIM/PIM (www.omg.org/mda). Projekt dziedziny, który powstanie będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycje (zamiast dziedziczenia)  (polecam artykuł Łukasza Barana)  i DDD. Opis dotyczy każdego projektu związanego z oprogramowaniem, także gotowym np. ERP, CRM, EOD itp.

Korzystałem z opisu zasad gry w szachy zamieszczonego na WIKI:

Zasady gry w szachy ? prawidła regulujące sposób rozgrywania partii szachów. Choć pochodzenie gry nie zostało dokładnie wyjaśnione, to współczesne zasady ukształtowały się w średniowieczu. Ewoluowały one do początków XIX wieku, kiedy to osiągnęły właściwie swą bieżącą postać. W zależności od miejsca zasady gry różniły się od siebie, współcześnie za przepisy gry odpowiada Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się różnić w przypadku różnych wariantów gry, np. dla szachów szybkich, błyskawicznych czy korespondencyjnych. (Zasady gry w szachy ? Wikipedia, wolna encyklopedia).

To na co chcę zwrócić tu uwagę w szczególności, to metafora:

projektując (modelując) oprogramowanie dla człowieka, modelujemy narzędzie dla tego człowieka a nie jego samego.

Swego czasu pisałem, w artykule o nazywaniu klas,  że oprogramowanie z reguły zastępuje dotychczasowe narzędzie człowieka a nie człowieka jako takiego. Druga ważna rzecz: aktor jest równoprawnym elementem systemu (tu systemem jest organizacja z jej ludźmi i używanymi przez nich narzędziami). No to zaczynamy.

(więcej…)

Czytaj dalejPlansza do gry w szachy czyli analiza i projektowanie

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?

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ń

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ę

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

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

Przypadki użycia systemu czyli co?

Po kilku latach kolejnych doświadczeń upewniam się, że proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika. Usługa ta jednak może mieć warianty. Jaki z tego ma pożytek sponsor projektu? Koszt, projekt ma kilkanaście lub kilkadziesiąt a nie setki przypadków użycia i jest łatwiejszy w implementacji. A gdzie przypadki systemowe? Nie ma takich. Pojęcie Aktora ma jasną definicję (osoba lub inny system mający interakcję z Systemem), pojęcie przypadku użycia także (specyfikacja działań Systemu w odpowiedzi na działania aktora lub innego podmiotu "zainteresowanego" Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych definicji nie tylko psuje standard bo nie pasuje do spójnej przestrzeni nazw. Wymyślanie swoich znaczeń po protu psuje zrozumiałość, niszczy role komunikacyjną modeli (języka ich tworzenia). Niestety Pan Cockbourn jest w moich oczach takim "dorabiaczem" i psującym sens prostego i jak widać trudnego zarazem, narzędzia jakim jest model przypadków użycia systemu.

Czytaj dalejPrzypadki użycia systemu czyli co?

Koniec treści

Nie ma więcej stron do załadowania