Bartosz Chrabski Specjalista IT pracujący w grupie oprogramowania IBM Polska. Zajmuje się projektowaniem i wdrażaniem systemów zarządzania pracą zespołów programistów, testerów analityków oraz technincznym wsparciem sprzedaży rozwiązań z rodziny IBM Rational. Autor kilkunastu publikacji z obszaru inżynierii oprogramowania, zarządzania projektami oraz prelegent licznych konferencji międzynarodowych. Karolina Zmitrowicz W branży IT niemal 10 lat. Posiada doświadczenie w zakresie analizy biznesowej i inżynierii wymagań, zarządzania jakością i zarządzania projektami: pracowała dla wiodących organizacji finansowych w Republice Południowej Afryki, Holandii, Austrii, Słowacji, Włoszech i w Polsce. Podczas swojej kariery pełniła różne role, od testera, przez technical writera, po kierownika projektów R&D, co umożliwiło jej poznanie wielu aspektów realizacji projektów IT i nauczyło postrzegania podejmowanych tematów z różnych punktów widzenia. Praca w międzynarodowych, wielokulturowych zespołach projektowych wykształciła w Karolinie nie tylko umiejętności efektywnego planowania i koordynacji złożonych działań, ale i doskonałe umiejętności interpersonalne. W pracy analityka wykorzystuje doświadczenie zdobyte podczas kilku lat pracy w obszarze zapewnienia i kontroli jakości, by stale ulepszać jakość produktów swoich prac, jak i samego procesu ich powstawania. W latach 2010-2013 Karolina zaangażowała się we wsparcie i doskonalenie systemu certyfikacji inżynierów wymagań REQB oraz była główną autorką programu IQBBA. Była także założycielką i redaktorem naczelnym magazynu c0re - kwartalnika dla testerów oprogramowania. Obecnie kontynuuje pracę redaktorską w Quale, kwartalniku traktującym o szeroko pojętej jakości w IT. W dalszym ciągu jest aktywnym członkiem kilku międzynarodowych organizacji mających na celu zwiększanie wiedzy i dojrzałości zawodowej testerów oprogramowania oraz inżynierów wymagań, wspiera również najważniejsze wydarzenia związane z jakością oprogramowania w Polsce i za granicą. Obecnie pracuje jako niezależny konsultant IT i trener w obszarze inżynierii wymagań i zarządzania jakością pomagając klientom usprawniać procesy inżynierii oprogramowania a tym samym osiągać lepsze wyniki biznesowe. Uważa, że podstawą do osiągnięcia jakości są efektywne procesy i odpowiednie podejście ludzi, a nie tymczasowe rozwiązania i modne trendy. Jest autorką szeregu specjalistycznych publikacji oraz książki obejmującej program certyfikacji w obszarze inżynierii wymagań, która wkrótce ukaże się nakładem wydawnictwa PWN.
SPIS TREŚ CI Od Autorów............................................ 11 1. Wprowadzenie do inżynierii wymagań........................... 13 1.1. Wyzwania związane z projektami IT.............................. 15 4.1. 1.1.1. Cele i wizja....................................... 16 4.1. 1.1.2. Złe planowanie projektu................................. 16 4.1. 1.1.3. Słaba komunikacja................................... 19 4.1. 1.1.4. Złe zarządzanie oczekiwaniami interesariuszy...................... 20 4.1. 1.1.5. Problemy z wymaganiami i ich zakresem........................ 21 4.1. 1.1.6. Brak umiejętności miękkich............................... 22 4.1. 1.1.7. Nierealistyczne oczekiwania............................... 23 4.1. 1.1.8. Brak zasobów ludzkich................................. 24 4.1. 1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego............. 26 1.2. Podstawowe definicje oraz klasyfikacje............................. 27 4.1. 1.2.1. Wymagania biznesowe................................. 29 4.1. 1.2.2. Wymagania interesariuszy................................ 29 4.1. 1.2.3. Wymagania rozwiązania................................. 30 4.1. 1.2.4. Wymagania przejścia.................................. 30 1.3. Atrybuty wymagań....................................... 31 1.4. Kryteria jakości wymagań................................... 34 1.5. Wymagania w procesie zapewnienia jakości oprogramowania................. 36 1.6. Inżynieria wymagań oraz jej znaczenie w projekcie...................... 37 1.7. Podstawowe role w procesie inżynierii wymagań........................ 39 1.8. Koncepcja interesariuszy.................................... 40 1.9. Standardy oraz normy..................................... 42 4.1. 1.9.1. ISO 9000........................................ 43 4.1. 1.9.2. ISO/IEC 25000 Software Engineering Software product Quality Requirements and Evaluation (SQuaRE) Guide to SQuaRE..................... 43 4.1. 1.9.3. ISO 9241........................................ 43 4.1. 1.9.4. ISO 31000: Risk Management............................. 44 4.1. v1.9.5. IEEE 610:1990: Standard Glossary of Software Engineering Terminology....... 44 4.1. 1.9.6. IEEE 828-2012: Standard for Configuration Management in Systems and Software Engineering...................................... 44 4.1. 1.9.7. IEEE 830-1998: Recommended Practice for Software Requirements Specifications... 44 4.1. 1.9.8. IEEE 1233-1996: Guide for Developing of System Requirements Specifications.... 45 4.1. 1.9.9. IEEE 1362-1998: Guide for Information Technology System Definition Concept of Operations (ConOps) Document........................... 45 4.1. 1.9.10. IEEE 29148-2011 Systems and software engineering Life cycle processes Requirements engineering............................... 45 4.1. 1.9.11. IEEE 1028:2008 Standard for Software Reviews and Audits.............. 45
6 SPIS TREŚCI 4.1. 1.9.12. SWEBOK: The Guide to the Software Engineering Body of Knowledge (ISO Technical Report 19759)............................. 46 4.1. 1.9.13. CMMI......................................... 46 4.1. 1.9.14. BABOK A Guide to the Business Analysis Body of Knowledge........... 46 1.10. Słowniki............................................ 47 2. Proces inżynierii wymagań.................................. 49 2.1. Definicja procesu........................................ 51 2.2. Inżynieria wymagań a analiza biznesowa............................ 56 2.3. Zasady tworzenia udanych wymagań.............................. 58 4.1. 2.3.1. Zrozum krytyczne cele najwyższego poziomu...................... 59 4.1. 2.3.2. Koncentruj się na dostarczeniu wartości........................ 60 4.1. 2.3.3. Zdefiniuj wymaganie jako stan końcowy o wartości dla interesariusza........ 60 4.1. 2.3.4. Wyrażaj wymagania ilościowo.............................. 61 4.1. 2.3.5. Nie mieszaj środków z celami.............................. 63 4.1. 2.3.6. Skup się na pożądanej jakości systemu, nie tylko na jego funkcjonalności........ 65 4.1. 2.3.7. Zapewnij bogatą specyfikację............................. 65 4.1. 2.3.8. Wykonuj kontrolę jakości specyfikacji.......................... 68 4.1. 2.3.9. Uznaj, że wymagania się zmieniają........................... 69 3. Inżynieria wymagań a inne procesy............................. 71 3.1. Zarządzanie projektem..................................... 73 3.2. Zarządzanie ryzykiem...................................... 77 3.3. Testowanie i zapewnienie jakości............................... 83 3.4. Wpływ wymagań na inne artefakty projektu.......................... 86 4. Inżynieria wymagań w procesach tworzenia oprogramowania........... 89 4.1. Model V jako przykład kaskadowego wytwarzania systemów.................. 91 4.2. IBM Rational Unified Process.................................. 94 4.1. 4.2.1. Zarządzania wymaganiami w IBM Rational Unified Process............... 96 4.1. 4.2.2. Przepływ prac dla wymagań w IBM Rational Unified Process.............. 97 4.1. 4.2.3. Role i artefakty w IBM Rational Unified Process..................... 99 4.3. Zwinne metodyki w zarządzaniu wymaganiami........................ 100 4.4. Programowanie ekstremalne.................................. 102 4.5. Scrum (według Scrum.org)................................... 107 4.1. 4.5.1. Rejestr produktowy, czyli metoda na zorganizowanie wymagań............. 111 4.1. 4.5.2. Wyzwania związane z migracją do Scrum........................ 114 4.6. Disciplined Agile Delivery................................... 115 4.7. Przypadek biznesowy...................................... 116 4.1. 4.7.1. Informacja o firmie i sytuacja rynkowa......................... 116 4.1. 4.7.2. Potrzeba......................................... 116 4.1. 4.7.3. Rozwiązanie....................................... 116 4.1. 4.7.4. Zyski.......................................... 117 5. Identyfikacja wymagań.................................... 119 5.1. Źródła wymagań........................................ 122 5.2. Wizja oraz cel projektu..................................... 122 5.3. Identyfikacja interesariuszy projektu.............................. 128 5.4. Techniki identyfikacji wymagań................................ 130 4.1. 5.4.1. Warsztat wymagań................................... 131 4.1. 5.4.2. Wywiad......................................... 134
SPIS TREŚCI 7 4.1. 5.4.3. Ankieta kwestionariusz................................ 138 4.1. 5.4.4. Samodzielna rejestracja................................ 142 4.1. 5.4.5. Reprezentant klienta po stronie dostawcy....................... 144 4.1. 5.4.6. Identyfikacja na podstawie istniejących dokumentów................. 147 4.1. 5.4.7. Ponowne użycie specyfikacji.............................. 150 4.1. 5.4.8. Obserwacja w terenie................................. 153 4.1. 5.4.9. Mentorowanie/praktykowanie............................. 156 4.1. 5.4.10. Burza mózgów..................................... 158 4.1. 5.4.11. Prototypowanie.................................... 163 4.1. 5.4.12. Przypadki użycia.................................... 166 4.1. 5.4.13. Scenorys........................................ 171 5.5. Wymagania funkcjonalne i niefunkcjonalne........................... 174 6. Analiza wymagań....................................... 183 6.1. Analiza problemu biznesowego................................. 186 6.2. Oganizacja wymagań...................................... 189 6.3. Powiązania i zależności między wymaganiami......................... 190 6.4. Usuwanie konfliktów i duplikatów wymagań.......................... 194 6.5. Kontrola jakości........................................ 198 6.6. Szacowanie wysiłku...................................... 198 4.1. 6.6.1. Techniki bazujące na algorytmach............................ 200 4.1. 6.6.2. Techniki bazujące na przybliżeniach........................... 207 6.7. Priorytetyzacja wymagań.................................... 210 6.8. Modelowanie rozwiązania................................... 213 4.1. 6.8.1. Model dziedziny..................................... 214 4.1. 6.8.2. Diagram przepływu danych (ang. Data Flow Diagram)................. 216 4.1. 6.8.3. Diagram związków encji (ang. Entity Relationship Diagram).............. 216 4.1. 6.8.4. Modelowanie interfejsu użytkownika.......................... 218 4.1. 6.8.5. Unified Modeling Language (UML)........................... 219 4.1. 6.8.6. System Modeling Lanuage (SysML)........................... 228 4.1. 6.8.7. Inne notacje do modelowania.............................. 231 6.9. Akceptacja wymagań...................................... 235 7. Specyfikacja wymagań.................................... 239 7.1. Pojęcie specyfikacji....................................... 241 7.2. Rodzaje specyfikacji...................................... 241 4.1. 7.2.1. Specyfikacja wymagań................................. 242 4.1. 7.2.2. Specyfikacja rozwiązania................................ 243 4.1. 7.2.3. Specyfikacja techniczna................................. 245 7.3. Szablony dla specyfikacji wymagań (na podstawie IEEE 830).................. 246 4.1. 7.3.1. IEEE 830........................................ 246 4.1. 7.3.2. Wzorzec Volere..................................... 251 4.1. 7.3.3. Historyjki użytkownika................................. 252 4.1. 7.3.4. Przypadki użycia jako sposób na wymagania funkcjonalne............... 252 7.4. Jakość specyfikacji wymagań.................................. 256 Rozdział 8. Zarządzanie wymaganiami............................. 259 8.1. Śledzenie wymagań...................................... 261 8.2. Zarządzanie Konfiguracją................................... 268 8.3. Zarządzanie Zmianą...................................... 271 8.4. Zarządzanie wymaganiami dotyczącymi projektu oraz systemu................. 275 8.5. Plan Zarządzania Wymaganiami................................ 277
8 SPIS TREŚCI 8.6. Przypadek biznesowy wdrożenie procesu zarządzania wymaganiami............. 278 4.1. 8.6.1. Informacja o firmie i sytuacja rynkowa......................... 278 4.1. 8.6.2. Potrzeba......................................... 278 4.1. 8.6.3. Rozwiązanie....................................... 279 4.1. 8.6.4. Zyski.......................................... 284 9. Wymagania a zarządzanie jakością............................. 287 9.1. Planowanie jakości....................................... 289 9.2. Kontrola jakości........................................ 295 4.1. 9.2.1. Przeglądy........................................ 296 4.1. 9.2.2. Inspekcje........................................ 304 4.1. 9.2.3. Listy kontrolne..................................... 307 9.3. Miary jakości wymagań..................................... 309 9.4. Doskonalenie procesu..................................... 311 10. Narzędzia wspierające proces inżynierii wymagań................... 315 10.1. Narzędzia w zarządzaniu wymaganiami............................ 317 4.1. 10.1.1. IBM Rational Requirements Composer........................ 317 4.1. 10.1.2. Borland Caliber RM.................................. 319 4.1. 10.1.3. Serene Dimensions.................................. 320 4.1. 10.1.4. Rational DOORS (Dynamic Object Oriented Requirements System)......... 321 4.1. 10.1.5. Blueprint Requirements Center............................ 322 4.1. 10.1.6. Open Source Requirements Management Tool/aNimble Platform........... 323 4.1. 10.1.7. Cechy dobrego narzędzia do zarządzania wymaganiami............... 324 4.1. 10.1.8. Wdrożenie narzędzia do zarządzania wymaganiami.................. 325 10.2. Czynniki mające znaczenie przy doborze odpowiednich narzędzi............... 328 10.3. Narzędzia w obszarze modelowaniu wymagań........................ 329 4.1. 10.3.1. Sparx Enterprise Architect.............................. 329 4.1. 10.3.2. IBM Rational Software Architect........................... 330 4.1. 10.3.3. StarUML....................................... 331 10.4. Narzędzia w obszarze modelowania procesów biznesowych.................. 332 4.1. 10.4.1. Boc Group Adonis................................... 332 4.1. 10.4.2. igrafx Process..................................... 333 4.1. 10.4.3. BizAgi Process Modeler................................ 334 4.1. 10.4.4. Rational System Architect.............................. 335 10.5. Narzędzia wsparcia dla zarządzania konfiguracją....................... 336 4.1. 10.5.1. GIT.......................................... 336 4.1. 10.5.2. Subversion...................................... 337 4.1. 10.5.3. IBM ClearCase.................................... 339 10.6. Narzędzia wsparcia dla zarządzania zmianami........................ 339 4.1. 10.6.1. Atlassian Jira..................................... 339 4.1. 10.6.2. IBM Rational Team Concert.............................. 340 10.7. Zarządzanie procesem testowania oprogramowania...................... 342 4.1. 10.7.1. HP Quality Center.................................. 342 4.1. 10.7.2. IBM Rational Quality Manager............................ 343 4.1. 10.7.3. Testia Tarantula.................................... 344 4.1. 10.7.4. Requirements Testing Hub.............................. 345 4.1. 10.7.5. TestLink....................................... 346 10.8. Ryzyko związane ze złym zakupem narzędzia......................... 347 Podsumowanie.......................................... 349
SPIS TREŚCI 9 Przypadki biznesowe....................................... 353 Projekt 1 - Wdrażanie procesu inżynierii wymagań......................... 355 4.1.Informacja o firmie i sytuacja rynkowa............................. 355 4.1.Potrzeba............................................. 355 4.1.Rozwiązanie........................................... 356 4.1.Zyski............................................... 361 Projekt 2 Integracja narzędzi w procesie wytwarzania....................... 362 4.1.Informacja o firmie i sytuacja rynkowa............................. 362 4.1.Potrzeba............................................. 362 4.1.Rozwiązanie........................................... 362 4.1.Etap 1 Integracja wymagań z procesem zarządzania testami................. 364 4.1.Etap 2 Integracja wymagań z zarządzaniem konfiguracją................... 365 4.1.Etap 3 Integracja wymagań z zarządzaniem zmianami..................... 366 4.1.Zyski............................................... 368 Projekt 3 Kontrola jakości wymagań na wczesnych etapach projektu............... 370 4.1.Informacja o firmie i sytuacja rynkowa............................. 370 4.1.Potrzeba............................................. 370 4.1.Skutek.............................................. 371 4.1.Przyczyna............................................ 371 4.1.Rozwiązanie........................................... 371 Projekt 4 Zarządzanie wymaganiami przy użyciu historyjek użytkownika............. 372 4.1.Informacja o firmie i sytuacja rynkowa............................. 372 4.1.Potrzeba............................................. 372 4.1.Rozwiązanie........................................... 372 4.1.Zyski............................................... 373 Bibliografia............................................ 375 Spis rysunków........................................... 377 Spis tabel............................................. 379 Indeks............................................... 380
W rozdziale wprowadzającym przedstawimy podstawowe informacje dotyczące wymagań i różnych związanych z nimi aspektów. Oprócz zestawu pojęć i zagadnienień teoretycznych niezbędnych do zrozumienia istoty dziedziny inżynierii wymagań, opiszemy również tematy poboczne, umożliwiające zrozumienie znaczenia tej dziedziny dla sukcesu przedsięwzięcia. Zacznijmy od problemów, których przynajmniej częściowe rozwiązanie zależy od jakości procesów mniej lub bardziej związanych z wymaganiami. 1.1. Wyzwania związane z projektami IT Problemy w realizacji projektów informatycznych są nieustannie wdzięcznym tematem do dyskusji omawia się je na konferencjach, szkoleniach, w prasie i innych publikacjach. Szczególnie medialne i interesujące są spektakularne porażki, odbijające się szerokim echem w środowisku IT. Ilu z nas, najczęściej po fakcie, zadaje sobie pytanie, dlaczego projekty informatyczne tak często się nie udają? Ilu z nas deklaruje, że następnym razem będzie lepiej... a następny raz okazuje się jeszcze gorszy... W zasadzie wiadomo, co robimy nie tak. Badaniem przyczyn porażek projektowych zajmują się organizacje uznane na całym świecie (m.in. Standish Group i jej słynny już Chaos Report). Informują one, że głównymi powodami problemów są m.in. niekompletne wymagania, niedostateczne zaangażowanie użytkowników, brak zasobów i wsparcia kierownictwa, nierealistyczne oczekiwania, niedoszacowane estymacje oraz problemy z planowaniem. Czynniki te nie zmieniają się praktycznie od lat. Badania innych organizacji (w tym Gartnera) również wskazują część z tych czynników jako wywierające największy negatywny wpływ na powodzenie projektów IT 1. Analizując statystyki i dostępną dokumentację, można wyciągnąć wniosek, że większość problemów występujących podczas realizacji projektów IT jest związana z samym zarządzaniem projektem. Czynniki technologiczne obciążone, zdawałoby się, najwyższym ryzykiem to zaledwie niewielki odsetek przyczyn niepowodzeń projektów. Skąd taka rozbieżność? Dziedzina zarządzania projektem istnieje w IT od wielu lat nie jest ani nowa, ani nieusystematyzowana. Istnieje wiele wytycznych, praktyk i standardów opisujących reguły dobrego zarządzania projektem. Dlaczego więc od lat tak wiele problemów występujących podczas realizacji projektów IT wynika z faktu zarządzania nimi? Czyżby odpowiedź brzmiała: ponieważ nie uczymy się na błędach? Może przyczyny problemów są wciąż te same, ponieważ nigdy poważnie ich nie zbadaliśmy. Często widzimy tylko skutki i w panice próbujemy gasić pożar, kiedy już wybuchnie, nie zastanawiając się, dlaczego pożary występują tak często i co je powoduje. Może lepiej nie budować kolejnego domu ze słomy i papieru, zamiast dziwić się, że znowu nie wytrzymał najmniejszej próby ognia? Podsumowując informacje z różnych źródeł i statystyk, można wskazać kilkanaście notorycznie powtarzających się czynników ryzyka. 1 http://www.gartner.com/technology/research.jsp.
16 WPROWADZENIE DO INŻYNIERII WYMAGAŃ 1.1.1. Cele i wizja Projektów nie realizujemy po to, żeby wyprodukować dany produkt. Z biznesowego punktu widzenia wyprodukowanie produktu nie jest celem samym w sobie realizacji projektu, projekty mają dostarczyć klientowi konkretną wartość. Produkt jest jedynie środkiem do osiągnięcia celu, jakim jest wartość. Niestety w praktyce znaczna liczba projektów charakteryzuje się kompletnym brakiem przygotowania biznesowego projekty inicjowane są bez uprzedniego zdefiniowania i analizy potrzeb, celów biznesowych oraz ryzyk. W wielu przypadkach brakuje planowania strategicznego, które pozwoliłoby organizacji określić cele i zaplanować ich realizację dzięki odpowiednim, często współzależnym projektom. Skutek? Klient nie wie, co chce osiągnąć za pomocą danego rozwiązania i jakim celom biznesowym ma ono służyć. Bardzo często projekty są realizowane po to, by wytworzyć jakiś system, choć celem projektu informatycznego nie jest sam system, ale korzyści, jakie ma dostarczać, i cele biznesowe, które ma realizować. Te cele i korzyści powinny stanowić podstawę do zainicjowania projektu, ponieważ to właśnie one determinują przyczynę, dla której klient podejmuje się wytworzenia produktu informatycznego. Klient zamawia system po to, by zrealizować konkretne cele biznesowe optymalizację jakiegoś procesu biznesowego, zwiększenie sprzedaży, czy redukcję pracowników administracyjnych. Te cele niestety bardzo często nie zostają zdefiniowane. Zarówno klient, jak i dostawca, skupia się zatem na funkcjach i usługach produktu, nie zastanawiając się, czemu mają one służyć. W efekcie klient dostaje produkt o określonych funkcjach, dostawca otrzymuje wynagrodzenie za swe usługi, ale produkt nie realizuje żadnych istotnych celów biznesowych lub realizuje je w stopniu dla klienta niewystarczającym. Czy taki projekt dostarczony w czasie, z funkcjami, jakie zostały zamówione, jedynie nie realizujący celów biznesowych można określić jako udany? Jednym z podstawowych problemów z projektami IT jest brak zrozumienia rzeczywistych potrzeb biznesowych organizacji zamawiającego. Podstawowe pytanie, jakie powinniśmy sobie zadać przy organizacji jakiegokolwiek projektu, brzmi: co chcemy osiągnąć, nie jaki produkt wytworzyć. Produkt, nawet zgodny z udokumentowanymi wymaganiami, niekoniecznie spełni potrzeby klienta. Wspomniane wyżej co chcemy osiągnąć wyjaśnia, dlaczego będziemy realizować dany projekt. To dlaczego jest wizją projektu, którą powinniśmy udokumentować w postaci określonego dokumentu (niektóre metodyki nazywają go po prostu dokumentem wizji), aby służył jako wysokopoziomowa deklaracja celu projektu. Nie wystarczy posiadać dokument wizji i listę celów biznesowych. Dokumenty te powinny być używane podczas realizacji projektu i służyć jako wskazówki przy podejmowaniu dalszych decyzji, chociażby tych związanych z zakresem projektu prace niesłużące spełnieniu wizji i celów projektowych można potencjalnie uważać za zbędne, jako że nie dostarczają żadnej wartości. Dobrą praktyką realizacji projektów jest dopasowanie celów projektu do ogólnych celów biznesowych i strategii organizacji. 1.1.2. Złe planowanie projektu Kolejnym grzechem jest całkowite zaniechanie planowania. Niektóre, najczęściej niedojrzałe organizacje w usilnym dążeniu do jak najszybszego wytworzenia pro-
1.1. Wyzwania związane z projektami IT 17 duktu (bo przecież rynek czeka...) zapominają, że podstawą realizacji jakiegokolwiek projektu jest planowanie. Jeśli nie opracowano planu, nie można go później realizować (co ukierunkowuje prace) ani monitorować. Oznacza to brak możliwości wykrycia potencjalnych problemów czy ryzyk na wczesnym etapie i odpowiedniego zareagowania, zanim problemy skumulują się do tego stopnia, że jedyną możliwą reakcją będzie już tylko gaszenie pożaru. Następny błąd popełniany jest na tyle często, że powinien zdobyć miejsce na podium w konkursie na klasyczny błąd planowania. Niedoszacowanie złożoności zakładamy, że prace związane z realizacją produktu albo i sam produkt są prostsze, niż okazuje się w rzeczywistości. Skąd to wynika? Zasadniczo można wyróżnić trzy przyczyny: Brak wiedzy na temat realnej złożoności problemu. W przypadku projektów czy produktów innowacyjnych lub takich, w których obszarze zespół projektowy nie ma doświadczenia, nie zawsze wiadomo, jak szacować złożoność. Przyjmuje się pewne założenia, bardzo często niedoszacowując. Kłania się stara zasada szacowania projektów: wynik szacowania należy pomnożyć przez 2 i dodać 50% buforu na możliwe problemy. Niestety, w obecnych warunkach rynkowych zasada ta jest często niemożliwa do zastosowania, ponieważ skutecznie zmniejszyłaby szanse producenta na realizację danego projektu. Brak konsultacji ze specjalistami. Niektórzy kierownicy projektu zbyt mocno wierzą we własne siły i próbują szacować projekt samodzielnie, bez konsultacji z zespołem projektowym czy ekspertami dziedzinowymi. Skutki są łatwe do przewidzenia. Problem ten może wynikać z błędnego postrzegania kierownika projektu jako jedynej osoby odpowiedzialnej za jego planowanie i szacowanie, choć zgodnie ze sztuką jest to zadaniem zespołu gdyż któż lepiej zaplanuje i wyceni np. testowanie w projekcie niż osoba odpowiedzialna za planowanie i realizację testów, czyli lider testów? Świadome niedoszacowanie w celu obniżenia łącznego kosztu projektu. Praktyka ta jest spotykana dość często, zwłaszcza w sektorze administracji publicznej, gdzie kryterium wygrania przetargu na projekt jest cena. Cóż więc ma zrobić producent, któremu zależy na wygranej? Obniżyć koszty, najczęściej przyjmując założenia, że pewne elementy da się zrobić szybciej i łatwiej, niż wskazują na to wyliczenia. O efektach takich założeń możemy często poczytać w prasie. Kolejnym bardzo poważnym błędem popełnianym podczas planowania projektu jest brak zarządzania oczekiwaniami klientów czy ogólnie interesariuszy. W praktyce przejawia się on brakiem zaplanowanych spotkań z interesariuszami, na których można omówić i zweryfikować wyniki już wykonanych prac, czyli upewnić się, czy podążamy w dobrym kierunku. Brak zaplanowania zaangażowania klienta i innych istotnych interesariuszy może skutkować problemami z wymaganiami, które okazują się być niekompletne czy nieprawidłowe (nie odzwierciedlają realnych potrzeb klientów), ponieważ zabrakło walidacji i komunikacji na bieżąco. Jeśli już mowa o komunikacji ten aspekt planowania również przysparza wielu kłopotów. Praktyka wskazuje, że w wielu projektach zaniedbuje się opracowanie planu komunikacji definiującego podstawowe zasady dzielenia się informacją w projekcie oraz określającego role i odpowiedzialności poszczególnych członków
18 WPROWADZENIE DO INŻYNIERII WYMAGAŃ zespołu. Brak planu komunikacji i określenia odpowiedzialności skutkuje najczęściej chaosem informacyjnym i problemami w realizacji podstawowych zadań. Rozważmy prosty przykład co zrobi tester, jeśli nie wie, komu zgłosić błąd zauważony w specyfikacji wymagań podczas przygotowywania przypadków testowych? 1. Poinformuje kierownika projektu, od którego dobrej woli i kompetencji będzie zależało przekazanie problemu do rozwiązania odpowiednim osobom. 2. Skonsultuje się z kolegą i wspólnie ustalą własną interpretację wymagań. 3. Zignoruje problem, na przykład wychodząc z założenia, że zgłoszenie błędu w wymaganiu i jego konsekwencje będą go kosztować dodatkową pracę. Złe zaplanowanie projektu często skutkuje nadmiernym, stałym lub czasowym, obciążeniem niektórych jego wykonawców, podczas gdy inne osoby (czy zespoły) są w tym samym czasie niemalże wolne. Przykładowo, projekty są często dzielone na etapy. Na etapie analizy i dokumentacji wymagań obciążeni są głównie analitycy (a nawet przeciążeni, ponieważ zwykle na analizę zakłada się zbyt mało czasu w stosunku do realnych potrzeb). W tym czasie testerzy i programiści są bezczynni albo pracują przy innym projekcie. Opcja druga z pozoru wydaje się całkiem rozsądna, jednakże w wyniku jej zastosowania po zakończeniu prac analitycznych testerzy i programiści rozpoczynają pracę nad projektem bez przygotowania i znajomości kontekstu. Powstają opóźnienia spowodowane faktem, że muszą się oni zapoznać z założeniami projektu i specyfikacjami produktu, zrozumieć, co mają do zrobienia, po czym dopiero zacząć pracę. Jak więc rozwiązać ten problem? Bardzo prosto programiści i testerzy są częścią zespołu projektowego, czyż nie? Celem zespołu jest dostarczenie produktu odpowiedniej jakości przy określonych założeniach (choćby czasowych). Członkowie zespołu powinni więc angażować się nie tylko w swoje zadania, jak na przykład samo kodowanie, lecz także wnosić wkład do czynności powiązanych z zadaniami, które będą realizować. Bardzo dobrym sposobem wykorzystania potencjału programistów i testerów jest zaangażowanie ich do przeglądów wymagań i specyfikacji produktu. Testerzy znakomicie zweryfikują, czy wymagania i projekty będą testowalne; programiści sprawdzą możliwości implementacji i doradzą optymalne sposoby spełnienia wymagań przy zastosowaniu dostępnych możliwości technicznych. Warto również dodać, że wiele problemów związanych z planowaniem wynika z przyczyn pośrednich. Przykładowo, źle wdrożony proces inżynierii wymagań może skutkować zaniedbaniem ustalenia priorytetów wymagań, co w konsekwencji może sprawić, że zespół skoncentruje się na wymaganiach mało istotnych, zamiast w pierwszej kolejności zająć się tymi najważniejszymi, które wprowadzają największe ryzyko projektowe. Innym błędem często spotykanym w obszarze inżynierii wymagań jest pomijanie pewnych czynności. Czasami producent pomija analizę biznesową wymagań i przechodzi od razu do projektowania rozwiązania. Przyczyn takiego stanu jest wiele najczęściej presja czasu (wynikająca zazwyczaj z niedoszacowania projektu) oraz nieświadomość faktu, że analiza biznesowa jest koniecznym etapem wytwarzania rozwiązań informatycznych. Bez pełnej analizy biznesowej pojawia się ryzyko zmian projektu systemu w późniejszych etapach projektu (np. podczas implementacji i testów) zostaną wykryte błędy, luki, brakujące funkcje czy ograniczenia, które zostałyby przewidziane na etapie analizy biznesowej.
1.1. Wyzwania związane z projektami IT 19 Kwestia zarządzania zmianami jest innym dowodem na to, że na problemy w planowaniu mogą się składać czynniki pośrednie. Wszelkie modyfikacje wnoszone do zakresu lub treści projektu powinny być obsługiwane za pomocą procesu zarządzania zmianami, którego częścią jest analiza wpływu. Bez niej nie jesteśmy w stanie określić ryzyka implementacji danej zmiany i przewidzieć wpływu, jaki wywrze ona na różne elementy produktu oraz na sam projekt nie wiemy na przykład, czy wdrożenie zmiany nie zepsuje dotychczas stabilnego produktu, co wpłynie na przebieg realizacji projektu, generując opóźnienia. Z tego powodu ważnym elementem planowania projektu jest nie tylko ustalenie etapów, obciążenia zasobów itp., ale również przewidywanie przebiegu samych procesów składających się na wytworzenie projektu produktu (np. analiza wymagań, implementacja, testowanie) oraz procesów pomocniczych, jak wspomniane już zarządzanie zmianą czy równie istotne zarządzanie konfiguracją. 1.1.3. Słaba komunikacja Projekty informatyczne są realizowane przez ludzi, a sukces przedsięwzięcia w dużym stopniu zależy od ich umiejętności współpracy. Czynnikami niezbędnymi do osiągnięcia sukcesu są świadomość i zrozumienie celów, zadań, odpowiedzialności, oczekiwań, problemów, ryzyk. Za uzyskanie i utrzymanie tej świadomości odpowiada komunikacja. Komunikacja to nie tylko dyskusje to również wszelkiego typu dokumenty, procedury, raporty i inne elementy umożliwiające dzielenie się informacją. Aby skutecznie zaplanować projekt i dalej go realizować, niezbędny jest częsty kontakt ze sponsorami i użytkownikami biznesowymi oraz końcowymi, gdyż tylko w taki sposób możemy poznać ich oczekiwania i potrzeby, jak również na bieżąco sprawdzać, czy wyniki realizowanych prac dążą do ich spełnienia. Raporty statusu i spotkania zarządcze nie są zbędną biurokracją, ale środkiem umożliwiającym monitorowanie postępów projektu i szybką reakcję na potencjalne problemy. Bez nich nie byłoby wiadomo, czy projekt podąża w dobrym kierunku i czy wszystko przebiega zgodnie z planem nie jesteśmy w stanie bowiem rozwiązać problemu, nie mając świadomości jego istnienia. Kolejny ważny element komunikacji to spotkania. Dojrzałe zespoły i organizacje nie organizują spotkań dla zasady, lecz w celu wymiany informacji i wyjaśnienia wszystkim członkom spotkania stanu spraw, problemów, szans, statusu prac oraz dalszych czynności. Zebrania dają możliwość nie tylko zrozumienia celu i przebiegu projektu, ale i szansę wyjaśnienia na bieżąco wszelkich wątpliwości czy zareagowania na problemy. Spotkania są ważne, istotna jest jednak również umiejętność ich organizowania. Dość powszechna niechęć do uczestnictwa we wszelkiego rodzaju spotkaniach często wynika z faktu ich fatalnej organizacji i realizacji braku planu, moderacji, podsumowania co skutkuje poczuciem straconego czasu. Organizację spotkania należy zacząć od opracowania i przekazania uczestnikom agendy, która wyszczególnia kwestie podejmowane na spotkaniu, pozwala też kontrolować przebieg i zakres dyskusji. Samo spotkanie powinno być moderowane, aby uniknąć schodzenia z zaplanowanych wątków i zapewnić dyscyplinę dyskusji. W trakcie spotkania wyznaczona osoba (sekretarz) powinna notować główne
20 WPROWADZENIE DO INŻYNIERII WYMAGAŃ decyzje, ustalenia, elementy dyskusji, które posłużą do opracowania notatki ze spotkania. Notatka ta powinna podsumowywać przebieg spotkania, decyzje (co ustalono), kwestie otwarte (czego nie ustalono), dalsze kroki i podział odpowiedzialności. Notatkę należy przesłać uczestnikom spotkania do akceptacji, a po jej uzyskaniu przekazać szerszemu gronu odbiorców. Ważnym elementem komunikacji, w tym także spotkań, są prezentacje i demonstracje wymagań, rozwiązań, produktu lub jego części. Ta forma komunikacji nie tylko znakomicie ułatwia przekazywanie wiedzy, lecz także ponieważ wykorzystujemy wizualizacje, które są łatwiejsze do przyswojenia niż tekst, umożliwia uzyskanie cennej informacji zwrotnej na temat prezentowanych obiektów. W celu przedstawienia alternatywnych sposobów implementacji ich wymagań i wyboru optymalnej opcji można prezentować interesariuszom koncepcje rozwiązań czy prototyp produktu. Przedmiotem prezentacji mogą być same wymagania, co umożliwia ich walidację i zaakceptowanie przez wybraną grupę interesariuszy, a tym samym obniża ryzyko niepowodzenia projektu spowodowanego wytworzeniem produktu na podstawie błędnie udokumentowanych lub niezrozumianych wymagań. Jak widać, opcji skutecznej komunikacji jest wiele wystarczy jedynie je poznać i wdrożyć jako stały element każdego przedsięwzięcia informatycznego. 1.1.4. Złe zarządzanie oczekiwaniami interesariuszy Bardzo ważnym czynnikiem powodzenia projektu jest zbudowanie wzajemnego zaufania i porozumienia między interesariuszami odnośnie do celów i pożądanych wyników przedsięwzięcia. Jest to szczególnie istotne w przypadku, gdy interesariusze pochodzący z różnych organizacji mają sprzeczne oczekiwania i interesy co, jak wiadomo, ma miejsce w większości projektów komercyjnych, mających na celu wytworzenie produktu przez dostawcę na życzenie zewnętrznego klienta. Aby osiągnąć sukces i wytworzyć produkt spełniający oczekiwania interesariuszy, należy po pierwsze znać ich oraz ich potrzeby. Po drugie, należy zbudować świadomość dążenia do wspólnego celu, niezależnie od organizacji, z której pochodzi dany interesariusz. Pierwszy warunek, mimo że pozornie oczywisty i prosty, w praktyce może nastręczać sporych problemów. Identyfikacja interesariuszy i ich potrzeb zasadniczy warunek początkowy dla czynności określania wymagań w wielu projektach jest wykonywana nieprawidłowo. Ze względu na presję czasu, brak świadomości, a czasem zwyczajną ignorancję, zaniedbuje się pełną identyfikację interesariuszy, ograniczając się jedynie do tych znanych i najbardziej oczywistych jak sponsor, kierownik projektu, biznes itp. Skutkiem takiej beztroski są często luki w analizie, gdyż każdy pominięty interesariusz oznacza ryzyko pominiętego wymagania czy ograniczenia, które może w zasadniczy sposób wpłynąć na koncepcję produktu lub samego projektu (chociażby kwestia wymaganej dokumentacji projektowej, która może być różnie postrzegana przez różnych interesariuszy).
1.1. Wyzwania związane z projektami IT 21 Kolejnym problemem jest samo zarządzanie oczekiwaniami interesariuszy. Wspomniano już, że różne grupy interesariuszy mają różne wymagania i potrzeby. Klasycznym przykładem jest różnica interesów na linii biznes użytkownicy końcowi. Biznes żąda spełnienia wszelkich procedur i wymagań wynikających z dziedziny biznesowej (często kosztem użyteczności produktu), natomiast użytkownicy z reguły pragną najprostszego rozwiązania. Nierozwiązane konflikty interesów między interesariuszami mogą sprawić, że gotowy produkt nie będzie spełniać oczekiwań określonej grupy czy grup odbiorców. W sytuacjach ekstremalnych producent może wytworzyć produkt kompletnie nieprzydatny użytkownikom końcowym lub niezgodny z wymaganiami biznesu. 1.1.5. Problemy z wymaganiami i ich zakresem Wymagania tworzą podstawy dla organizacji i planowania projektu IT oraz opracowania produktu; stanowią one jeden z najważniejszych czynników sukcesu lub porażki projektu. Słabe wymagania mają niejednoznaczny zakres, co przekłada się na słaby projekt produktu, w efekcie na słaby produkt. Wyzwania związane z wymaganiami nieprecyzyjnymi, niemierzalnymi, niepełnymi czy niemożliwymi do implementacji w danych warunkach biznesowych i technologicznych to już klasyczny problem podczas realizacji większości projektów IT. Najbardziej typowym błędem jest brak precyzji i niemierzalność wymagań. Pojawia się on zazwyczaj już na samym początku projektu. Ileż to razy doświadczalnie przekonaliśmy się, że klient nie umie sformułować swoich potrzeb? Jak często wymagania opisane są stwierdzeniami: system powinien być użyteczny, system ma umożliwiać zarządzanie raportami itp.? Klientowi (zamawiającemu) często brakuje kompetencji i wiedzy, jak przedstawić wymagania w sposób zrozumiały dla wykonawcy, aby jednocześnie były one precyzyjnymi kryteriami odbioru gotowego produktu. Doprecyzowanie wymagań leży w interesie dostawcy, gdyż pozostawienie ich bez wyjaśnienia spowoduje, że planowanie projektu zostanie wykonane na bardzo niedokładnych założeniach. Jak wygląda praktyka? Z różnych przyczyn, w tym z powodu błędów procesowych lub braku wiedzy, ale i w wyniku świadomego działania, dostawca często nie precyzuje wymagań przed podjęciem się realizacji danego projektu. Z nieprecyzyjnym opisem wymagań trudno realistycznie i wiarygodnie oszacować wysiłek, zakres i koszt projektu. Takie projekty są najczęściej niedoszacowane (ponieważ zakłada się mniej pracy, niż należy wykonać w rzeczywistości) albo przeszacowane (dodanie pewnego bufora na zapas ). Ponadto, przy takim sformułowaniu wymagań niemal niemożliwe staje się stwierdzenie, kiedy i czy w ogóle wymaganie zostało zaimplementowane. Brak mierzalności i kryteriów akceptacji powoduje, że odbiór gotowego rozwiązania opiera się na wierze, nie faktach. Początkowe problemy z wymaganiami skutkują często dalszymi konsekwencjami. Wstępnie ustalone harmonogramy projektów oszacowanych i zaplanowanych na
22 WPROWADZENIE DO INŻYNIERII WYMAGAŃ podstawie nieprecyzyjnych wymagań są zazwyczaj niemożliwe do realizacji. Brakuje czasu na wykonanie wszystkich czynności związanych z poprawnym wytworzeniem produktu. Jaki jest skutek? Próbuje się oszczędzić nieco czasu, maksymalnie skracając pewne etapy procesu wytwórczego. Jak można się domyślić, z reguły skraca się czas przeznaczony na szczegółową analizę wymagań lub/i testy, ponieważ w obiegowej, aczkolwiek całkowicie błędnej opinii procesy te mają najmniejszą wartość dodaną dla wytworzenia produktu. Analiza nie tworzy przecież kodu, czyż nie? Skracanie czasu analizy oznacza ryzyko pominięcia wymagań, ważnych ograniczeń czy reguł biznesowych, a w konsekwencji nieprawidłowy lub niepełny projekt rozwiązania. Idąc dalej poważne problemy przy odbiorze produktu, ponieważ, co jest całkowicie uzasadnione, klient nie wyrazi zgody na odbiór systemu i zapłatę za jego dostarczenie, jeżeli produkt nie spełni jego oczekiwań. Warto dodać, że w takim przypadku jedynym rozsądnym rozwiązaniem jest poprawienie produktu zgodnie z zastrzeżeniami klienta czyli wprowadzenie zmian w wytworzonym, stabilnym oprogramowaniu. Skutki późnych zmian są oczywiste wysokie ryzyko destabilizacji systemu i związana z nim konieczność wzmożonych testów regresyjnych i poprawek. 1.1.6. Brak umiejętności miękkich Komunikacja w zespole i dobrze dobrane kompetencje jego członków są zazwyczaj podstawą sukcesu przedsięwzięcia, jednak ich brak bywa równie często przyczyną klęski. Kompetencje miękkie, często określane w ogłoszeniach o pracę jako umiejętność pracy zespołowej, stanowią podstawę do zrozumienia, dialogu, budowania zaufania podczas realizacji projektu oraz na etapie jego utrzymania. Brak umiejętności nawiązywania kontaktu, odpowiedniego zadawania pytań czy wzbudzania zaufania może skutecznie utrudniać budowanie relacji z klientem, a w rezultacie tak istotną komunikację w projekcie. Jej zaniedbanie możemy utożsamiać z jednoczesnym odcięciem od informacji na temat tego, co dzieje się u naszego klienta, albo sposobu, w jaki postrzega on realizację samego projektu. Przykładem problemu z nawiązywaniem kontaktu mogą być zespoły handlowe, których podstawowym zadaniem jest poszukiwanie klientów. Jeśli sprzedawca przyklei na komputerze kartkę z napisam Zadzwoń do klienta jutro, po dwóch tygodniach zadanie często nadal nie jest wykonane bo karteczka przecież mówi jutro. Często kierują nami lęki, odruchy i przyzwyczajenia, w tym przypadku strach przed podniesieniem słuchawki i kontaktem z nieznaną osobą. Kompetencje te należy wykształcić. W zespole, który jest silnie ukierunkowany na zadania techniczne, często nie są one ćwiczone lub wyuczone. Stała techniczna praca z komputerem zamyka nas w małym świecie, w którym koncentrujemy się na realizacji zadania, skutecznie odcinając się od ludzi, którzy nas otaczają. Rezultatem tego są stereotypy informatyków, którzy głównie programują lub wykonują inną pracę na komputerze, jednak nie są w stanie nawiązać relacji z innymi ludźmi. W wielu krajach system edukacji nie obejmuje przemawiania, nawiązywania kontaktu, dyplomacji czy dyskusji. Polska nie odbiega pod tym względem od światowej średniej. Cierpimy na tym później, kiedy stajemy przed zarządem firmy
1.1. Wyzwania związane z projektami IT 23 i prezentujemy korzyści z wdrożenia naszego rozwiązania, wiedząc, że od jakości wystąpienia zależy kontrakt lub jego brak. Bez odpowiedniego przygotowania staje się to nie lada wyzwaniem. Istotnym składnikiem poprawnej komunikacji są spotkania, prowadzenie rozmów czy zwykłe zadawanie pytań w celu otrzymania informacji, które z perspektywy realizacji projektu interesują nas najbardziej. W wielu projektach znajdujemy niejasne wymagania typu system ma być ładny i zachodzimy w głowę, co autor miał na myśli. Zawsze możemy przyjąć, że wiemy lepiej i zrealizować zadanie zgodnie z naszą najlepszą wiedzą. Praktyka wskazuje jednak, że najpewniej nie uda nam się stworzyć dokładnie tego, co miał na myśli klient. Z pomocą przychodzą nam kompetencje miękkie, które pomagają zadawać odpowiednie pytania precyzujące: Dlaczego system ma być ładny (powód problemu z wyglądem)? Po co system ma być ładny (jak ma wygląd pomóc w dalszej pracy)? Jak wyobrażasz sobie idealne rozwiązanie tego problemu (zmusza klienta do myślenia o szczegółach)? Po takiej serii pytań może się okazać, że stary interfejs systemu był mało czytelny, klientowi zależy głównie na poprawieniu jego przejrzystości i użyteczności, a chce to zrealizować za pomocą dynamicznie generowanych tabel. Jeśli nie zadajemy pytań lub nie wiemy, o co pytać, stajemy przed wyzwaniem zdobycia szczytu góry, zdając się na ślepy los. Zwiększamy w ten sposób ryzyko, liczba niewiadomych rośnie niewiarygodnie, a wymarzony szczyt się oddala. Analogia ta sprawdza się we wszystkich dziedzinach, które wymagają współpracy z innymi ludźmi, nie tylko w projektach IT. Istnieje wiele technik miękkich i należy pamiętać, że często odgrywają one dużą rolę w projektach. Liczą się nie tylko kompetencje techniczne, ale często także forma przekazania lub pozyskania informacji oraz utrzymanie relacji z klientem. Brak takich umiejętności może skutecznie utrudnić pracę nad projektem i zdobywanie informacji, które mogą pomóc w jego efektywniejszej realizacji. Jeżeli jednak uda się nam zrealizować go z sukcesem, utrzymanie dobrych relacji i zrozumienie klienta to klucz do następnych kontraktów i zleceń. 1.1.7. Nierealistyczne oczekiwania Wszystkie realizowane projekty wykorzystują pewne wstępne wyobrażenia gotowych produktów oraz założenia, jakie przyjmujemy na początku ich realizacji. W oczach zamawiającego gotowy produkt jest często bliski ideału i wykracza daleko poza realne możliwości technologiczne lub oczekiwania rynku. Warunki przyjęte podczas realizowanych projektów często wymykają się spod kontroli, a od klienta słyszymy to jest to, czego chcieliśmy, ale. Co gorsza mogą one generować koszty nieadekwatne do wartości wytwarzanego rozwiązania. Podczas pracy nad projektami możemy spotkać osoby, które stawiają nierealistyczne wymagania bez uzasadnionej przesłanki biznesowej lub wybiegają z oczekiwaniami daleko w przyszłość. Oczywiście wszystko jest kwestią środków przeznaczonych na realizację projektów, jednak z praktyki wynika, że budżet projektu jest zawsze jest za mały, ponieważ projekty często są niedoszacowane.
24 WPROWADZENIE DO INŻYNIERII WYMAGAŃ Doświadczenie wskazuje, że nie istnieją projekty, w których przy ustalonym zakresie prac możemy dowolnie zmniejszyć budżet lub wymagać dużo większej jakości. Jak w anegdocie o szewcu, usługa może zostać wykonana: szybko i dobrze, ale nie tanio, tanio i szybko, ale jakości próżno się doszukiwać, tanio i dobrze, jednak w bardzo długim czasie. Z przedstawionych refleksji wyłania się problem ustalenia realnych priorytetów w projektach i przypisania ich do zebranych wymagań. W projektach wewnętrznych często można spotkać sytuację, w której wszystkie wymagania mają zostać zrealizowane, a nikt nie jest w stanie wskazać najważniejszych z nich. Przykładem może być przygotowanie prototypu produktu na konferencję, podczas gdy z góry wiadomo, że nie jesteśmy w stanie przygotować pełnej funkcjonalności na podany termin. Dyrektor naciska, zespół informuje, że produkt będzie gotowy w kwietniu roku następnego, a konferencja ma odbyć w grudniu. Sytuacja patowa bez podjęcia odpowiednich kroków i decyzji, co pokazać i realnie wykonać, strata zaistnieje zarówno po stronie biznesowej, jak i technicznej dla samego zespołu rozwoju, który dostanie zadanie nie do wykonania. Bez podjęcia działań spotkamy się z typowym marszem ku klęsce zespół będzie pracował nad produktem dnie i noce, choć z góry wiadomo, że nie wywiąże się z realizacji zadania. Nierealne wymagania są często formułowane jako oczekiwania. Niestety na wczesnym etapie projektu nie są one weryfikowane, ponieważ często nie ma takiej możliwości, a następnie generują wysokie koszty realizacji projektu lub tworzą niepotrzebne opóźnienia i utrudnienia. Najczęściej dotyczy to wymagań niefunkcjonalnych, których natura uniemożliwia ich łatwe opisanie. Stanowią one najtrudniejszą w realizacji część projektów. Praktyka pokazuje, że w takich sytuacjach musimy przedyskutować priorytety w projekcie z klientem oraz przedstawić mu obiektywne zalety oraz wady decyzji. Stała współpraca z biznesem ma znaczący wpływ na powodzenie projektu i należy ją doceniać. Szczególny nacisk na obecność interesariuszy możemy zaobserwować w popularnych metodykach zwinnych, np. Scrum, gdzie do reprezentowania biznesu klienta dedykowana jest odrębna rola o pełnej dostępności dla dostawcy. 1.1.8. Brak zasobów ludzkich Trudno jest znaleźć osobę z wymaganymi kompetencjami, a jednocześnie odpowiednio zmotywowaną do wykonywania aktywności związanych z realizacją projektu informatycznego. Ponieważ w obszarze testowania problem kadrowy jest dużym wyzwaniem, stanowiska często są obsadzane przez osoby z kwalifikacjami odbiegającymi od wymaganych, co skutkuje nieodpowiednim lub nieefektywnym prowadzeniem projektów. Ostatnie badania przeprowadzone wśród dyrektorów IT w Polsce wykazały, że największymi problemami, z jakimi spotykają się podczas wykonywa-
1.1. Wyzwania związane z projektami IT 25 nia codziennych zadań, są brak odpowiednich środków finansowych oraz zasobów ludzkich 2. W dzisiejszych czasach projekt obejmuje wiele systemów w zróżnicowanych technologiach i wymaga od zespołu różnego rodzaju kompetencji. Nie jest możliwe pokrycie całego zakresu kompetencji jedną osobą lub małym interdyscyplinarnym zespołem to najlepsza droga do dalszego zmniejszenia dostępnych zasobów. Mimo popularności metodyk zwinnych wykorzystujących małe interdyscyplinarne zespoły realizacja przez taki zespół wszystkich możliwych zadań w organizacji nie jest możliwa. Skalując takie zespoły i metodyki w organizacji, zyskujemy wymieszanie kompetencji i doświadczeń, jednak nie zawsze umożliwamy zespołom specjalizację, ponieważ nie idzie ona w parze z metodykami zwinnymi, jak np. Scrum. Aby określić szacowane koszty realizacji projektu, zasoby w projekcie powinny być zapewnione już na etapie powołania i definiowania wymagań. Niedoszacowanie kosztów zasobów to taki sam błąd jak pominięte wymagania czy brak odpowiednich środków finansowych na zakup wymaganych licencji na oprogramowanie. Specyficzne wymagania, normy lub metodyki mogą generować potrzebę zatrudnienia lub wynajęcia specjalisty. Sytuacja komplikuje się, jeżeli jego kompetencje są tak unikalne, że zasobów musimy szukać w innym kraju lub wręcz na innym kontynencie. Brak zasobów może przejawiać się jako różne typy potrzeb, czasem może wymagać dużej liczby osób do wykonania prostych prac, np. przeklikania scenariuszy testowych, lub częściej zadań wymagających specjalistycznych kompetencji metodycznych lub technologicznych. Brak specjalistów w zespole brak osób o kompetencjach potrzebnych do realizacji konkretnych zadań lub elementów wymaganych w projekcie. Zatrudnienie odpowiedniej osoby w ramach kontraktu Fixed-Term jest bardzo kosztowne, ponieważ wąska specjalizacja będzie generować wysokie koszty. Z pomocą przychodzą płatne usługi firm specjalizujących się w realizacji wykwalifikowanych zadań. Brak zasobów ludzkich do realizacji prac brak osób do realizacji zbyt dużej liczby zadań niekoniecznie wymagających wyspecjalizowanych kompetencji. Szczęśliwie na rynku istnieje wiele firm specjalizujących się w usługach typu body leasing, w których możemy wynajmować osoby do wykonywania dużej liczby zadań, ponosząc relatywnie niewysokie koszty. Należy pamiętać że zwiększenie liczby pracowników nie zawsze przyśpieszy wykonywanie pewnych czynności, a wręcz może je czasem skomplikować i wydłużyć czas realizacji. Przykładem ze świata przyrody może być ciąża u słonic, która trwa 2 III Krajowa Konferencja Inżynierii Oprogramowania Inżynieria oprogramowania w procesach integracji systemów informatycznych Cezary Orłowski, Paweł Madej, Łukasz Szczygielski, Bartosz Chrabski Zarządzanie przedsięwzięciami informatycznymi z wykorzystaniem centrów kompetencyjnych dużych firm informatycznych (12 15 września 2011).
26 WPROWADZENIE DO INŻYNIERII WYMAGAŃ 22 miesiące. Jeżeli dodamy kolejnych 21 słonic, nie uzyskamy małego słonia w miesiąc. Niektóre procesy w organizacji zajmują określony czas i z perspektywy zasobów nie mamy większego wpływu na ich przyspieszenie. W tym obszarze możemy jednak wpłynąć na jakość zasobów, które wykonują dla nas pracę, aby zapewnić odpowiednią realizację tego procesu. Odpowiednie zasoby i ich kompetencje są istotne dla projektu, ponieważ to właśnie pracownicy tworzą produkt dla klienta. Są one jednak zależne od pozostałych elementów ważnych dla projektu komunikacji w projekcie, oczekiwań czy zakresu, mając na nie znaczący wpływ. Dobór osób do projektu powinien zawsze być zdeterminowany przez ich kompetencje, wartość, jaką wnoszą, i doświadczenia z wcześniejszych projektów. 1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego Podstawą opracowania procesu prowadzenia projektów dopasowanego do organizacji są odpowiednio dobrane dobre praktyki, metody zarządzania oraz efektywne narzędzia wspierające. Ich wybór dla wielu organizacji stanowi wyzwanie i poważny problem. Analizując środowiska, w których obecnie prowadzone są projekty, możemy stwierdzić, że zespoły analityków, programistów i testerów zwykle nie komunikują się ze sobą w sposób efektywny, co negatywnie wpływa na wydajność pracy, koszty i jakość finalnego produktu. Powszechnie używane narzędzia wspierające prowadzenie projektu nie potrafią wymieniać informacji między sobą, co prowadzi do powielania funkcjonalności i konieczności żmudnego i narażonego na błędy przenoszenia danych między nimi. Wybór narzędzi dokonywany jest zwykle pod kątem zaspokojenia potrzeb każdego zespołu z osobna, co z czasem całkowicie blokuje rozwój strategii departamentu odpowiedzialnego za rozwój IT. Oczywistym wnioskiem jest konieczność dążenia do konsolidacji dyscyplin w ramach projektu na poziomie integracji repozytoriów danych i ujednolicenia narzędzi, przy jednoczesnej eliminacji powielania ich podstawowych funkcji. Zgodnie z tą koncepcją, efektywne narzędzia wspierające pracę zespołów projektowych powinny obsługiwać cały zintegrowany cykl produkcyjny (ang. Application Lifecycle Management skrót ALM). ALM ma za zadanie zintegrować najważniejsze dyscypliny projektowe, jak zarządzanie wymaganiami, zarządzanie zmianami i konfiguracjami oraz zarządzanie procesami zapewnienia jakości. Dla osiągnięcia jak najlepszych efektów, narzędzia ALM powinny wspierać się na solidnych fundamentach, które zapewnią możliwość pomiaru efektywności procesów wytwarzania oraz współpracy między wszystkimi uczestnikami projektu. Każda organizacja profesjonalnie zajmująca się wytwarzaniem oprogramowania lub systemów pracuje według ustalonych procesów. Mogą być one dokumentowane w postaci metodyk, jak Scrum, OpenUP, EclipseWay, T-Map Next czy Rational Unified Process, lub przyjęte jako nieformalne zbiory dobrych praktyk. Adaptacja posiadanych narzędzi do przyjętych procesów jest wyzwaniem dla wielu organizacji, szczególnie gdy procesy te są nowe lub specyficzne dla dziedziny przedsięwzięcia. Wybierając narzędzie, zawsze powinniśmy się kierować jego wsparciem dla aktu-
1.2. Podstawowe definicje oraz klasyfikacje 27 alnych lub przyszłych procesów używanych w organizacji. W idealnej sytuacji producent udostępnia w narzędziu różne szablony metodyk, jak również umożliwia ich edycję i tworzenie własnych szablonów od podstaw. Ocena aktualnego stanu projektu, zarządzanie ryzykiem czy budżetem są poważnym wyzwaniem w każdym przedsięwzięciu. Dzięki opcji wglądu w rzeczywiste dane projektowe możliwe jest wczesne podejmowanie decyzji pozwalających ograniczyć wiele ryzyk. Z perspektywy kadry zarządzającej czy kierownika projektu szczególnie istotny staje się element raportowania i planowania prac z uwzględnieniem bieżących danych z przebiegu prac, ewentualnych opóźnień czy danych historycznych z zakończonych wcześniej projektów. Wszelkie zmiany w wymaganiach, problemy technologiczne, odstępstwa od planu, urlopy, przeciągające się zadania czy rozwiązania błędów zgłoszonych przez klientów powinny być możliwe do śledzenia i weryfikowania w czasie rzeczywistym. Wyciągane wniosków ze zrealizowanych projektów pomaga znacznie obniżyć koszty i zwiększać produktywność. Narzędzia powinny gromadzić ważne dane projektowe i wspierać kadrę zarządzającą w procesie ich analizy. Oczywistym przykładem zastosowania takich informacji jest weryfikacja poprawności szacowania pracochłonności. Innym przykładem użycia danych archiwalnych do retrospekcji jest analiza głównych źródeł błędów i problemów napotkanych w projektach. Większość organizacji korzysta już z różnego rodzaju narzędzi wspierających różne dyscypliny procesu tworzenia oprogramowania rozwiązujące specyficzne potrzeby organizacji. Rezygnacja z nich wiązałaby sie ze stratami jakości obsługi procesów, dlatego narzędzia takie powinny być zintegrowane, aby cały proces wytwarzania był efektywny, mierzalny i przewidywalny. Podsumowując czynniki wpływające na sukces projektu, można pokusić się o stwierdzenie, że spora część z nich w mniejszym lub większym stopniu dotyczy inżynierii wymagań. Potwierdzają to przeróżne statystyki opracowywane przez organizacje profesjonalnie zajmujące się badaniami rynku, na przykład Standish Group czy Gartner. Ich opracowania od lat wskazują w przybliżeniu te same przyczyny niepowodzeń projektów, wśród których niezmiennie czołowe pozycje zajmują zagadnienia związane z wymaganiami i celami biznesowymi. 1.2. Podstawowe definicje oraz klasyfikacje Punktem startowym dla inżynierii wymagań jest tak zwany problem biznesowy. Opisuje on potrzebę czy cel biznesowy, które będą rozwiązane przez docelowy produkt. Problem biznesowy jak nazwa wskazuje w ujęciu biznesowym opisuje, co chcemy osiągnąć. Na tym etapie nie ma mowy o szczegółach planowanego produktu czy aspektach Premiera implementacyjnych. książki Koncentrujemy - listopad się na potrzebie. 2014. Przykładem problemu biznesowego jest potrzeba optymalizacji procesu obsługi klienta. Problem biznesowy jest likwidowany przez tak zwane rozwiązanie. Jest nim dowolny produkt, usługa czy proces lub ich elementy umożliwiające spełnienie wymagań związanych z realizacją danego problemu biznesowego. Rozwiązanie definiowane jest jako zmiana w obecnym stanie organizacji wykonana w celu osią-