ANALIZA WYBRANYCH KONCEPCJI W OBSZARZE … · jako standard lub do celów akredytacji, lecz jako...

Stanisław Stanek*

ANALIZA WYBRANYCH KONCEPCJI W OBSZARZE PROJEKTOWANIA WYMAGAŃ

Wprowadzenie W kontekście podejmowanej działalności projektowej pojawiają się za-

zwyczaj cztery podstawowe pytania: o cele, dla których system ma być realizo-wany (dlaczego?), o metareguły obowiązujące w procesie realizacji systemu (jak?), o interesariuszy, których system ma wspomagać (kto?), o usługi jakie system ma realizować (co?). Specyfikę projektów informatycznych odzwier-ciedla ciąg ukierunkowanych na informatykę zaleceń organizacji normalizacyj-nych. W szczególności standard ISO/IEC 12207-2008, opracowany dla potrzeb łatwiejszego łącznego posługiwania się standardami 21207 oraz 15504, definiuje używane w artykule pojęcia klient1, użytkownik2, developer3 oraz interesariusz4. Interesariusze będą wspomagać działania projektowe w nawiązaniu do postrze-ganych potrzeb jakie projektowany system będzie zaspakajał. Ian Sommerville w jednej z częściej cytowanych pozycji [Somm03] podejmujących problematykę analizy wymagań pisze: „Problemy, które mają rozwiązywać inżynierowie oprogramowania, są często bardzo złożone. Zrozumienie ich natury może być trudne, zwłaszcza w wypadku nowych systemów. Trudno jest zatem dokładnie ustalić, co system powinien robić. Opisy usług i ograniczeń są wymaganiami stawianymi systemowi. Proces wynajdowania, analizowania, dokumentowania oraz sprawdzania tych usług i ograniczeń nosi nazwę „inżynierii wymagań”. * Prof. nadzw. dr hab. inż. Stanisław Stanek, Wyższa Szkoła Oficerska Wojsk Lądowych im. ge-

nerała Tadeusza Kościuszki, 51-150 Wrocław, ul. Czajkowskiego 109, e-mail: stan_stanek@ neostrada.pl

1 Customer − organizacja lub osoba, która otrzymuje produkt lub usługę. 2 User − jednostka lub grupa, korzystająca z systemu podczas jego użytkowania. 3 Developer − organizacja, która wykonuje zadania rozwoju (w tym analizy wymagań, projekto-

wania, testowania) podczas procesu cyklu życia. 4 Stakeholder − osoba lub organizacja mająca prawo, akcje, roszczenia albo zainteresowana sys-

temem lub jego charakterystykami nawiązującymi do potrzeb oraz oczekiwań. Można za-uważyć (za [Some03, s. 122]), że w określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk, np.: użytkownicy, którzy będą pracować z systemem, inżynierowie budujący lub pielęgnujący inne powiązane systemy, menadżerowie przedsiębiorstwa, eksperci z danych dziedzin, a być może nawet reprezentanci związków zawodowych.

Stanisław Stanek 138

Problematyka inżynierii wymagań wydzieliła się z obszaru badań nad inży-nierią oprogramowania. Za prekursorów tej problematyki badawczej uważa się Bella oraz Thayera, którzy w 1976 roku w następstwie analizy badań empirycz-nych konkludowali, że: – niekompletne, niewłaściwe, niezgodne lub niejasne wymagania są liczne

i mają krytyczny wpływ na jakość oprogramowania, – wymagania dla systemu nie powstają w sposób naturalny, przeciwnie, muszą

być zaprojektowane a następnie konsekwentnie przeglądane i dostosowy-wane.

Rozwój podstaw metodycznych inżynierii wymagań oraz szerzej inżynierii oprogramowania, jaki nastąpił w latach 80., nie spowodował znaczącego po-stępu w obszarze prac projektowych, co ilustrują np. następujące często cytowa-ne wyniki raportu Standish Group’s: – 31% projektów zostało przerwanych przed zakończeniem, – 53% projektów kosztowało ponad 189% wartości estymowanych, – tylko 16% projektów zakończyło się zgodnie z planem (termin, koszty), – projekty ukończone dostarczały jedynie 42% oryginalnych cech oraz funkcji,

Ponadto trzy najczęstsze problemy projektowe to: – brak informacji wejściowych pochodzących od użytkownika − 13%, – niekompletność wymagań oraz specyfikacji − 12%, – zmiany wymagań oraz specyfikacji − 12% [StGr94].

Wyniki te oznaczają, że na progu nowego tysiąclecia projektowanie wy-magań w dalszym ciągu sprawiało znaczące trudności projektantom.

Dalsza interpretacja badań empirycznych z tego okresu utrwalała przekona-nie o potrzebie bardziej adekwatnej pracy z użytkownikiem. Podejście zorien-towane na użytkownika (UOD – User Oriented Design) uzyskało między-narodową nobilitację najpierw w 1999 roku w postaci standardu ISO 13407, a ostatnio po aktualizacji, w nawiązaniu do numeracji zgodnej z innymi standar-dami użyteczności, w postaci obowiązującego obecnie standardu ISO 9241- -2105. Standard jest postrzegany jako manifest skierowany do rozproszonych środowisk stosujących UOD nawołujący do zjednoczenia. Organizacje, które decydują się na jego wykorzystanie uzyskują terminologiczne i metodyczne wsparcie wypracowane przez międzynarodowe gremia ekspertów.

Krytyczną dyskusję dotychczasowych praktyk w obszarze specyfikowania wymagań wskazującą na przesłanki wprowadzenia podejścia zwinnego przed-stawioną przez Dona Reinertsena we wprowadzeniu do ostatniej książki Deana Lefingwella można streścić następująco: 5 W Polsce 21 lutego 2011 roku ukazał się w postaci normy PN-EN ISO 9241-210:2011 Ergo-

nomia interakcji człowieka i systemu -- Część 210: Projektowanie ukierunkowane na człowieka w przypadku systemów interaktywnych.

Analiza wybranych koncepcji… 139

– badania niezmiennie ukazują, że od 80% do 85% niepowodzeń w projektowaniu wiąże się z niepoprawnymi wymaganiami. Wiemy o tym od ponad dekady, jednak nie udało nam się dotychczas tego wyniku poprawić;

– dlaczego? Początkowo byliśmy organizowani funkcjonalnie, po prostu problem po-zostawał poza granicami inżynierii − mogliśmy obwiniać marketing i zarządzanie produktem. Później, gdy przyjęto cross-funkcjonalne zespoły nakazano, aby słuchać głosu klienta, co miało rozwiązać problem;

– nie rozwiązało. Zignorowano fakt, że niejednokrotnie klienci nie wiedzą, czego chcą. Jeśli nawet wiedzą, to nie potrafią tego opisać. A jeśli potrafią, to raczej opisują swo-je rozwiązanie problemu, a nie samą rzeczywistą potrzebę. Aby trzymać się prawdy, nie ma jednego „głosu klienta”. Mamy do czynienia z kakofonią głosów wskazują-cych na różne rozwiązania. Jeśli skupimy się jedynie na użytkowniku, to możemy przeoczyć „wymagania niefunkcjonalne”. A przecież, szczególnie w kontekście dy-namiki zmian w otoczeniu, nie można interesariuszom odmówić prawa do rozwoju, do zmian, bo wówczas będziemy ich ograniczać, a nie wspomagać;

– tak więc musimy zaprzestać „chowania głowy w piasek”, bardziej niż mozolnie i kosztownie tworzyć idealne wymagania, musimy inwestować w organizowanie procesów i infrastruktury, wspierających wykrywanie i korygowanie braku dopaso-wania pomiędzy naszymi rozwiązaniami a zmieniającymi się potrzebami klienta [Lefi11].

Celem artykułu jest analiza trzech wymienionych nurtów badawczych (in-żynieria wymagań, podejście zorientowane na użytkownika, podejścia zwinne) w kontekście rozwiązań proponowanych dla potrzeb projektowania wymagań. Artykuł ma zidentyfikować, opisać oraz poddać pod dyskusję wybrane, pro-ponowane w ramach wymienionych koncepcji, mechanizmy.

1. Prace nad inżynierią wymagań Podejście inżynierskie koncentruje się na wykorzystaniu sprawdzonych

podstaw teoretycznych w procesie rozwiązywania problemów lub tworzenia produktów. Nawiązując do przytoczonej we wstępie opinii Iana Sommerville, inżynieria wymagań jest zorientowana na wyodrębnienie oraz analizę procesu wymagań w organizacji. Aktywności w procesie inżynierii wymagań analizowa-li m.in. Houdek oraz Pohl [HoPo00], Lamswerde [Lams09]6: – tworzenie projektu: aktywność związana z uruchomieniem projektu w celu

opracowania nowego produktu lub modyfikowania istniejącego produktu; – odkrywanie wymagań (określane też jako zbieranie pozyskiwanie, wydo-

bywanie wymagań): aktywność, w ramach której developer zwykle w inter-akcji z interesariuszami działają w celu zdefiniowania dziedziny projektu usług, jakie system powinien zapewniać oraz przyszłych ograniczeń;

6 Szerszy opis poszczególnych aktywności można także znaleźć np. w [Lams09].


– analiza (doskonalenie) wymagań: po odkryciu wymagania są interpreto-wane oraz strukturalizowane. Następnie są dokumentowane. Tutaj aktywność ta jest wyodrębniona, jednak często przeplata się z odkrywaniem wymagań, ponieważ analiza niezmiennie ma swoje miejsce w fazie odkrywania;

– negocjacja wymagań: aktywność związana z negocjacjami z interesariu-szami w celu uzyskania porozumienia, co do definicji wymagań;

– sprawdzanie wymagań: weryfikacja formalna ma na celu zapewnienie for-malnej poprawności wymagań. Nawiązuje do poprawności zapisu oraz wew-nętrznej zgodności. Walidacja wymagań ma z kolei na celu stwierdzenie czy zebrane wymagania i stworzony dokument wymagań definiują system zgod-ny z oczekiwaniami interesariuszy. Dobrą praktyką jest organizowanie inspekcji wymagań, w których biorą udział interesariusze lub ich przedstawi-ciele;

– zarządzanie wymaganiami: dotyczy planowania oraz zarządzania zmianami wymagań. Zarządzanie zmianą sprawia, że ustandaryzowane informacje są gromadzone dla każdej zmiany oraz że całkowite koszty oraz korzyści pro-ponowanych zmian są analizowane, dlatego też zarządzanie zmianą obejmuje ocenę ryzyka i analizę oddziaływań;

