Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn: "People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you’ve worked through a set of user stories? No. Not even close!" ["Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!".](https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/) Świat od dekad boryka się…

Czytaj dalejWymagania biznesowe – jak zbierać i dokumentować

Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: "nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale". To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa... a nie raz z jego łamaniem.  Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji.…

Czytaj dalejCzy wdrożenie zawsze wymaga reorganizacji?

Wymagania biznesowe i Siatka Zachmana

Cztery lata temu pisałem o książce Ronalda Rossa "Building Business Solutions": Druga to pozycja nowa, całościowo opisująca podejście polegająca na modelowaniu organizacji w analizie biznesowej (zawiera część materiału pierwszej) . Zwraca uwagę na fakt, że nie chodzi w analizie o tworzenie mnóstwa diagramów a o to, by zrozumieć jak organizacja funkcjonuje opisując to, oraz stworzyć model, który pozwoli na prognozowanie zachowania organizacji w odpowiedzi na bodźce, nawet te które jeszcze nie zaistniały. (Źródło: Business Rule Concepts ? czyli jak ?wyłuskać istotę rzeczy? | | Jarosław Żeliński IT-Consulting) Niedawno wpadł mi w skrzynkę kolejny wpis na blogu R.Rossa: Zachman?s basic…

Czytaj dalejWymagania biznesowe i Siatka Zachmana

Systems Engineering Fundamentals by United States Government

Tak, taką książkę można nabyć na Amazonie ;). Streszczenie na stronach sprzedawcy oddaje dobrze jej treść: This book provides a basic, conceptual-level description of engineering management disciplines that relate to the development and life cycle management of a system. For the non-engineer it provides an overview of how a system is developed. For the engineer and project manager it provides a basic framework for planning and assessing system development. Ogólnie książka opisuje podstawowy koncepcyjny etap inżynierii systemów (i nie należy tego utożsamiać tylko z branżą IT). Jest napisana przystępnym językiem,…

Czytaj dalejSystems Engineering Fundamentals by United States Government

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

Nieprzewidywalne wymagania

Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają "zwinną", że "nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu, bo klient zna tylko cel i razem do niego dążymy, prototypy - tak właśnie radzimy sobie z nieprzewidywalnością wymagań". Przypomnę: wymagania to "warunki jakie coś musi spełnić aby było przydatne" (sł. j.polskiego PWN), jak mam tu rozumieć "brak wymagań na początku projektu", skoro jego - projektu - celem jest wytworzenie czegoś przydatnego? Co to znaczy "wymagania dzisiaj są nieprzewidywalne"? To…

Czytaj dalejNieprzewidywalne wymagania

Jak połączyć prywatne z firmowym w jednym urządzeniu?

Tak więc bezpieczeństwo powinno być raczej elementem wymagań w postaci "oczekiwany efekt" a nie "jak je zapewnić". Nie rozumiem dlaczego tak wielu analityków i działy IT wzbraniają się przed uznaniem, że oprogramowanie powinno być dostępne na dowolnym urządzeniu mobilnym i że nie powinno pozwalać na..., i tu określone ograniczenia. Moim zdaniem bezpieczeństwo powinno być definiowane (wymagania) poprzez ryzyka, których chcemy uniknąć w określonym, biznesowo oczekiwanym (a nawet zastanym) środowisku, a nie poprzez narzucanie konkretnego sposobu i technologii, w szczególności przymusu korzystania z konkretnego sprzętu czy oprogramowania.

Czytaj dalejJak połączyć prywatne z firmowym w jednym urządzeniu?

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ę

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

Koniec treści

Nie ma więcej stron do załadowania