Po wygłoszeniu zaplanowanych wykładów zaproszono uczestników konferencji do wymiany doświadczeń. W roli ekspertów wystąpili: Stephen Withall, Marek Ujejski (Polskie Towarzystwo Informatyczne), Anita Walkowiak (AION). Dyskusję moderował Artur Kasprzyk (AION).
W trakcie dyskusji pojawiły się następujące pytania:
Czy analityk biznesowy może dobrze wykonywać swoją pracę bez uprzedniej praktyki programistycznej?
Opinie większości osób były zgodne – praktyka programistyczna nie jest wymagana. Aczkolwiek pojawiły się opinie, iż dobrze byłoby, gdyby analityk znał konsekwencje podejmowanych przez siebie decyzji. W przeciwnym bowiem razie bardzo łatwo jest doprowadzić do sytuacji, w której poprawnie określone oczekiwania trudno jest zrealizować i z tego powodu wymagać mogą zmiany już zatwierdzonych decyzji.
Korzystanie z szablonów niewątpliwie ułatwia oraz przyspiesza pracę. Wprowadza pewną automatyzację, co prowadzi do rutyny. Jak używać wzorców/szablonów, aby nie stracić własnej kreatywności? Czy wzorce są na tyle niebezpieczne, że za innowacje powinien być odpowiedzialny zespół, który z nich nie korzysta?
Jako pierwszy głos w dyskusji zabrał Stephen Withall. Stwierdził, iż jego dotychczasowe doświadczenia ze stosowania wzorcowych rozwiązań wskazują na szybsze dochodzenie do poprawnych konstrukcji niźli w przypadku opracowywania docelowych rozwiązań od podstaw. Jednocześnie nie zachodzi przy tym ryzyko utraty innowacyjności czy kreatywności. W trakcie dalszej dyskusji nawiązano także do praktyk stosowania wzorców projektowych. Także i w tym przypadku podkreślono, iż stosowanie opracowanych szablonów nie wpływa negatywnie na kreatywność, podczas gdy pozytywny wpływ objawia się nie tylko szybszym tempem prac, ale także obserwuje się poprawę jej jakości oraz tendencję do poszukiwania przez członków zespołów kolejnych, ogólnych rozwiązań dla często występujących problemów.
Jakie zmiany w pracy analityka niesie wprowadzenie MDA?
Model-Driven Architecture zakłada, iż przygotowywane modele, na których mają być wykonane przekształcenia, są jednoznaczne i precyzyjne. Ta cecha narzuca określone wymagania odnośnie pracy analityka, jego wiedzy oraz wykorzystywanych technik analitycznych. Realizowane przez niego działania powinny skutkować powstaniem modeli spełniających powyższe kryteria. Co otrzymujemy w zamian? Przede wszystkim skrócenie procesu produkcyjnego, mniejszą błędorodność prac (wyższą jakość produktu), możliwość szybszej reakcji na zmiany.
Poddano jednak w wątpliwość, czy wprowadzenie MDA do procesu wytwórczego nie spowoduje, iż programiści będą zmuszeni do zarządzania kodem napisanym przez „maszynę” i czy nie okaże się, iż kod ten będzie nieefektywny z punktu widzenia aplikacji. Anita Walkowiak, od kilku lat wykorzystująca MDA w projektach, odpowiedziała, iż kod „wygenerowany” przez maszynę jest tylko i wyłącznie takim kodem, jaki chcemy, aby był wygenerowany. W związku z tym, nie ma potrzeby go poprawiać (jeśli wygenerowany kod nie odpowiada potrzebom, wówczas należy zmodyfikować transformacje, bądź zarzucić pomysł generowania kodu dla danego obszaru). Należy natomiast go uzupełnić o te aspekty, które nie są poddane transformacjom.
Jestem przedstawicielem firmy produkującej oprogramowanie. Podpisujemy umowę z ogólnym załącznikiem funkcjonalnym i tworzymy specyfikację wymagań podczas realizacji projektu (stosując wewnętrzne wzorce). Jak w praktyce dokonywać odbioru systemu przez klienta? Zaznaczam, że czasem występują rozbieżności w interpretacji między dostawą i odbiorcą załącznika funkcjonalnego do umowy.
Pytanie wywołało żywiołową reakcję, gdyż z problemami tego typu stykają się praktycznie wszystkie zespoły realizujące projekty informatyczne. Pierwsza z udzielonych odpowiedzi brzmiała „Nie ma szans na sprawną realizację projektu, jeśli wymagania nie są jasno i precyzyjnie określone. Niespójności i brak precyzji zawsze się mszczą”. Jednakże, szybko podano kontr odpowiedź – „Skoro nie należy podchodzić do realizacji projektów w przypadku niepoprawnie wyspecyfikowanych wymagań, a życie pokazuje, że taka jest zdecydowana większość specyfikacji, to czy przypadkiem nie doprowadzimy do paraliżu na styku klient-wykonawca?”.
W dalszej części dyskusji podano propozycje rozdzielenia prac nad realizacją projektu informatycznego na dwa etapy: analizę oraz realizację systemu zgodnie z dostarczonymi wynikami analizy. Dzięki temu łatwiej będzie szacować poszczególne etapy prac (w trakcie analizy dowiadujemy się, co system rzeczywiście powinien robić, co stanowi dobry punkt wyjściowy do szacowania prac związanych z realizacją wymagań), a przede wszystkim każdy z etapów będzie realizowany z wykorzystaniem wystarczająco precyzyjnych informacji początkowych.
Pan Marek Ujejski zwrócił jednakże uwagę na formalny problem występujący w przypadku realizacji projektów zgodnych z ustawą o zamówieniach publicznych. Otóż, przy tego typu postępowaniu, praktykuje się, iż firma realizująca jeden z etapów prac, jest automatycznie wykluczana z ubiegania się o realizację kolejnego etapu, co może stanowić problem.
Czy pominięcie use case [przyp. aut. przy opisywaniu zasad funkcjonowania organizacji] nie spowoduje zwiększenia luki istniejącej pomiędzy specyfikacją wymagań a specyfikacją projektu.
Pytanie nawiązywało bezpośrednio do wykładów omawiających podejście firmy AION do specyfikacji oczekiwań biznesu wobec rozwiązań informatycznych. Prowadzący panel dyskusyjny, pan Artur Kasprzyk zwrócił uwagę na fakt, iż pojęcie przypadku użycia zostało wprowadzone jako pomysł na podział całej funkcjonalności na mniejsze składowe, dające określony rezultat aktualnemu użytkownikowi systemu. Z punktu widzenia określania oczekiwań uczestników procesów biznesowych, koncepcja przypadku użycia jest zbyt obszerna, gdyż nie pozwala na jawne wskazanie oczekiwań, które stworzą wspomnianą wartość dla użytkownika, a które są istotne z punktu widzenia kroków w procesie biznesowym. Oznacza to, iż z jednej strony, nie powstaje luka pomiędzy specyfikacją wymagań, a specyfikacja projektu; co więcej uzyskuje się płynne przejście pomiędzy wymaganiami projektu (wartościowanymi przez reprezentantów biznesu) a oczekiwaniami przyszłych użytkowników, którzy zatwierdzą określony sposób realizacji wymagań biznesowych, ujęty przypadkami użycia.
Czy istnieją wzorce kontroli jakości wymagań ?
Pytanie wywołało lawinę komentarzy oraz zainicjowało dyskusję na temat praktycznych możliwości weryfikacji specyfikowanych oraz otrzymywanych oczekiwań. Uczestnicy dyskusji stwierdzili, powołując się także na omawianą przez Suzanne Robertson metodykę Volere, iż systematyczne podejście do specyfikowania wymagań umożliwia weryfikację jakości każdego z poszczególnych wymagań oraz grupy wymagań ściśle ze sobą powiązanych. Problemem staje się natomiast weryfikacja kompletności i spójności wszystkich wymagań zebranych w trakcie prac nad systemem. Symptomatyczne były kolejne wypowiedzi osób uczestniczących w dyskusji, zaczynające się od „Wprawdzie nie mam pomysłu na rozwiązanie problemu, ale ponad to, co powiedziano niska jakość wymagań powoduje jeszcze…”. Dyskusję, a tym samym konferencję zakończono stwierdzeniem, iż problem jest, skutki jego występowania są dotkliwe i w związku z tym warto dalej pracować nad skuteczniejszymi metodami zarządzania wymaganiami.
Kolejny wykład, poprowadzony przez Artura Kasprzyka koncentrował się na problemie pozyskiwania oraz specyfikowania oczekiwań uczestników procesów biznesowych wobec rozwiązań informatycznych w kontekście realizowanej przez nich pracy. Prowadzący postawił tezę, iż wdrażanie rozwiązań informatycznych w biznesie powinno być rozpatrywane jako jeden ze sposobów usprawniania funkcjonowania organizacji (obecnie, często nazywanego usprawnianiem procesów biznesowych, jako bezpośredni efekt popularyzacji procesowego podejścia do zarządzania organizacjami), a miarą sukcesu wdrożenia powinien być zysk z przedsięwzięcia na poziomie organizacji. Artur Kasprzyk wskazał metody pozyskiwania wymagań, zwiększające skuteczność pracy analityka poprzez bezpośrednie nawiązanie do pracy wykonywanej przez uczestników procesów biznesowych, zwężonej w trakcie omawiania poszczególnych obszarów wsparcia do niewielkich działań, umożliwiających szybką weryfikację wymagań wobec rzeczywistych potrzeb organizacji. Wykład został zakończony analizą przydatności koncepcji przypadku użycia do kontaktu ze specjalistami dziedzinowymi, z której wyprowadzono wniosek, iż przypadki użycia są dobrym sposobem na opisywanie sposobu realizacji wymagań biznesu, ale nie są odpowiednim narzędziem do specyfikowania wymagań biznesu. Wskazano jednocześnie, iż właściwszym sposobem na specyfikowanie wymagań biznesu jest wykorzystanie np. szablonu opisu wymagania z metody Volere, aczkolwiek wkomponowanego w model procesowy organizacji i uzupełnionego o odwołania do innych składowych tego modelu.
Trzeci wykład, prowadzony przez Stephena Withalla miał na celu zainspirowanie słuchaczy pomysłem traktowania specyfikacji wymagań wobec typowych obszarów wsparcia technologiami informatycznymi (np. CRM, ERP) jako „dobra wspólnego” dostawców i odbiorców. W trakcie wykładu zauważono, iż pomimo podejmowanych prób osiągnięcia wspólnego celu (wdrożenie systemu w docelowym środowisku), poglądy każdej ze stron na wymagania, jakie system powinien realizować, mogą się różnić. Jednakże, nie powinno to być traktowane jako rozbieżność pomiędzy ofertą a oczekiwaniami, a jedynie jako zaczątek dyskusji na temat wzajemnych oczekiwań i priorytetów, mającej doprowadzić do opracowania bardziej elastycznego „wspólnego” katalogu wymagań i produktów realizujących je w jak największym stopniu. Upublicznienie rozwijanych w ten sposób katalogów, zdaniem autora, mogłoby doprowadzić do zwiększenia świadomości klientów co do możliwych do osiągnięcia korzyści wynikających z zakupu (wdrożenia systemu), a z drugiej strony pozwolić dostawcom produktów rozwijać je w kierunku zgodnym z oczekiwaniami docelowych użytkowników.
Prezentacje rozpoczęło wystąpienie Stephena Withalla, który omówił koncepcję wzorców wymagań oraz wskazał korzyści wynikające z katalogowania oraz wielokrotnego wykorzystania często pojawiających się oczekiwań wobec rozwiązań informatycznych. Stephen Withall w swoim wystąpieniu skoncentrował się na trudniejszym, niefunkcjonalnym obszarze wymagań, poprzedzając jednakże właściwą część prezentacji oceną aktualnego stanu inżynierii wymagań oraz zaobserwowanych w projektach praktyk. Zaprezentowana krytyczna ocena okazała się zgodna z poglądami uczestników konferencji, wskazując tym samym na zasadność podejmowania inicjatyw mających na celu usprawnienie procesu pozyskiwania i specyfikowania wymagań. Dalsza część wykładu miała wykazać, iż taki stan rzeczy nie musi być jedynym możliwym, aczkolwiek jego zmiana wymaga zastosowania systematycznych metod i dokładnego opisu oczekiwań. W kolejnym wystąpieniu Stephen Withall przedstawił obszary funkcjonowania systemów informatycznych, które zostały wsparte przez niego wzorcami. Zaprezentowano także podstawowe założenia wybranych wzorców oraz argumenty uzasadniające ich opracowanie i korzyści, jakie mogą wynikać z ich stosowania. 