– śledzenie wymagań: pozwala na analizowanie pochodzenia wymagań, związków zachodzących pomiędzy wymaganiami oraz między wymaganiami a ich realizacją w projektowanym systemie. Ułatwia utrzymanie spójności w obliczu zmian.

Do wielokrotnie cytowanych później modeli procesu inżynierii wymagań można zaliczyć (rys. 1): – L − model iteracyjny Loucopoulosa, Karakostasa [LoKa95], – M − model liniowy Macaulaya [Maca96], – K − model liniowy z iteracjami między działaniami Kotonaya oraz Sommer-

vile’a [KoSo98], – S − podsumowujący doświadczenia model cyklów aktywności Sommervile’a

[Some05]. Przeprowadzane w dalszej kolejności, w dwóch firmach A i B, badania

[SAJP02] zmierzające do wskazania, który z trzech modeli M, K, L adekwatnie odzwierciedla realizowane w praktyce prace nad wymaganiami, choć odsłoniły wiele prawidłowości, to jednak nie przyniosły rozstrzygnięcia. W dwóch pro-jektach (A2, B2) inżynieria wymagań była realizowana jako wydzielona faza, a proces wymagań nawiązywał do modelu liniowego M. W trzech pozostałych projektach inżynieria wymagań była realizowana ciągle w czasie całego procesu projektowania.


L

M

K

S

Rys. 1. Modele inżynierii wymagań

Analiza wykonalnościoraz wybór

opcji


Odnotowano wiele iteracji, co było szczególnie wyraźne, gdy w ramach przyrostów były realizowane prototypy (A3). Podsumowując, należy zauważyć, że proces inżynierii wymagań kształtuje się w nawiązaniu do szerszego kon-tekstu. Model przyrostowy inżynierii wymagań L w miarę dobrze oddaje itera-cyjny charakter procesu projektowania, jednak nie pokazuje progresji w procesie projektowania. Mając na uwadze powyższe doświadczenia, za podstawę do dal-szych rozważań przyjęto późniejszy model S (por. rys. 1).

Tabela 1

Badania nad modelami L, K, M

A − duża firma produkcja B − duża firma finanse Proj. A1 Proj. A2 Proj. A3 Proj. B1 Proj. B2

Cel projektu Wdrożenie ERP

Upgrade systemów

Wsparcie promocji

Rozwój witryny

Wymiana CRM

Rozmiar Duży Średni Mały Średni Mały Osób 26-100 11-25 1-10 1-10 1-10

Osobomiesięcy 540 24 3 100 8

Priorytet Czas/Koszt Czas/Funk. Funk. Czas Czas/Funk.

Tworz. projektu Nie Explicite Implicite Implicite Explicite Odkrywanie wym. Explicite Explicite Explicite Explicite Explicite

Analiza wym. Explicite Implicite Explicite Explicite Implicite

Negocjacje wym. Implicite Implicite Implicite Explicite Explicite

Zarządzanie wym. Explicite Implicite No No Implicite Śledzenie wym. Implicite Implicite No No Implicite

Model (K) (M) (L) (K) (L) (K) (M)

Źródło: Na podstawie: [SAJP02].

Obserwowane w praktyce duże zróżnicowanie procesów inżynierii wy-

magań po części tłumaczy koncepcja dojrzałości procesowej. Dojrzałość pro-cesowa wyraża się zakresem, w jakim procesy są formalnie: zdefiniowane, zarządzane, elastyczne, mierzone i efektywne [Gaje03]. W latach 90. wielu developerów oprogramowania, w celu doskonalenia procesów wewnetrznych, podjęło prace (por. np. [Paulk95]) nad wdrożeniem opracowanego przez Softwa-re Engineering Institute SEI7, modelu Capability Maturity Model for Software (SW-CMM). W 2000 roku wydał CMMI-SE/SW zintegrowany model obejmu-jący zarówno problematykę oprogramowania, jak również problematykę inży-

7 Przy Cornegie Melion University, por. http://www.sei.cmu.edu/.


nierii systemów. Zarówno SW-CMM, jak również CMMI-SE/SW dostarczają specyficzne rekomendacje dla rozwijania oraz zarządzania wymaganiami. Krót-ki opis tych modeli z punktu widzenia problematyki wymagań można znaleźć w załączniku do książki Karla Wiegersa [Wieg03]. Modele te nie pokrywają ca-łości procesu wymagań (por. np. [Rog98; BeHR03]), co zaowocowało dużą iloś-cią modeli dojrzałości ukierunkowanych na doskonalenie procesu wymagań u developerów. Oto najlepiej zweryfikowane modele, zalecane do przeanalizo-wania: REGPG [SoSa97], REPM [GoTe02], RMM [Heum03], R-CMM [BeHR03], [TrAl08], Uni-REPM [Nguy10], IAG [WWW1]. Ze szczególnym zainteresowaniem spotkał się pierwszy z wymienionych modeli (por. np. [KaAK02; SoRa05; XuSS06; SDYS09]). Jak zauważają autorzy, „(…) od-miennie niż CMM lub ISO 9001-3, REGPG w swoim zamiarze nie ma służyć jako standard lub do celów akredytacji, lecz jako praktyczny przewodnik łatwy do zrozumienia, a także łatwy w stosowaniu”. W procesie oceny developera rozważono 66 dobrych praktyk sklasyfikowanych według ośmiu obszarów oraz trzech poziomów (Zał. 1). Przydzielono oceny powszechności stosowania każdej z praktyk. – 0 – praktyka nigdy niestosowana (lub prawie nigdy), – 1 – praktyka stosowana sporadycznie (jeśli ktoś zadecyduje o jej zastoso-

waniu), – 2 − praktyka często stosowana (nie jest jednak standardem), – 3 − praktyka zawsze stosowana (jest standardem).

Obliczono wskaźniki sumaryczne S1 − suma ocen za kryteria z poziomu podstawowego oraz S23 – suma ocen za kryteria z pozostałych poziomów. Po-ziom dojrzałości odczytano z poniższej tabeli.

Tabela 2

Poziomy dojrzałości modelu REGPG

Lp. Poziom dojrzałości Warunek Komentarz

1 Początkowy S1 < 56 Proces wymagań planowany ad hoc. Wynik zależy od realizatorów

2 Powtarzalny S1 > 55, S23 < 41 Developer otwarty na narzędzia wspomagające prace oraz na ulepszanie praktyk

3 Zdefiniowany S1 > 85, S23 > 40 Developer stosuje dobre praktyki inżynierii wymagań na co dzień

Źródło: Na podstawie: [SoSa97].


Słabo ocenione praktyki stają się wskazówką dla potrzeb dalszego doskona-lenia. Poziomy 1 oraz 2 korespondują z odpowiednimi poziomami modeli SEI, w przypadku poziomu trzeciego, w nawiązaniu do znaczącej nieokreśloności w obszarze wymagań nie da się dokładnie sprecyzować poziomu korespondują-cego modelu SEI (3, 4 lub 5).

W analizie przypadków skonfrontowano jak przedstawione modele i zale-cenia są realizowane w praktyce. Arao, Goto i Nagata [ArGN05] podejmują istotny problem przejścia od modelu biznesowego do modelu systemowego, ze-stawiając „jaki być powinien proces wymagań” z „jaki proces wymagań jest” por. tab 3.

Tabela 3

Lp. Jak być powinno? Jak jest?

1 Klienci i developer zgadzają się na nowy proces biznesowy dla realizacji celów projektu

Spojrzenie klienta oraz developera na nowy proces nie jest jednoznaczne

2 Developer adekwatnie wydobywa oraz definiuje wymagania klientów dotyczące systemu/oprogramowania

Developer określa wymagania klienta do pewnego stopnia, ale nie na poziomie szczegółowym

3 Developer definiuje specyfikację, która spełnia wymogi klienta

Developer odkrywa wymagania klienta w nawiązaniu do postępu prac nad specyfi- kacją wymagań

4 Developer zarządza zmianami wymagań szybko i dokładnie, zgodnie ze zmianami wymagań klienta

Developer nie jest zdolny zarządzać zmianami wymagań adekwatnie oraz termi- nowo, z powodu zbyt dużej liczby zmian

Popularne wyjaśnienie dla rozbieżności między tym, co być powinno,

a tym, co jest, głosi, że użytkownik nie jest zdolny stanowić o swoich preferen-cjach przy przejściu do modelowania systemowego bez kontaktu z artefaktami świata rzeczywistego. Autorzy rozważanych badań nie do końca podzielają po-wyższe wyjaśnienie. Analizując przykładowy proces „śledzenie wyników bizne-sowych w tygodniu poprzedzającym złożenie zamówienia”, dostrzegają złożo-ność techniczną (m.in. potrzeba współdziałania punktu sprzedaży utrzymującego sprzedaż z ubiegłego tygodnia z systemem finansowym naliczającym wskaźniki oraz mechanizmami adekwatnej prezentacji). Każdemu procesowi odpowiada wiele funkcji systemowych, następuje zmiana terminologii oraz dodanie szcze-gółów technicznych, które mogą w istotny sposób oddziaływać na proces bizne-sowy. Narzuca się tutaj powiedzenie, że niestety „diabeł tkwi w szczegółach” takiej operacji. W rzeczywistości ponieważ niemożliwe jest wyartykułowanie wymagań w tym samym czasie zarówno dla klientów, jak i developerów, to pro-ces musi być do pewnego stopnia ciągły i interaktywny, aby wymagania okazały się zrozumiałe i dokładne. Autorzy budują narzędzia autorskie wspomagające


specyfikowanie oraz śledzenie (tracing) wymagań pozyskiwanych w procesie przejścia od modelu biznesowego do SRS na podstawie Microsoft Excel oraz Access. Dalsze prace projektowo wdrożeniowe prowadzą do następujących kon-kluzji: – nie można rozpoczynać procesu przechodzenia do SRS zanim spojrzenie biz-

nesowe nie będzie ustabilizowane, – należy starać się negocjować model wymagań ze wszystkimi interesariusza-

mi, – proponowane rozwiązanie sprawdzało się w różnorodnych realizowanych

projektach, – brak szkoleń członków projektu oraz liderów powoduje niepowodzenie pro-

cesu implementacji.

2. Podejście zorientowane na użytkownika Podejście zorientowane na użytkownika (UOD – User Oriented Design)

uzyskało międzynarodową nobilitację najpierw w 1999 roku w postaci standardu ISO 13407, a następnie po aktualizacji, w nawiązaniu do numeracji zgodnej z innymi standardami użyteczności, w postaci obowiązującego obecnie standar-du ISO 9241-2108. Standard jest postrzegany jako manifest skierowany do roz-proszonych środowisk stosujących UOD nawołujący do zjednoczenia. Organi-zacje, które decydują się na jego wykorzystanie uzyskują terminologiczne i metodyczne wsparcie wypracowane przez międzynarodowe gremia ekspertów.

