Specyfikacja oprogramowania. Inżynieria wymagań. Wydanie III Karl Wiegers, Joy Beatty

Recenzje książki: Specyfikacja oprogramowania. Inżynieria wymagań. Wydanie III (2) Poniższe recenzje mogły powstać po przekazaniu recenzentowi darmowego egzemplarza poszczególnych utworów bądź innej zachęty do jej napisania np. zapłaty.

1. Recenzja: Programista Magazyn 01/2015 Rafał Kocisz

   Recenzja dotyczy produktu: ksiązka drukowana

   Czy recenzja była pomocna:

    TAK  (0)  NIE  (0)

   Specyfikacja oprogramowania. Brrrr...Zmora każdego programisty. Każdy z nas chciałby, aby wymagania dotyczące programów, które tworzymy, były jasno określone, klarowne, jednoznaczne, spójne. Kłopot w tym, że prawie nigdy nie są. Faktem pozostaje, że – czy nam się to podoba, czy nie – definiowanie wymagań jest integralną częścią procesu wytwarzania oprogramowania. Pomimo że inżynieria wymagań jest bardziej domeną analityków biznesowych niż programistów, jako profesjonalni rzemieślnicy, którzy podchodzą bardzo odpowiedzialnie do swojej pracy, chcemy nieustannie doskonalić się w swoim fachu – zarówno w tych aspektach, które są nam bliskie (programowanie!), jak i w tych mniej lubianych, aczkolwiek nie mniej ważnych. Dlatego uważam, że każdy szanujący się programista powinien przeczytać chociaż jedną książkę na temat specyfiowania wymagań. Dziś, w ramach Klubu Dobrej Książki, chciałbym zaproponować związaną z tym tematem pozycję, która w mojej opinii warta jest uwagi. 
   
   Na wejściu trzeba jasno powiedzieć, że Specyfiacja oprogramowania… to książka wymagająca. Tytuł ten w zasadzie przeznaczony jest dla osób pracujących na stanowisku analityka biznesowego. Jednakże jej lektura niewątpliwie będzie bardzo cenna dla każdego programisty z kilku powodów. Dla tych, którzy pracują przy dużych projektach, przyswojenie sobie wiedzy
   
   omówionej w książce autorstwa Karla Wiegersa oraz Joy Beatty pomoże niewątpliwie łatwiej odnaleźć się w dżungli wymagań, która jest nieodłącznym składnikiem tego rodzaju przedsięwzięć. Dzięki tej wiedzy będziemy w stanie lepiej komunikować się z innymi członkami zespołu, przede wszystkim z analitykami biznesowymi oraz właścicielami produktów. Z kolei w przypadku programistów pracujących w mniejszych grupach, czy wręcz wytwarzających oprogramowanie indywidualnie, omawiana pozycja będzie nieocenionym źródłem wiedzy dotyczącej inżynierii wymagań, którą z miejsca da się zastosować w praktyce.
   
   Specyfiacja oprogramowania… podzielona jest na pięć części:
   

   
   
   • Wymagania dotyczące oprogramowania. Co, dlaczego i kto,
   
   
   • Opracowywanie wymagań,
   
   
   • Wymagania w różnych klasach projektów,
   
   
   • Zarządzanie wymaganiami,
   
   
   • Implementacja inżynierii wymagań.
   
   

   
   Przyjrzyjmy się nieco bliżej wymienionym wyżej częściom. Część pierwsza: „Wymagania dotyczące oprogramowania. Co, dlaczego i kto?”, jest de facto słownikiem pojęć podstawowych dotyczących inżynierii wymagań. Znajdziemy tu odpowiedzi na pytania w rodzaju: czym są wymagania?, jaka jest rola użytkownika oraz analityka biznesowego w definiowaniu wymagań?, jakie są podstawowe dobre praktyki związane z gromadzeniem wymagań. 
   
   Część druga: „Opracowywanie wymagań”, to rozbite na piętnaście rozdziałów, dogłębne kompendium wiedzy omawiające proces definiowana wymagań przy wytwarzaniu oprogramowania. Kluczowe tematy poruszone w tej części to: 
   

   
   
   • Określanie wymagań biznesowych,
   
   
   • Pozyskiwanie wymagań,
   
   
   • Interakcja z użytkownikiem w odniesieniu do defiiowania wymagań,
   
   
   • Dokumentowanie wymagań,
   
   
   • Obrazowanie wymagań,
   
   
   • Specyfiowanie wymagań danych,
   
   
   • Specyfiowanie wymagań niefunkcjonalnych,
   
   
   • Określanie priorytetów wymagań,
   
   
   • Walidacja wymagań.
   
   

   
   Punkt trzeci omawia z kolei aspekty inżynierii wymagań dotyczące specyfiznych klas projektów: zwinnych, ulepszających i zastępujących, bazujących na gotowych rozwiązaniach, zlecanych na zewnątrz, dotyczących automatyzacji procesów biznesowych oraz analityki biznesowej. 
   
   Lektura części czwartej oraz piątej to skok na głęboką wodę: zawierają one szczegółową analizę procesów zarządzania wymaganiami oraz sposoby implementacji inżynierii wymagań. Adresatami umieszczonych tam treści są niewątpliwe zawodowi analitycy biznesowi. Fragmenty książki, które najbardziej przypadły mi do gustu (i podejrzewam, że będą najbardziej interesujące dla osób zajmujących się programowaniem), znajdują się w pierwszej i drugiej części opracowania. Lektura części pierwszej daje bardzo dobry, przekrojowy pogląd na tematykę inżynierii wymagań. Część druga napakowana jest za to konkretną, twardą i praktyczną wiedzą dotyczącą ww. dziedziny, opisaną szczegółowo, a jednocześnie bardzo przystępnie. Z racji tego, że w ramach mojej pracy zawodowej niemalże na co dzień mam do czynienia z projektami zwinnymi, bardzo zaciekawił mnie rozdział dotyczący gromadzenia wymagań w tego rodzaju przedsięwzięciach.
   
   Z kolei ostatnie dwie części książki czytałem z dużym trudem. Zawarta w nich wiedza jest niewątpliwie bardzo cenna, aczkolwiek przeznaczona raczej dla doświadczonych analityków biznesowych.
   
   Podsumowując: jeśli w ciągu całej swojej kariery programistycznej zdecydujesz się przeczytać jedną książkę dotyczącą inżynierii wymagań, to omawiany tu tytuł jest dobrym kandydatem. Lektura tego opracowania to dość droga inwestycja (głównie w ujęciu czasowym), jednakże niewątpliwe w szerszej perspektywie zwróci Ci się z nawiązką.
   
   