Rozważania rozpoczęto od przypomnienia pryncypiów podejścia zoriento-wanego na użytkownika (Por. Zał. 3).

W standardzie ISO 9241-210 podstawową, wyróżnioną aktywnością jest identyfikowanie i specyfikowanie wymagań. Zaleca się utworzenie jednoznacz-nie określonych wymagań użytkownika w stosunku do zamierzonego kontekstu wykorzystania oraz celów biznesowych systemu.

Tradycyjne podejścia inżynierii wymagań koncentrowały się na identyfi-kacji funkcjonalnych wymagań oraz na zapewnieniu, aby rozwijany produkt je spełniał. Inne niefunkcjonalne wymagania (wydajności, niezawodności, uży-teczności, łatwości konserwacji, rentowności) miały mniejsze znaczenie. Do-piero z perspektywy użytkownika, niefunkcjonalne wymagania stają się kry-tyczne dla powodzenia we wdrożeniu nowego systemu. Z perspektywy użytkownika zasadne staje się pytanie czy dotychczasowe procesy, również te, które wiążą się z działaniem przyszłego systemu, ale nie będą informatyzowane,

8 W Polsce 21 lutego 2011 ukazał się w postaci normy PN-EN ISO 9241-210:2011. Ergonomia

interakcji człowieka i systemu -- Część 210: Projektowanie ukierunkowane na człowieka w przypadku systemów interaktywnych.


nie powinny być zreorganizowane. W szerszym oraz lepiej umocowanym gronie interesariuszy rozwija się problematyka modelowania biznesowego, która nabie-ra większego znaczenia oraz uzyskuje potrzebne możliwości realnego oddziały-wania. Zaczyna uwierać niezrozumiała dla użytkownika tradycyjna specyfikacja. Rozwija się alternatywa tradycyjnej specyfikacji, w tym prototypy i bardziej iteracyjne oraz przyrostowe podejścia, znajdujące swoje miejsce w rozszerzonej specyfikacji wymagań, która przekonująco opisuje w jaki sposób przyszły sys-tem będzie funkcjonował. Przyszły użytkownik wiele uwagi poświęca ważnej i zrozumiałej dla niego specyfikacji wejść i wyjść. Napotykając na różnorodne problemy w komunikacji bezpośredniej, można dostrzec potrzebę modelowania umysłowości odbiorcy naszej pracy, utworzenia tzw. modelu mentalnego. Model mentalny daje głębsze zrozumienie ludzi, ich motywacji, procesów myślowych, a także otoczenia emocjonalnego i filozoficznego działań. Może być reprezen-towany poprzez diagram afiniczny (podobieństwa) zachowań użytkowników [You08].

W wielu pracach są analizowane zalety i wady modelowania biznesowego oraz systemowego z wykorzystaniem UML oraz innych rozwiązań. Wiele in-teresujących, z perspektywy problematyki specyfikowania wymagań, analiz przedstawił Martin Glinz ze współpracownikami. W artykule z 2000 roku [Glin00] w nawiązaniu do analizy przykładowego systemu (zdalnej opieki me-dycznej) przedstawił, szeroko wzmiankowane w innych pracach, dziewięć sła-bości analizy wymagań opartej na UML9. W kolejnym artykule [FrGK06] w nawiązaniu do wcześniejszych badań podjęto obserwację oraz analizę pracy wyróżnionego zespołu projektowego. W trakcie pierwszego miesiąca pracy ze-spół poszukiwał, techniką prób i błędów, adekwatnej do kontekstu, metody pra-cy z wymaganiami. Poczynając od najprostszych metod, rozwijał swój arsenał przydatnych w danej sytuacji rozwiązań, dochodząc do metody Ericssona- -Penkera, która została przyjęta jako metoda wiodąca. W trakcie kolejnych dwóch miesięcy udało się zespołowi z wykorzystaniem wypracowanych, w sze-rokim zakresie autorskich, podstaw metodycznych opracować adekwatną spe-cyfikację wymagań. W trakcie poszukiwań zespół zaadaptował Enterprise Architecta, które to narzędzie zostało z powodzeniem wykorzystane w trakcie dalszych prac.

9 1. Brak elementów aktywnych w diagramach przypadków użycia. 2. Brak możliwości re-

prezentowania kontekstu – zależności między aktorami. 3. Brak możliwości adekwatnego modelowania struktury przypadków użycia i hierarchii. 4. Brak możliwości adekwatnego spe-cyfikowania interakcji między przypadkami użycia. 5. Trudność modelowania zależnych od stanu zachowań systemu. 6. Nieporęczne modele przepływu informacji. 7. Brak możliwości modelowania zachowań charakterystycznych dla komponentów wysokiego poziomu, takich jak podsystem. 8. Trudności przy modelowaniu dekompozycji systemu rozproszonego. 9. Brak aspektowo zorientowanego spojrzenia na złożony system.


3. Podejście zwinne Podejście zwinne wyłoniło się w kontekście dyskusji nad cyklem życia

oprogramowania na początku naszego wieku. Dominujące w poprzednim wieku modele: kaskadowy, spiralny oraz prototypowania, wypracowane przez takie au-torytety, jak Winston Royce, Barry Bohm, Daniel McCracen, Michael Jacobson oraz Garry Russel Gladden dały podstawę dla metodyk określanych jako twarde, z racji ich ukierunkowania na rozległą dokumentację, rozbudowane procesy, długie oraz sekwencyjne fazy. Jak wynika jednakże również z przedstawionych wcześniej rozważań, w praktyce szczególnie w niewielkich firmach rozwiązania te w całości nie przyjęły się oraz trwały poszukiwania alternatywnych (lekkich) rozwiązań (por. tab. 4).

Tabela 4

Przykładowe lekkie rozwiązania metodyczne

jakie wyłoniły się w latach 90.

Rok Metodyka Twórca Liczba praktyk

Liczba ról

Liczba artefaktów

1991 Crystal Methods Alistair Cockburn 14 10 25

1993 Scrum Jeff Sutherland 5 3 5

1993 Dynamic Systems Dev. Grupa firm brytyjsk 15 12 23

1998 Extreme Programming Kent Beck 28 7 7

Twórcy podejść alternatywnych dostrzegając potrzebę wymiany doświad-

czeń, w 2000 roku skorzystali z zaproszenia Kenta Becka i spotkali się po raz pierwszy na konferencji w Oregon. Bob Martin we wrześniu 2000 roku zaprosił liderów wyłaniającego się lekkiego podejścia na następne spotkanie w 2001 ro-ku. Alister Cockburn rekomendował zastąpienie, używanego dla potrzeb identy-fikacji proponowanych rozwiązań metodycznych, określenia „lekkie” określe-niem „zwinne”. Następne spotkanie odbyło się w dniach 11-13 lutego 2001 roku w Utah, gdzie zgromadziło się 17 entuzjastów nowego kierunku. Rezultatem spotkania było powołanie zrzeszenia nazywanego Agile Alliance mającego na celu promowanie podejść zwinnych i wspieranie osób zainteresowanych [WWW4]. Ogłoszono Manifest Zwinnego Wytwarzania Oprogramowania sfor-mułowany w postaci czterech ogólnych reguł oraz dwunastu szczegółowych zasad (por. np. [MaMa08, s. 39-46]). Już pierwsze spojrzenie na pryncypia po-dejścia zwinnego wskazuje na zasadniczą zmianę optyki patrzenia na proble-matykę analizy wymagań. Rozwój polega na rozszerzeniu dotychczasowego logicznego, systemowego spojrzenia o: kontekst retrospektywnej, krytycznej


analizy dotychczasowych praktyk, przejęte z nauk zarządzania zagadnienia organizacji pracy wysoko wydajnych zespołów oraz tworzenie samoorganizują-cych się, szczupłych rozwiązań, a także na fascynacji kulturą kaizen.

Bardziej szczegółową analizę rozpoczęto od zagadnienia wyłaniania wizji systemu. Podstawowym założeniem podejścia zwinnego jest ograniczenie wstępnych prac koncepcyjnych (tzw. paraliżu przez analizę), krótki cykl dostar-czenia produktu, a następnie szybkie adaptacje produktu zgodnie z aktualną od-powiedzią płynącą z rynku. Niemniej jednak osoba reprezentująca interesariu-szy, w SCRUM − właściciel produktu, w trakcie sesji poświęconej planowaniu wydania poddaje pod dyskusję wizję produktu. Aby dobrze spełnić swoje zada-nie, właściciel projektu powinien zastanowić się nad obszarami projektu (tzw. drajwery projektu), w których oczekuje na generowanie wartości, patrząc z punktu widzenia biznesu. Uczestnicy mogą zastanawiać się nad zwrotem z in-westycji. W nawiązaniu do problemu projektowania produktu dobrze jest wcześ-niej opracować tzw. minimalny zestaw jego cech marketingowych (MMFS). Zwinna wizja komunikuje intencje strategiczne oraz odpowiada na następujące pytania: – dlaczego budujemy ten produkt, system lub aplikację? – jaki problem rozwiązuje? – jakie cechy oraz korzyści dostarcza? – komu są dostarczane te cechy oraz korzyści? – jaka wydajność, niezawodność i skalowalność wiąże się z produktem? – jak wygląda porównanie produktu z istniejącymi już na rynku oraz z przy-

gotowywanymi do wydania? – jak będziemy uzyskiwać zysk na sprzedaży? Jakie będą źródła przychodów

oraz jaki będzie model biznesowy? – czy mamy zdolność wykonania produktu? Czy będziemy w stanie produkt

rozwijać? Jaka będzie roadmapa rozwoju produktu? Analizując dobre praktyki, szczególnie w obszarze RUP, gdzie dokument

wizji jest jednym z kluczowych, szczegółowo opracowywanym artefaktem, Dean Leffingwell zaleca [Leff11], aby również w zwinnych projektach, zwłasz-cza w dużych, taki dokument opracowywać. Postuluje jednak, aby w nawiązaniu do zasad podejścia zwinnego opracowywać tylko jeden dokument wizji liczący od 5 do 10 (maks. 20) stron, tak aby aktualizacja tego dokumentu nie była uciąż-liwa. W załączniku do ostatniej książki Deana można znaleźć przykładowy wzo-rzec dokumentu wizji dla potrzeb projektów zwinnych (4 strony).

W odpowiedzi na pytanie jak wypełnić wzorzec wizji dla potrzeb projektów zwinnych Roman Pichler [Pich10] zaleca takie techniki, jak: prototypy (pa-pierowe, sketches, spikes, mock-up), personas and scenerios (identyfikowanie się z klientem oraz zbadanie jak produkt oddziałuje na jego życie), vision box lub trade journal review (zastanowienie się nad trzema wypunktowaniami „sprzedającymi” produkt do centralnego umieszczenia na opakowaniu lub przez


retrospekcje przeanalizowanie, co chciałoby się przeczytać o produkcie po jego wydaniu), Kano model (projektowanie funkcjonalności produktu poprzez wy-różnienie funkcji podstawowych, wydajnościowych oraz wywołujących za-chwyt).

Znaczącym wkładem podejścia zwinnego do problematyki specyfikowania wymagań jest wyartykułowana (Kent Beck) pierwotnie w ramach podejścia eks-tremalnego (XP) koncepcja krótkich wypowiedzi użytkowników (historii użyt-kownika) − spisu rzeczy jakie system powinien zdaniem użytkownika robić. Hi-storia użytkownika rozpoczyna tzw. grę planistyczną, w ramach której najpierw w wyniku intensywnych kontaktów między developerami oraz użytkownikami zbyt duże historie są dzielone na mniejsze oraz zbyt małe są scalane w większe. Developerzy przypisują każdej historii użytkownika koszt jej wykonania, a użytkownicy wybierają historie, które będą realizowane w następnej iteracji, nawiązując do szacowanej wydajności zespołu. W wyniku prac Mike’a Cohna historie użytkownika zostały zaadaptowane również w SCRUM jako narzędzie do budowy rejestru produktowego oraz przy definiowaniu zawartości poszcze-gólnych iteracji – tzw. Sprintów. W nawiązaniu do problematyki specyfikowania wymagań historia użytkownika może być postrzegana jako wysokopoziomowy opis wymagań do zaimplementowania. W zrozumieniu tego związku pomaga rozwijana w ramach podejścia zwinnego koncepcja poruszającego doku- mentu10 − spełniającego rolę pamięci zewnętrznej ilustrującej w obrazowej, po-ruszającej wyobraźnie formie bieżącą komunikację w zespole projektowym. Po-ruszające dokumenty silnie nawiązują do kontekstu, są dokumentacją do bieżą-cego wykorzystania w odróżnieniu od dokumentów reprezentacyjnych (por. np. [Elss10]). W podejściu zwinnym historia użytkownika jest przykładem porusza-jącego dokumentu o bardziej sformalizowanej postaci (np. według Mike’a Coh-na „Jako <rodzaj użytkownika>, chcę <cel>, tak aby <uzasadnienie>” [Co04, s. 127]), który przykładowo mógłby przyjąć następującą postać: „Jako użytkow-nik standard chcę, aby przy dużym jednorazowym zakupie był udzielany rabat, tak aby duży jednorazowy zakup był bardziej konkurencyjny”.

W podejściach zwinnych centralne znaczenie, z perspektywy wymagań, ma proces opracowywania testów w nawiązaniu do praktyk: zautomatyzowane testy programisty, wytwarzanie kończone testami lub wytwarzanie poprzedzone tes-tami (WPT). Jakkolwiek dalsze rozważania są w dużej części prawdziwe rów-nież dla dwóch pierwszych praktyk, to najbardziej wyraźne powiązania można uzyskać w przypadku wdrożenia praktyki WPT. Na wstępie należy zauważyć, że sztuka pisania testów rozwiązuje w ramach podejść zwinnych problem wyż-szego piętra specyfikacji wymagań. Odnosi się to zarówno do testów jednostko-wych (białej skrzynki), gdy programista powodowany wymaganiami wyraża swoje intencje w formie testu, jak również akceptacyjnych (czarnej skrzynki),

10 Ang. evocative document.


w których interesariusz sprawdza czy jego wymagania zostały właściwie zrozu-miane, a programista implementuje wymagania w postaci kodu. W jednej z kon-kluzji książki Roberta Martina i Mican’a Martina można przeczytać, że „(…) zarówno testy jednostkowe, jak i akceptacyjne pełnią funkcję swoistej dokumen-tacji. Ponieważ dokumentacja w tej formie może być kompilowana i wykony-wana, jej wiarygodność i precyzja nie powinny budzić najmniejszych wątpli-wości. Co więcej, tego rodzaju testy są pisane w jednoznacznych językach zrozumiałych dla właściwych grup odbiorców” [MaMa08, s. 82]. Nie można za-kończyć analizy problematyki dokumentowania wymagań w podejściach zwin-nych bez spojrzenia z perspektywy refaktoryzacji kodu, stanowiącego w swojej istocie również kolejne piętro specyfikacji wymagań. Dla programisty kod nie-refaktoryzowany jest kodem ciężkim, zwykle niezrozumiałym, a jego leczenie w formie ekstremalnej nawiązuje do leczenia objawowego według mechanizmu czarnej skrzynki. Przeciwnie lekki, refaktoryzowany kod stanowi o zdolności do przetrwania oprogramowania w burzliwym, zmieniającym się otoczeniu.

Z uwagi na wymogi dotyczące objętości artykułu, przeanalizowano jedynie wyzwanie jakie stoi przed twórcami gier komputerowych. Dynamika rozwoju kosztów jest w tym obszarze znacznie większa niż dynamika rozwoju rynku. Branża staje na rozdrożu: Czy czeka ją kryzys podobny do tego z 1983 roku, czy też uda się wypromować nowe rynki, a może wystarczy odchudzająca terapia z wykorzystaniem podejścia zwinnego? W tym sektorze rynku liczy się radość z grania, o której można orzekać trzymając w ręku manipulator. Każdy dzień zyskany dla bardziej obiecującego projektu poprzez precyzyjniejszą identyfika-cję oraz wycofywanie projektów brnących ku klęsce może stanowić o „być albo nie być” firmy. Znamienne są doświadczenia firmy CCP Games zatrudniającej ponad 400 pracowników w trzech lokalizacjach: Reykjavik, Atlanta oraz Shang-hai. Jesienią 2008 roku, CCP podjęła ambitne wyzwanie zaprojektowania dodatku do EVE Online o nazwie Apokryfy w ciągu sześciu miesięcy. W przy-padku Apocrypha udana realizacja oznaczała współdziałanie ponad 120 deve-loperów w 13 zespołach Scrum zatrudniających 9 właścicieli produktu oraz po-mieszczonych na trzech kontynentach (por. [Keit10]). Zwinne rozwiązania sprawdzają się więc również w dużych projektach.

Podsumowanie Uczyniono znaczące wysiłki badawcze w zakresie poszukiwania modelu

inżynierii wymagań. Weryfikacje empiryczne wskazują, że pierwsze wielo-krotnie cytowane modele mają charakter raczej normatywny niż opisowy. Model Sommerville’a wydaje się być rozsądnym kompromisem. Ciekawą własnością tego modelu jest jego podobieństwo do zalecanego dla procesów innowacyjnych modelu Stewarta – Deminga PDCA.


Kolejny rozważony problem dotyczy rozwoju dojrzałości provaiderów w obszarze wymagań. Modele CMMI-SW dostarczają stabilną, choć nie zawsze wystarczającą podstawę. Wskazane środowiska badawcze oraz provaiderzy rozwijają te rozwiązania dodając własne narzędzia, które doskonalą zwarty schemat myślowy zaproponowany w jednym z pierwszych tego typu rozwiązań, zaproponowany przez Sommerville’a oraz Sawyera. Z uwagi na brak opracowa-nia tego modelu w literaturze krajowej został on w artykule szerzej scharaktery-zowany.

Umiejętne wykorzystanie narzędzi, również autorskich, wspomagających proces zarządzania wymaganiami może znacząco wpłynąć na skuteczność developera. Wykorzystanie tego typu narzędzi niestety nie jest powszechne. Ak-tualny krótki przegląd narzędzi można znaleźć np. w [ShSM11] .

Wydanie normy PN-EN ISO 9241-210:2011 inspiruje do przedstawienia oraz dalszego przedyskutowania pryncypiów podejścia zorientowanego na użyt-kownika. Podejście to rekomenduje potrzebę, metody oraz dobre praktyki głęb-szego uwzględnienia kontekstu użytkownika w procesie prac nad wymaganiami.

Introspektywne badania Glinza identyfikują występujący w praktyce proces poszukiwania adekwatnych do kontekstu konkretnych rozwiązań w nawiązaniu do ogólnych modeli, norm oraz praktyk . Ten kluczowy, słabo opisany, proces determinuje sukces lub porażkę projektu.

Kontekst wymagań w podejściu zwinnym jest istotny, coraz lepiej rozu-miany oraz opisany w aktualnie ukazującej się literaturze. Wyłaniają się cztery poziomy szczegółowości rozważań: – poruszająca, kolektywnie rozwijana wizja, – napędzające kolejne iteracje, adekwatnie skalowane oraz wybierane do reali-

zacji historie użytkownika, – sprawujące piecze nad zmianami testy, – refaktoryzowany kod.

Wypracowane w ramach różnych podejść rozwiązania mogą być integro-wane adekwatnie do potrzeb. Przykładem może być rozwijanie dojrzałości wy-magań w zespołach wykorzystujących podejście zwinne.

Literatura

[ArGN05] Arao T., Goto E., Nagata T.: „Business Process” Oriented Requirements Engineering Process. RE '04 Proceedings of the 13th IEEE International Conference on Requirements Engineering. IEEE Computer Society, Wash-ington.

[BeHr03] Beecham S., Hall T., Rainer A.: Software Process Improvement Problems in Twelve Software Companies: An Empirical Analysis. „Empirical Software Engineering” 2003, Vol. 8, No. 1.


[Co04] Cohn M.: User Stories Applied for Agile Software Development. Addison- -Wesley, 2004.

[Elss10] Elssamadisy A.: Agile wzorce wdrażania praktyk zwinnych. Helion, Gliwice 2010.

[FrGK06] Fricker S., Glinz M., Kolb P.: A Case Study on Overcoming the the Require-ments Tar Pit. „Journal of Universal Knowledge Management” 2006, Vol. 1, No. 2.

[Gaje03] Gajewski P.: Koncepcja struktury organizacji procesowej. TNOiK, Toruń 2003.

[Glin00] Glinz M.: Problems and Deficiencies of UML as a Requirements Specifi-cation Language. Procedings of the 10th International Workshop on Software Specification and Design (IWSSD-10), San Diego, November 2000.