2. Recenzja: Quale Karolina Zmitrowicz

   Recenzja dotyczy produktu: ksiązka drukowana

   Czy recenzja była pomocna:

    TAK  (0)  NIE  (0)

   O powodzeniu każdego przedsięwzięcia decydują solidne podstawy. Nie inaczej jest w przypadku tworzenia oprogramowania. Niewłaściwe określanie wymagań, niewystarczające wsłuchiwanie się w potrzeby użytkowników mogą skutkować uzyskaniem nieprzydatnego produktu. Jak uniknąć błędów? Na czym polega zadanie analityka? Jak skutecznie pozyskiwać wymagania i właściwie nimi zarządzać? Odpowiedzi na te pytania dostarcza książka Specyfikacja oprogramowania. Inżynieria wymagań autorstwa Karla Wiegersa i Joy Beatty.
   
   Publikacja ta, będąca swego rodzaju „biblią dla analityków”, doczekała się już trzeciego wydania. W informatyce dekada to niemal wieczność, a niemal tyle czasu minęło od ostatniej edycji Specyfikacji oprogramowania. Autorzy dostosowali zatem zawartość książki do współczesnych realiów, uwzględniając rozwój branży IT, zmiany dotyczące zarządzania projektami czy nowe narzędzia pomocne w inżynierii wymagań.
   
   Co znajdziemy w książce?
   
   Tekst Specyfikacji oprogramowania podzielono na pięć części.
   
   Przedmiotem części I (Wymagania dotyczące oprogramowania. Co, dlaczego i kto?) są ogólne zagadnienia dotyczące inżynierii wymagań. Autorzy wyjaśniają w niej, jaki jest cel tworzenia dokumentacji i kto uczestniczy w tym procesie. Krótko charakteryzują najważniejsze problemy towarzyszące inżynierii wymagań, a także opisują korzyści płynące z dbania o jakość specyfikacji. Przedstawiając rolę klienta w procesie pozyskiwania wymagań, Wiegers i Beatty m.in. wymieniają jego prawa i obowiązki. Następnie opisują dobre praktyki w inżynierii wymagań oraz dość wyczerpująco wyjaśniają funkcję analityka biznesowego, skupiając się na jego pożądanych cechach.
   
   W II części (Opracowywanie wymagań) autorzy przedstawiają cały proces specyfikacji oprogramowania. Rozpoczynają od zidentyfikowania wymagań biznesowych, następnie podkreślają potrzebę poznawania oczekiwań przyszłych użytkowników wobec produktu. Podpowiadają, jak rozstrzygać spory, do jakich dochodzi na tym etapie prac nad specyfikacją. W kolejnym rozdziale przedstawiają różne sposoby pozyskiwania wymagań, zwracają uwagę na kluczowe zagadnienia i pułapki czyhające na analityków. Następnie skupiają się na opracowywaniu przypadków użycia, podkreślając przy tym potrzebę podejścia do funkcji oprogramowania z perspektywy przyszłego użytkownika, a więc skupienia się na tym, by produkt był praktyczny. Kolejne rozdziały dotyczą reguł biznesowych i związanych z nimi ograniczeń, a także dokumentowania wymagań. Bardzo pomocy jest zamieszczony w książce szablon. Autorzy krok po kroku budują dokument dotyczący wymagań. Następnie wymieniają cechy idealnych wymagań oraz techniki przedstawiania ich. Nie od dziś wiadomo, że obrazy są bardziej uniwersalne (i niekiedy czytelne) od słów. Dlatego też w rozdziale 12. zamieszczono różne graficzne sposoby przedstawiania wymagań: od diagramów po tabele. Kolejne zagadnienia opisane w książce to m.in. modelowanie relacji między danymi, zwrócenie uwagi na jakość oprogramowania (autorzy proponują specyfikowanie wymagań dotyczących jakości za pomocą języka Planguage), prototypowanie, priorytety oraz walidacja wymagań. Następnie Wiegers i Beatty wyjaśniają, dlaczego warto dbać o wysoką jakość tworzonych wymagań – można będzie korzystać z nich w kolejnych projektach. Na koniec przedstawiają pozostałe zagadnienia związane z wymaganiami: koszty, miejsce specyfikowania w harmonogramie prac nad oprogramowaniem czy rolę wymagań np. w procesie pisania kodu i testowania.
   
   Temat części III w zasadzie jest zawarty w jej tytule: Wymagania w różnych klasach projektów. Autorzy w pierwszej kolejności opisują cechy wymagań w projektach zwinnych, wskazując różnice między metodykami agile’owymi i klasycznym podejściem do tworzenia oprogramowania. Podkreślają przy tym jeszcze większą potrzebę wsłuchiwania się w oczekiwania użytkownika (np. w podrozdziale dotyczącym epik i opowieści użytkownika). Następnie skupiają się na wymaganiach w projektach ulepszających i zastępujących czy bazujących na już istniejących produktach. Kolejne zagadnienia poruszane w części III to zalety outsourcingu, offshoringu czy nearshoringu oraz związane z nimi zagrożenia. Następnie Wiegers i Beatty przedstawiają projekty automatyzacji procesów biznesowych, projekty analityki biznesowej i m.in. projekty systemów wbudowanych.
   
   W części IV (Zarządzanie wymaganiami) autorzy skupiają się na metodach wydajnej pracy z wymaganiami. Zwracają uwagę m.in. na konieczność dbania o kontrolowanie wersji czy spójność poszczególnych dokumentów. Następnie przedstawiają zagadnienia związane ze zmianami wymagań, np. kontrolowanie zmian czy analizę ich wpływu. Rozdział 29. dotyczy w głównej mierze śledzenia wymagań, a kolejny – zamykający część IV – zawiera opis narzędzi służących do opracowywania wymagań i zarządzania nimi.
   
   Przedmiotem ostatniej, V części (Implementacja inżynierii wymagań) są, ogólnie rzecz biorąc, dwa zagadnienia: ulepszanie procesów inżynierii wymagań oraz zarządzanie ryzykiem.
   
   Książka zawiera ponadto trzy dodatki. Pierwszy (A) składa się z 20 pytań pomagających wybrać optymalne dla danego projektu/przedsiębiorstwa techniki inżynierii wymagań, a także wskazać elementy (np. dotyczące analityków czy klientów) wymagające poprawy. Dodatek B zawiera kilkanaście tabel. Zebrano w nich najważniejsze problemy związane z wymaganiami, ich możliwe przyczyny oraz rozwiązania. W dodatku C zamieszczono kilka przykładów dokumentów dotyczących wymagań.
   
   Na końcu książki znajduje się przydatny słowniczek pojęć.
   
   Duża łyżka miodu
   
   Książka jest napisana prostym, przystępnym językiem. Poszczególne zagadnienia autorzy opisują niemalże od podstaw, dzięki czemu zrozumieją je nawet osoby na co dzień niezwiązane z branżą IT czy analizą wymagań.
   
   Struktura książki jest przemyślana i czytelna. Prawie każdy z rozdziałów rozpoczyna się historyjką wprowadzającą czytelnika w temat. Poprzedza ona krótki wstęp, po którym znajdują się podrozdziały zawierające szczegółowe rozważania. Najistotniejsze informacje umieszczono w ramkach opatrzonych trójkątem z wykrzyknikiem. Tekst urozmaicają Prawdziwe historie (oznaczone symbolem książki) – opisy doświadczeń autorów. Wiegers i Beatty przestrzegają również czytelników przed skutkami pewnych nieprzemyślanych działań (Pułapka). Większość rozdziałów kończy ramka Następne kroki, pomagająca zastosować teorię w praktyce. Zawiera ona ćwiczenia do wykonania przez czytelnika.
   
   Łyżeczka dziegciu
   
   Mankamentem książki może być… grubość kartek; są one bardzo cienkie, więc w trakcie czytania zwykle widzimy również zawartość kolejnej/poprzedniej strony. Podczas dłuższej lektury okazuje się to dosyć męczące.
   
   Książka jest starannie dopracowana pod względem językowym. Jedynie rozdział 31. zawiera zaskakująco dużo drobnych usterek. Nie najlepiej wygląda również tłumaczenie niektórych pojęć z dziedziny IT, jak wspomniane epiki czy historie użytkownika. Oryginalne formy wydają się naturalniejsze.
   
   Merytoryczna wartość publikacji jest niepodważalna. Wśród nielicznych błędów można wymienić niewłaściwe tłumaczenie rozwinięcia skrótu CRUD w rozdziale 13.
   
   Dobra inwestycja
   
   Czy warto wzbogacić swoją biblioteczkę o Specyfikację oprogramowania? Z pewnością. Co więcej, to książka, do której czytelnik będzie niejednokrotnie wracać. Publikację Wiegersa i Beatty wielokrotnie już nazywano kompendium wiedzy dla każdego analityka oraz innych osób związanych z branżą IT. Kolejne wydanie Specyfikacji oprogramowania bez wątpienia nadal zasługuje na to miano.
   
   Dobra wiadomość dla miłośników nowoczesnych technologii – książka jest dostępna również w wersji elektronicznej.

więcej recenzji

ukryj recenzje