[GoTe02] Gorschek T., Tejle K.: A Metod for Assessing Requirements Engineering Process Maturity in Software Projects. Blenking Institute of Technology, Master Thesis Computer Science no. MSC-2002:2, 2002.

[Heum03] Heumann J.: The Five Levels of Requirements Management Maturity, http://www.therationaledpe.com/conIenI/feb 03/f_managementMaturity_jh. jsp [dostęp: 28.11.2012].

[HoPo00] Houdek F., Pohl K.: Analyzing Requirements Engineering Process a Case Study. Proceedings of the 11th International Workshop on Database and Expert Systems Applications, Greenwich, UK 2000.

[KaAK02] Kauppinen M., Aaltio T.. Kujala S.: Lessons Learned from Applying the Re-quirements Engineering Good Practice Guide for Process Improvement. In: Proceedings of the 7lh European Conference on Software Quality, Hel-sinki.

[Keit10] Keith C.: Agile Game Development with Scrum. Addison-Wesley, Boston 2010.

[KoSo98] Kotonya G., Sommerville I.: Requirements Engineering − Processes and Techniques. John Wiley & Sons. UK 1998.

[Lams09] Lamsweerde A.: Requirements Enginering. John Wiley & Sons, 2009. [Leff11] Leffingwell D.: Agile Software Requirements. Pearson Education, 2011. [Maca96] Macaulay L.A.: Requirements Engineering. Springer-Verlag, Berlin, Heidel-

berg, New York 1996. [MaMa08] Martin R., Martin M.: Agile programowanie zwinne. Helion, Gliwice 2008. [Nguy10] Nguyen T.: The Creation of Uni-REPM. Blenking Institute of Technology,

Master Thesis Computer Science no. MSE-2010:27, 2010. [Paulk95] Paulk M., Weber C., Curtis B., Chrissis M.: The Capability Maturity Model:

Guidelines for Improving the Software, Process. Addison-Wesley, Reading- -MA, Boston 1995.

[Pich10] Pichler R.: Agile Product Management with SCRUM. Addison-Wesley, 2010.

[PISO11] PN-EN ISO 9241-210:2011 Ergonomia interakcji człowieka i systemu -- Część 210: Projektowanie ukierunkowane na człowieka w przypadku sys-temów interaktywnych.


[Rog98] Rogoway P.: How to Reap the Business Benefit from SPI: Adding SPICE while Preserving the CMM (Motorola): SPI NEWSPAPER, http://www.iscn. at/select_newspaper/assessments/motorola.html [dostęp: 28.11.2012].

[SAJP02] Sacha M., Aurum A., Jeffery J., Paech B.: Proceedings of the Seventh Aus-tralian Workshop on Requirements Engineering Process Models in Practice, http://www.deakin.edu.au/events/awre02/Melbourne, 2002, http://sunsite. informatik.rwth-aachen.de/Publications/CEUR-WS//Vol-69 [dostęp: 28.11.2012].

[SAJP02] Sacha M., Aurum A. Jeffery R., Paech B.: Requirements Engineering Pro-cess Models in Practice. The seventh Australian Workshop on Requirements Engineering: proceedings, Melbourne, Victoria, School of Information Sys-tems, Deakin University, 2002.

[SDYS09] Shrivastava A., Darhan M., Yagyasen D., Singh V.: An Efficient Evaluation of Requirements Engineering Maturity Measurement Framework For Medi-um and Small Scale Software Companies. Proceedings of the 3rd National Conference; INDIA Com-2009, Computing For Nation Development, Feb-ruary 26-27, 2009.

[ShSM11] Shahid M., Ibrahim S., Mahrin M.: An Evaluation of Requirements Man-agement and Traceability Tools. World Academy of Science, Engineering and Technology 78, 2011, http://www.waset.org/journals/waset/v54/v54-117.pdf [dostęp: 28.11.2012].

[Somm03] Sommerville I.: Inżynieria oprogramowania. WNT, Warszawa 2003. [Somm05] Sommerville I.: Integrated Requirements Engineering: A Tutorial. IEEE

Software, 2005. [SoRa05] Sommerville I., Ransom J.: An Empirical Study of Industrial Requirements

Engineering Process Assessment and Improvement. ACM Transactions on Software Engineering and Methodology. 14(1).

[SoSa97] Sommerville L Sawyer P.: Requirements Engineering: A Good Practice Guide. Wiley, Chichester, l997.

[StGr04] Standish Group: Charting the Seas of Information Technology – Chaos. The Sandish Group International, West Yarmouth 1994.

[TrAl08] Tripathi S., at all: An Efficient Evaluation of Requirements Engineering Pro-cess Maturity Assessment and Improvement. Proceedings of the 2nd National Conference; INDIA Com-2008, Computing For Nation Development, Feb-ruary 08-09, 2008.

[Wieg03] Wiegers K.: Software Requirements. Microsoft Press, 2003. [WWW1] http://www.iag.biz/business-analysis-resources/landing/self-assessment-tool.

html [dostęp: 28.11.2012]. [WWW4] http://www.agilealliance.org [dostęp: 28.11.2012]. [XuSS06] Xu H., Sawyer P., Sommerville I: Requirement Process Establishment and

Improvement from the Viewpoint of Cybernetics. „The Journal of Systems and Software” 2006, 79.

[Youn08] Young I.: Mental Models. Aligning Design Strategy with Human Behavior. Rosenfeld Media, 2008.

Załąc

znik

1 Ze

staw

ienie

wybr

anyc

h te

chni

k inż

ynier

ii wym

agań

Tech

nika

M

ocne

stro

ny

Słab

e st

rony

Wyw

iad

Dla

zew

nętrz

nego

obs

erw

ator

a pr

zypo

min

a ro

zmow

ę, je

dnak

role

są

zróżn

icow

ane.

Oso

ba p

rzep

row

adza

jąca

wyw

iad −

anki

eter

dąż

y do

poz

yska

nia

info

rmac

ji or

az m

oże

posł

ugiw

ać się

wcz

eśni

ej p

rzy-

goto

wan

ymi p

ytan

iam

i tzw

. wyw

iad

ustru

ktur

aliz

owan

y lu

b je

dyni

e dy

spoz

ycja

mi d

o w

ywia

du, c

zyli

luźn

o sf

orm

ułow

anym

i pro

ble-

m

ami –

tzw

. wyw

iad

swob

odny

, nie

ustru

ktur

aliz

owan

y (s

ytua

cja

ba

rdzi

ej z

bliż

ona

do n

atur

alne

j roz

mow

y). O

soba

odp

owia

dają

ca –

re

spon

dent

star

a się

prze

kazać

wie

dzę

w o

dpow

iedz

i na

pyta

nia.

Py

tani

a m

ogą

być

zam

knię

te, g

dy z

awie

rają

okr

eślo

ne m

ożliw

ości

od

pow

iedz

i tzw

. kaf

eter

ie (k

oniu

nkty

wne

lub

dysj

unkt

ywne

) lub

ot

war

te g

dy re

spon

dent

owi d

aje

się

swob

odę

odpo

wie

dzi,

a an

kiet

er

przy

tacz

a od

pow

iedź

dosło

wni

e.

• m

ożliw

ość

pozy

skan

ia b

ogat

ych

oraz

sz

czeg

ółow

ych

dany

ch; w

ywia

d pe

netru

je

zaka

mar

ki z

agad

nien

ia

• po

zwal

a na

rozw

inię

cie

/ uzu

pełn

ieni

e w

iedz

y an

kiet

era

• u

resp

onde

nta

rozw

ija się

zaan

gażo

wan

ie o

raz

zroz

umie

nie

proj

ektu

•

natu

raln

a ko

mun

ikac

ja z

uw

zglę

dnie

niem

el

emen

tów

nie

wer

baln

ych

ułat

wia

pod

ejm

o-

wan

ie /

zroz

umie

nie

trudn

ych

prob

lem

ów,

otw

artość

ora

z sz

czer

ość

wyp

owie

dzi.

• w

ymag

a zn

aczą

cego

zaa

ngaż

owan

ia c

zasu

or

az w

ysiłk

u, głó

wni

e an

kiet

era,

ale

takż

e re

spon

dent

a •

wym

aga

zaan

gażo

wan

ia o

sób

o w

ysok

ich

umie

jętn

ości

ach

w o

bsza

rze

kom

unik

acji

inte

rper

sona

lnej

•

trudn

a do

zas

toso

wan

ia w

prz

ypad

ku d

użej

ilośc

i zróżn

icow

anyc

h in

tere

sariu

szy

– po

trzeb

a w

spom

agan

ia p

oprz

ez a

nkie

ty

• ef

ekty

ubo

czne

, tak

ie ja

k sp

ołec

znyc

h oc

zeki

wań

, hal

o, R

osen

thal

a, ..

. .

Wyw

iad

grup

owy

zogn

isko

wan

y1

Dru

ga c

o do

pow

szec

hnoś

ci w

ykor

zyst

ania

, po

przy

padk

ach

użyc

ia,

tech

nika

zal

icza

na d

o ja

kośc

iow

ych

met

od g

rom

adze

nia

dany

ch,

pole

gają

ca n

a pr

zepr

owad

zeni

u i a

naliz

ie k

ontro

low

anej

dys

kusj

i „k

olek

tyw

nej k

onw

ersa

cji”

na

dany

tem

at p

omię

dzy

ucze

stni

kam

i m

ałyc

h (6

-12

osób

) sta

rann

ie se

lekc

jono

wan

ych

grup

. Zw

ykle

nie

dąży

my

do u

zysk

ania

kon

sens

usu,

racz

ej c

hodz

i o p

reze

ntac

je/n

e-

gocj

acje

zna

czeń

, ide

i, op

inii,

ocz

ekiw

ań, o

bser

wac

ji, p

osta

w o

raz

zach

owań

.

• w

spie

rają

kre

owan

ie w

izji,

form

ułow

anie

py

tań

oraz

wer

yfik

owan

ie k

once

pcji,

gdy

br

ak je

st id

ei, h

ipot

ez, w

iedz

y, d

anyc

h •

moż

liwość

obse

rwow

ania

ora

z w

pływ

ania

na

zac

how

ania

w g

rupi

e •

moż

liwość

bard

ziej

efe

ktyw

nego

wyk

orzy

s-

tani

a cz

asu

niż

w p

rzyp

adku

wyw

iadu

, tem

aty

bard

ziej

wsz

echs

tronn

ie n

aśw

ietlo

ne

• w

ysok

ie k

wal

ifika

cje

osób

pro

wad

zący

ch

oraz

inte

rpre

tują

cych

wyn

iki

• re

zulta

ty różn

ią się

zazw

ycza

j od

wcz

eśni

ej-

szyc

h oc

zeki

wań

, mogą

być

spec

yfic

zne

• w

kład

ucz

estn

ików

jest

czę

sto

zróż

nico

wan

y •

szcz

egół

owe,

spec

yfic

zne,

sens

ytyw

ne

zaga

dnie

nia

mogą

okaz

ać się

nieo

dpow

ied-

nie

1 tzw

. fok

us o

d an

g. F

ocus

Gro

up In

terv

iew

FG

I


cd. z

ałąc

znik

1

Etno

graf

ia

Roz

legł

y ob

szar

wie

dzy

o ko

ntek

stual

izac

ji, b

adan

ia p

row

adzo

ne są

na

pod

staw

ie z

apis

ywan

ia w

ynik

ów b

ezpośr

edni

ch o

bser

wac

ji.

Tech

nika

uzn

awan

a ja

ko n

ieko

mpl

ekso

wa,

zaz

wyc

zaj łąc

zona

z

inny

mi t

echn

ikam

i np.

wyw

iade

m, p

roto

typo

wan

iem

lub

anal

izą

przy

padk

ów uży

cia.

Opi

sano

wie

le ro

zsze

rzając

ych

strat

egii,

taki

ch

jak

np. o

bser

wac

ji (ja

wne

j, ni

ejaw

nej,

ucze

stni

cząc

ej, n

ieuc

zest

- ni

cząc

ej, s

hado

win

g) i

foto

graf

ii so

cjol

ogic

znej

, fot

ogra

fii d

nia

ro

bocz

ego,

obs

erw

acje

mig

awko

we,

gru

py fo

kuso

we

z el

emen

tam

i ba

dani

a et

nogr

afic

zneg

o −

wyw

iady

gru

pow

e, n

a kt

óre

resp

onde

nci

przy

noszą

prze

dmio

ty, k

tóre

stają

się

bodź

cem

do

dysk

usji.

• po

zwal

a na

wer

yfik

ację

fakt

ów o

raz

założeń

• um

ożliw

ia p

recy

zyjn

e po

mia

ry

• po

mag

a od

kryw

ać n

ieja

wne

odd

ział

ywan

ia

oraz

wym

agan

ia (w

iedz

a uk

ryta

) •

ułat

wia

ana

lityk

om p

racę

nad

wym

agan

iam

i (w

izua

lizow

anie

, zw

ięks

zeni

e za

inte

reso

wan

ia, z

rozu

mie

nia,

pro

cesy

pa

mię

ci)

• zw

ykle

pon

osim

y re

laty

wni

e ni

ewie

lkie

ko

szty

• lu

dzie

mogą św

iado

mie

lub

nieś

wia

dom

ie

real

izow

ać in

acze

j sw

oje

działa

nia,

gdy

są

obse

rwow

ani

• za

obse

rwow

ane

przy

padk

i mogą

nie

być

typo

we

• ob

serw

ując

złożo

ne o

bsze

rne

proc

esy

moż

na w

ycią

gnąć

myl

ne, n

ieko

mpl

etne

w

nios

ki

• w

pew

nych

prz

ypad

kach

nie

moż

liwa

lub

niep

rakt

yczn

a

War

szta

t wym

agań

D

ośw

iadc

zeni

a pr

akty

ki w

skaz

ują

na p

otrz

ebę

zorg

aniz

owan

ia

war

szta

tu w

ymag

ań, p

odcz

as k

tóre

go k

lucz

owi i

nter

esar

iusz

e sp

otyk

ają

się

„pod

prz

ywód

ztw

em”

mod

erat

ora,

aby

inte

nsyw

nie

prac

ując

, z w

ykor

zyst

anie

m te

chni

k w

spom

agan

ia k

reat

ywnośc

i,

w c

iągu

1-2

dni

wyp

raco

wać

kon

sens

us będąc

y po

dsta

wą

defin

icji

wym

agań

. W w

ynik

u w

arsz

tató

w p

owst

ają śc

iśle

zaw

czas

u ok

reślo

ne re

zulta

ty.

• po

mag

a w

bud

owan

iu z

espołu

, któ

rego

czł

on-

kow

ie z

obow

iąza

li się

dążyć

do su

kces

u pr

ojek

tu

• w

szys

cy in

tere

sariu

sze

mają

moż

liwość

wyp

owie

dzen

ia się,

ksz

tałtu

je się

polit

yka

real

izac

ji pr

ojek

tu, r

ozw

ija się

zroz

umie

nie

wsp

ólni

e pr

zyję

tej d

efin

icji

syst

emu

oraz

m

odel

i wym

agań

, zw

ięks

za się

inno

wac

yj-

ność

pro

jekt

u

• cz

ynni

ki k

ryty

czne

zw

iąza

ne z

prz

ygot

o-

wan

iem

war

szta

tów

ora

z od

działy

wan

iem

os

oby

prow

adzą

cej

• dw

a wąt

ki o

sób

repr

ezen

tują

cych

stro

nę

bizn

esow

ą or

az o

sób

twor

zący

ch o

prog

ra-

mow

anie

•

niez

byt p

rzyd

atne

w p

rzyp

adku

mał

ych

proj

ektó

w o

nie

wie

lkim

ryzy

ku

Przy

padk

i uży

cia

Kon

cepc

ję p

rzyp

adkó

w uży

cia

stw

orzył I

var J

acob

son

w la

tach

80.

Po

dsta

wą

kons

trukc

ji je

st sc

enar

iusz

inte

rakc

ji, a

pon

adto

iden

tyfi-

kato

r, na

zwa,

spec

yfik

acja

akt

orów

, wyjąt

ków

i ro

zsze

rzeń

–

w w

ersj

i pod

staw

owej

. W la

tach

90.

prz

ypad

ki uży

cia

zost

ały

włą

czon

e do

języ

ka U

ML

oraz

uzy

skał

y at

rakc

yjną

pro

stą

repr

ezen

-ta

cję

graf

iczną.

Cie

szą

się

w d

alsz

ym c

iągu

wie

lkim

zai

nter

eso-

w

anie

m (są

używ

ane

w p

onad

50%

pro

jekt

ów) o

raz

rozw

ijają

się

w

naw

iąza

niu

do ro

zwoj

u ko

ncep

cji u

ser s

torie

s ora

z or

ient

acji

aspe

ktow

ej, o

czy

m Iv

ar Ja

cobs

on p

isze

na sw

ojej

stro

nie

inte

rne-

to

wej

.

• m

ożliw

y je

st p

rost

y op

is w

ymag

ań, n

awet

dla

duży

ch sy

stem

ów, z

różn

icow

ani i

nter

esa-

riu

sze

mogą

ucze

stni

czyć

ora

z w

nosić

wła

sny

wkł

ad

• do

brze

wko

mpo

now

ują

się

w p

roce

s roz

woj

u sy

stem

u, st

opni

owo

są u

szcz

egół

awia

ne o

raz

dosk

onal

one,

szcz

egól

nie

dobr

ze in

tegr

ują

się

z te

stow

anie

m o

raz

szac

owan

iem

i śle

dze-

ni

em p

rac

• z

przy

padk

ami uży

cia

wiąże

się

wie

le

mity

czny

ch o

pini

i, kt

óre

utru

dnia

ją ic

h st

osow

anie

, tak

ich

jak:

że

są te

chni

ką

deko

mpo

zycj

i, że

są o

dpow

iedn

ią i

wys

tar-

czającą

tech

niką

do

opisu

wsz

ystk

ich

wy-

m

agań

, że

służą

tylk

o do

ana

lizy

wym

agań

lu

b że

ta a

naliz

a m

usi b

yć n

adm

iern

ie

prac

ochł

onna


cd. z

ałąc

znik

1

Prot

otyp

Po

dkreśl

my

różn

orod

ność

, sze

roki

zak

res b

adań

i dośw

iadc

zeń

na

d w

ykor

zyst

anie

m w

stęp

nych

wer

sji,

pier

wow

zoró

w p

rzys

złeg

o ro

zwią

zani

a. K

ontin

uum

pro

toty

pów

rozw

aża

się

w c

zter

ech

wym

iara

ch: z

akre

s, fu

nkcj

onal

ność

, int

erak

cyjn

ość,

diz

ajn.

Pr

otot

ypy

o ni

ewie

lkim

zaa

wan

sow

aniu

, okr

eśla

ne te

rmin

em

low

-fide

lity,

obr

azują

konc

epcję,

alte

rnat

ywne

rozw

iąza

nia,

ukł

ad

ekra

nu. W

ażne

zna

czen

ie m

ają

w te

j gru

pie

tzw

. pap

iero

we

prot

otyp

y tw

orzo

ne p

rzy

pom

ocy

szki

ców

odręc

znyc

h, n

akle

jek,

op

rogr

amow

ania

wsp

omag

ając

ego.

Z k

olei

pro

toty

py h

igh-

fidel

ity

są z

azw

ycza

j w p

ełni

inte

rakt

ywne

, sta

now

ią fu

nkcj

onal

nośc

i pr

oduk

tu p

odst

awow

ego,

czę

sto

są ro

zwija

ne z

wyk

orzy

stan

iem

w

yspe

cjal

izow

anyc

h na

rzęd

zi (S

mal

ltalk

, Vis

ual B

asic

, wzo

rce,

Sh

areP

oint

). Po

dział n

a pr

otot

ypy

hory

zont

alne

ora

z w

erty

kaln

e

jest

z k

olei

zw

iąza

ny z

ukł

adem

dw

uwym

iaro

wym

(zak

res,

funk

cjo-

naln

ość)

. Sze

rsza

per

spek

tyw

a po

dejm

uje

prob

lem

inte

rakc

ji w

zaje

mny

ch o

raz

szcz

egół

y di

zajn

u.

• do

star

cza

konk

ret,

wok

ół k

tóre

go o

gnis

kuje

się

dial

og in

tere

sariu

szy

• po

zwal

a na

kon

cent

row

anie

się

na w

ybra

nych

as

pekt

ach

wym

agań

•

zwię

ksza

zaa

ngaż

owan

ie uży

tkow

nika

, prz

e-ci

wdz

iała

efe

ktom

ubo

czny

m u

trudn

iają

cym

w

ywia

d, w

szcz

egól

nośc

i pap

iero

we

pro-

to

typy

poz

wal

ają

na a

ktyw

ne d

osko

nale

nie

założeń

prze

z uż

ytko

wni

ka

• sz

czeg

ólni

e od

pow

iedn

i w p

rzyp

adku

tzw

. „t

rudn

ego

użyt

kow

nika

”, k

tóry

nie

jest

w

stan

ie fo

rmuł

ować

pre

cyzy

jnyc

h,

abstr

akcy

jnyc

h założeń

• pr

otot

ypy

low

-fide

lity

mogą

być

rozw

ijane

pr

zy n

iew

ielk

ich

kosz

tach

• zw

ięks

za w

ymag

ania

wob

ec p

roje

ktan

tów

, w

szcz

egól

nośc

i dzi

ałan

ia m

uszą

być

ef

ekty

wne

(tru

dne

bo in

form

atyc

y z

reguły

są

per

fekc

jona

lista

mi),

nar

zuca

reżi

m

krót

kich

wyd

ań, z

najo

moś

ci różn

orod

nych

na

rzęd

zi, u

mie

jętn

ości

kom

unik

acyj

ne

• częs

to sp

otyk

amy

efek

t „to

mi j

uż w

y-

star

cza”

, zw

iąza

ny z

insp

irow

aną

zwyk

le

prze

z uż

ytko

wni

ka c

hęcią

popr

zest

ania

na

aktu

alny

m ro

zwią

zani

u, b

ez z

rozu

mie

nia,

że

pro

toty

p ni

e sp

ełni

a w

ymag

ań n

p.

skal

owln

ości

i ro

zwoj

owoś

ci

• pr

zy st

osow

aniu

pro

toty

pów

hig

h-fid

elity

do

chod

zą n

owe

wym

iary

ryzy

ka

Mod

elow

anie

biz

neso

we

Mim

o sw

ojej

pow

szec

hnoś

ci p

oglą

d, ż

e m

ożliw

e je

st w

ykor

zys-

ta

nie

tech

nolo

gii d

o w

yelim

inow

ania

nie

dobo

rów

org

aniz

acji

nie

kwes

tionu

jąc

stru

ktur

y or

gani

zacj

i jak

o całośc

i, ok

azuj

e się

za-

zwyc

zaj f

ałsz

ywy.

Jest

to te

chni

ka sy

met

rycz

na d

o pr

otot

ypow

ania

, w

tym

sens

ie, ż

e w

spie

ra z

wię

ksze

nie

zroz

umie

nia

i akt

ywnośc

i pr

zez

anal

itykó

w w

spół

prac

ując

ych

z uż

ytko

wni

kam

i.

• zw

ięks

za się

zroz

umie

nie

prob

lem

atyk

i, pr

oble

mów

ora

z po

trzeb

inte

resa

riusz

y •

upro

szcz

one,

wye

limin

owan

e lu

b uz

asad

nio-

ne z

osta

ją p

roce

dury

co

do k

tóry

ch m

ogły

by

pow

stać

wąt

pliw

ości

•

wył

ania

ją się

lider

zy c

hętn

i i z

doln

i do

wsp

ół-

prac

y w

kol

ejny

ch e

tapa

ch

• sła

bo ro

zwin

ięte

są p

odsta

wy

met

odyc

zne

w

zak

resi

e in

tegr

owan

ia m

odel

u or

gani

za-

cyjn

ego

z ak

tyw

nośc

iam

i inż

ynie

rii w

y-

mag

ań

• ro

zległa

reinży

nier

ia p

oprz

edza

jąca

pra

ce

proj

ekto

we

jest

złożo

nym

prz

edsięw

zięc

iem

op

atrz

onym

zna

czny

m ry

zyki

em


Za

łączn

ik 2

Dobr

e pra

ktyk

i inży

nier

ii wym

agań

z po

dział

em n

a obs

zary

ora

z poz

iom

y

Obs

zary

do

bryc

h

prak

tyk

Pods

taw

owy

(36)

Pośr

edni

(21)

Za

awan

sow

any

(9)

1 2

3 4

I.

Dok

umen

t w

ymag

ań

• zd

efin

iuj s

trukt

urę

stan

dard

oweg

o do

kum

entu

sp

ecyf

ikac

ji w

ymag

ań

• w

yjaś

nij j

ak k

orzy

stać

z d

okum

entu

•

dołą

cz st

resz

czen

ie w

ymag

ań

• ut

wór

z uz

asad

nien

ie b

izne

sow

e •

zdef

iniu

j spe

cjal

isty

czne

term

iny

• za

dbaj

o c

zyte

lność

doku

men

tu

• po

móż

czy

teln

ikow

i zna

leźć

info

rmac

je

• uc

zyń

doku

men

t łat

wym

do

zmia

ny

− −

II.

Kre

owan

ie

wym

agań

• oc

eń w

ykon

alność

syst

emu

• bą

dź w

rażl

iwy

na k

wes

tie o

rgan

izac

yjne

i p

olity

czne

•

zide

ntyf

ikuj

i ko

nsul

tuj s

ię z

udz

iało

wca

mi

• ut

rzym

uj ź

ródł

a w

ymag

ań

• zd

efin

iuj ś

rodo

wis

ko o

pera

cyjn

e •

używ

aj li

sty

kont

roln

e pr

zy o

dkry

wan

iu w

ymag

ań

• w

yszu

kaj o

gran

icze

nia

dzie

dzin

owe

• ut

rzym

uj u

zasa

dnie

nia

wym

agań

•

wys

zuku

jąc

wym

agan

ia p

atrz

z

różn

ych

punk

tów

wid

zeni

a •

prot

otyp

uj sł

abo

zroz

umiałe

w

ymag

ania

•

wyk

orzy

stuj

scen

ariu

sze

przy

od

kryw

aniu

wym

agań

•

defin

iuj p

roce

sy o

pera

cyjn

e

• w

ielo

krot

nie

używ

aj te

sam

e w

ymag

ania


Załącznik 2

cd. z

ałąc

znik

2

1 2

3 4

III.

A

naliz

a

i neg

ocjo

wan

ie

wym

agań

• zd

efin

iuj g

rani

ce sy

stem

u •

używ

aj li

sty

kont

roln

e do

ana

lizy

wym

agań

•

zaop

atrz

się

w o

prog

ram

owan

ie d

o w

spom

agan

ia

nego

cjac

ji •

zapl

anuj

pos

tępo

wan

ie w

prz

ypad

ku k

onfli

któw

i i

ch ro

zwią

zyw

anie

•

nada

j prio

ryte

ty w

ymag

anio

m

• kl

asyf

ikuj

wym

agan

ia

wyk

orzy

stując

wie

low

ymia

row

e po

dejś

cie

• uż

yj m

acie

rzy

inte

rakc

ji, a

by

wyk

ryć

konf

likty

i na

kład

ając

e się

wym

agan

ia

• pr

zypi

sz ry

zyko

do

wym

agań

IV.

Opi

s w

ymag

ań

• zd

efin

iuj s

tand

ardo

we

szab

lony

do

opis

u w

ymag

ań

• uż

ywaj

pro

steg

o i ś

cisł

ego

języ

ka

• ad

ekw

atni

e uż

ywaj

dia

gram

ów

• uz

upeł

nij o

pis w

języ

ku n

atur

alny

m in

nym

i sp

osob

ami o

pisu

• sp

ecyf

ikuj

wym

agan

ia il

ości

owo

−

V.

Mod

elow

anie

sy

stem

u

• ut

wór

z ko

mpl

emen

tarn

e m

odel

e sy

stem

u •

mod

eluj

oto

czen

ie sy

stem

u •

mod

eluj

arc

hite

kturę

syst

emu

• uż

ywaj

met

od st

rukt

ural

nych

do

mod

elow

ania

syst

emu

• uż

ywaj

słow

nika

dan

ych

• do

kum

entu

j pow

iąza

nia

pom

iędz

y in

tere

sariu

szam

i a m

odel

ami

syst

emu

−

VI.

W

alid

acja

w

ymag

ań

• sp

raw

dź z

godn

ość

doku

men

tu w

ymag

ań z

twoi

mi

stan

dard

ami

• zo

rgan

izuj

form

alne

insp

ekcj

e w

ymag

ań

• w

ykor

zyst

uj in

terd

yscy

plin

arne

zes

poły

do

prz

eglą

du w

ymag

ań

• zd

efin

iuj l

isty

kon

troln

e dl

a w

alid

acji

wym

agań

• uż

yj p

roto

typo

wan

ia, a

by

anim

ować

wym

agan

ia

• na

pisz

szki

c po

dręc

znik

a uż

ytko

wni

ka

• za

prop

onuj

prz

ypad

ki t

esto

we

dla

wym

agań

• st

osow

anie

not

acji

form

alny

ch

• pa

rafra

zuj m

odel

e sy

stem

u


cd

. załąc

znik

2

1 2

3 4

VII

. Za

rząd

zani

e

wym

agan

iam

i

• je

dnoz

nacz

nie

iden

tyfik

uj w

ymag

ania

•

zdef

iniu

j pol

itykę

zar

ządz

ania

wym

agan

iam

i •

zdef

iniu

j pol

itykę

śled

zeni

a •

utrz

ymuj

prz

ewod

nik śl

edze

nia

• uż

yj b

azy

dany

ch d

o za

rząd

zani

a w

ymag

ania

mi

• zd

efin

iuj z

arzą

dzan

ie z

mia

ną

• zi

dent

yfik

uj g

loba

lne

wym

agan

ia

syst

emow

e

• id

enty

fikuj

wym

agan

ia u

lotn

e •

prze

chow

uj o

drzu

cone

wym

agan

ia

VII

I. Inży

nier

ia

wym

agań

dl

a sy

stem

ów

kryt

yczn

ych

• ut

wór

z lis

tę k

ontro

lną

dla

wym

agań

be

zpie

czeń

stw

a •

zaan

gażu

j zew

nętrz

nych

rece

nzen

tów

w p

roce

sie

wal

idac

ji

• id

enty

fikuj

i an

aliz

uj z

agroże

nia

• z

anal

izy

zagr

ożeń

wyp

row

adź

wym

ogi b

ezpi

eczeńs

twa

• sp

raw

dź p

owtó

rnie

wym

agan

ia

oper

acyj

ne i

funk

cjon

alne

wob

ec

wym

agań

bez

piec

zeńs

twa

• sp

ecyf

ikuj

syst

em p

rzy

użyc

iu

met

od fo

rmal

nych

•

zbie

raj o

pisy

incy

dent

ów

• w

ycią

gaj w

nios

ki z

opi

sów

in

cyde

ntów

•

dbaj

o ro

zwój

kul

tury

be

zpie

czeń

stw

a w

org

aniz

acji

Źródło

: N

a po

dst.

[SoS

a97]

.


Załąc

znik

3 Pr

zypo

mni

enia

pryn

cypi

ów p

odejś

cia zo

rient

owan

ego

na uży

tkow

nika

I. Pr

ojek

t op

iera

się

na

dogłęb

nym

zro

zum

ieni

u uż

ytko

wni

ków

, za

dań

oraz

oto

czen

ia.

Pow

inni

zos

tać

zide

ntyf

ikow

ani

inte

resa

riusz

e zw

iąza

ni z

pro

jekt

em, u

wzg

lędn

iają

c ty

ch, n

a kt

óryc

h sy

stem

będ

zie

oddz

iały

wał

(be

zpoś

redn

io lu

b pośr

edni

o).

Cha

rakt

erys

tyki

uży

tkow

nikó

w, z

adań

ora

z ot

ocze

nia

są n

azyw

ane

kont

ekst

em w

ykor

zyst

ania

1 . Kon

teks

t w

ykor

zyst

ania

jes

t gł

ówny

m ź

ródł

em i

nfor

mac

ji dl

a us

tale

nia

wym

agań

, dos

tarc

za z

asad

nicz

y w

kład

w p

roce

sie

proj

ekto

wan

ia. W

kom

enta

rzac

h

do t

ego

pryn

cypi

um c

zęst

o w

skaz

uje

się

na t

rójkę

{uży

tkow

nik,

sys

tem

, ot

ocze

nie}

, kt

órą

trzeb

a ro

zpoz

nać

w t

rakc

ie p

rac

proj

ekto

wyc

h.

II. U

żytk

owni

cy b

iorą

udz

iał

w c

ałym

pro

cesie

pro

jekt

owan

ia i

roz

woj

u. Z

aang

ażow

anie

uży

tkow

nikó

w w

pro

jekt

owan

ie

pozw

ala

na p

ozys

kani

e w

artośc

iow

ej, ź

ródł

owej

wie

dzy

o ko

ntekśc

ie w

ykor

zyst

ania

, o z

adan

iach

, a ta

kże

jak

użyt

kow

nicy

mogą

prac

ować

w p

rzys

złoś

ci z

pro

dukt

em, s

yste

mem

lub

usłu

gą. P

owin

no o

no b

yć a

ktyw

ne n

ieza

leżn

ie c

zy uży

tkow

nik

ucze

stni

czy

w

pro

jekt

owan

iu,

czy

jest

źró

dłem

ist

otny

ch d

anyc

h lu

b cz

y oc

enia

roz

wią

zani

a. P

oprz

ez z

aang

ażow

anyc

h w

cał

ym p

roce

sie

proj

ekto

wan

ia i

roz

woj

u uż

ytko

wni

ków

org

aniz

acja

zam

awia

jąca

sys

tem

ma

moż

liwość

oddz

iały

wan

ia n

a ro

zwią

zani

e. T

akie

za

angażo

wan

ie o

raz

wsp

ółud

ział

moż

e m

ieć

wpł

yw n

a po

ziom

akc

epta

cji o

raz

późn

iejs

zego

wyk

orzy

stan

ia.

III.

Proj

ekt j

est p

row

adzo

ny i

udos

kona

lany

z w

ykor

zyst

anie

m o

cen

zori

ento

wan

ych

na uży

tkow

nika

. Oce

ny p

roje

któw

ora

z ic

h po

praw

iani

e na

pod

staw

ie o

trzym

aneg

o od

uży

tkow

nikó

w s

przęże

nia

zwro

tneg

o po

zwal

ają

min

imal

izow

ać r

yzyk

o, p

oleg

ając

e

na ty

m, ż

e w

ykon

any

syst

em n

ie będ

zie

zasp

akaj

ał p

otrz

eb uży

tkow

nika

lub

potrz

eb o

rgan

izac

ji (włą

czając

wym

agan

ia u

kryt

e lu

b tru

dne

do ja

wne

go w

yspe

cyfik

owan

ia).

Wstęp

ne r

ozw

iąza

nia

są w

eryf

ikow

ane

w r

amac

h zb

liżon

ych

do s

ytua

cji r

zecz

ywis

tych

sc

enar

iusz

y, w

ynik

i są

pods

tawą

prog

resy

wni

e po

praw

iany

ch r

ozw

iązań.

Zor

ient

owan

e na

uży

tkow

nika

oce

nian

ie p

owin

no b

yć

rów

nież

wyk

orzy

stan

e w

ram

ach

test

owan

ia,

końc

owej

oce

ny p

roje

ktu,

a t

akże

na

etap

ie e

kspl

oata

cji,

dają

c po

dsta

wę

dl

a pr

zyszły

ch p

roje

któw

. 1 A

ng. c

onte

xt o

f use

.


cd. z

ałąc

znik

3

IV. P

roce

s je

st i

tera

cyjn

y. B

ez i

tera

cji

nie

moż

na z

azw

ycza

j os

iągnąć

naj

bard

ziej

odp

owie

dnie

go p

roje

ktu

dla

syst

emu

inte

r-ak

tyw

nego

. Wie

le p

otrz

eb o

raz

ocze

kiw

ań u

uży

tkow

nikó

w o

raz

u in

nych

inte

resa

riusz

y, p

ojaw

ia s

ię je

dyni

e w

cza

sie

rozw

oju,

gd

y pr

ojek

tanc

i do

skon

alą

swoj

e zr

ozum

ieni

e uż

ytko

wni

ków

i

ich

zadań,

gd

y w

ob

liczu

po

tenc

jaln

ych

rozw

iązań

u

użyt

kow

nikó

w d

osko

nali

się

zdol

ność

wyr

ażan

ia p

otrz

eb.

W c

elu

min

imal

izac

ji ry

zyka

, że

roz

wija

ny s

yste

m n

ie s

pełn

i oc

zeki

wań

uży

tkow

nika

, gdy

now

e in

form

acje

są

otrz

ymyw

ane,

opi

sy, s

pecy

fikac

je i

prot

otyp

y są

zm

ieni

ane

oraz

pop

raw

iane

. Ta

k w

ięc

itera

cje

są w

ykor

zyst

ywan

e do

sto

pnio

wej

elim

inac

ji ni

epew

nośc

i ora

z ry

zyka

. W h

umor

ysty

czny

ch k

omen

tarz

ach

do

tego

pry

ncyp

ium

wsk

azuj

e się

, że

aby

dow

iedz

ieć

się

czeg

o uż

ytko

wni

k po

trzeb

uje

moż

na m

u na

poc

ząte

k dać

to c

zego

zap

ewne

ni

e po

trzeb

uje

(nas

z pi

erw

szy

proj

ekt)

oraz

obs

erw

ować

jego

reak

cję.

V

. Pro

jekt

odn

osi

się d

o całe

go d

ośw

iadc

zeni

a uż

ytko

wni

ka.

Kon

teks

t uż

ytec

znoś

ci r

ozpa

truje

my

szer

zej

niż

jedy

nie ła

twość

użyc

ia p

rodu

ktu.

Pat

rząc

z p

unkt

u w

idze

nia

osob

isty

ch c

elów

uży

tkow

nika

, m

oże

on o

bejm

ować

zar

ówno

per

cepc

yjne

ora

z em

ocjo

naln

e as

pekt

y za

zwyc

zaj p

ołąc

zone

z d

ośw

iadc

zeni

ami uży

tkow

nika

, jak

rów

nież

zag

adni

enia

, tak

ie ja

k sa

tysf

akcj

a z

prac

y or

az e

limin

owan

ie m

onot

onii.

Moc

ne s

trony

uży

tkow

nikó

w, i

ch o

gran

icze

nia,

pre

fere

ncje

i oc

zeki

wan

ia p

owin

ny b

yć b

rane

pod

uw

agę

podc

zas

określ

ania

, ja

kie

działa

nia

są p

rzep

row

adza

ne p

rzez

uży

tkow

nikó

w i

któ

re f

unkc

je są

real

izow

ane

prze

z te

chno

logię.

Teg

o pr

yncy

pium

w I

SO 1

3407

nie

był

o. D

ołąc

zono

je

zape

wne

, dla

pod

kreś

leni

a, k

onie

cznośc

i je

szcz

e ba

rdzi

ej

szcz

egół

oweg

o an

aliz

owan

ia k

onte

kstu

uży

tkow

nika

. V

I. Ze

spół

pro

jekt

owy

wyk

orzy

stuj

e um

ieję

tnoś

ci o

raz

spoj

rzen

ie i

nter

dysc

yplin

arne

. Zo

rient

owan

y na

uży

tkow

nika

zes

pół

proj

ekto

wy

nie

mus

i być

liczn

y, a

le p

owin

ien

być

wys

tarc

zają

co r

óżno

rodn

y, a

by w

wym

agan

ym c

zasi

e w

ypra

cow

ywać

ko

mpr

omis

owe

decy

zje

doty

cząc

e pr

ojek

tu o

raz

jego

wdr

ożen

ia. W

cza

sie

wsp

ółpr

acy

w z

espoła

ch, k

tóry

ch c

złon

kow

ie m

ają

rozl

egły

zes

taw

um

ieję

tnoś

ci w

yzw

ala

się

doda

tkow

a kr

eaty

wność

ora

z po

mysły

, kt

óre

są w

ykor

zyst

ywan

e w

pro

jekc

ie.

Dod

atko

wa

korz

yść

z in

terd

yscy

plin

arnośc

i ora

z ze

spo

jrzen

ia z

różn

ych

pers

pekt

yw2 p

oleg

a na

tym

, że

czło

nkow

ie z

espołu

sta

ją

się

bard

ziej

św

iado

mi o

gran

iczeń

oraz

real

iów

inny

ch d

yscy

plin

; dla

prz

ykła

du e

kspe

rci t

echn

iczn

i sta

ją s

ię b

ardz

iej w

yczu

leni

na

prob

lem

y uż

ytko

wni

ków

, zaś

uży

tkow

nicy

mogą

zysk

ać w

ięks

zą ś

wia

dom

ość

ogra

nicz

eń te

chni

czny

ch.

2 A

ng. M

ulti-

pers

pect

ive

appr

oach

.



ANALYSIS OF SOME CONCEPTS IN THE FIELD OF DESIGN REQUIREMENTS

Summary On the eve of the new millennium, the design requirements continue to make

significant difficulties to designers. This article aims to analyze three research trends: software engineering, user-oriented approach and agile approach. The paper is to iden-tify, describe, and to discuss mechanisms selected from among those trends.

ANALIZA WYBRANYCH KONCEPCJI W OBSZARZE … · jako standard lub do celów akredytacji, lecz jako...

Documents

Transcript of ANALIZA WYBRANYCH KONCEPCJI W OBSZARZE … · jako standard lub do celów akredytacji, lecz jako...