Metoda BP jako próba sformalizowania informatycznego projektu badawczego

Działalność o charakterze badawczym jest motorem postępu w każdej dziedzinie wiedzy, również w informatyce. Jednak tam, gdzie praca nad innowacyjnymi koncepcjami nie jest tylko podróżą w nieznane lecz musi służyć doraźnym celom projektu informatycznego, wyłania się potrzeba właściwego zarządzania takim procesem. W artykule zaprezentowano próbę sformalizowania naturalnego, zgodnego z intuicją podejścia do badań, opartą na adaptacji znanego z inżynierii oprogramowania modelu spiralnego cyklu życia projektu. Nowa metoda nosi nazwę BP, od pierwszych liter aktywności składających się na pojedynczy cykl: Badania–Prototypowanie.W kolejnych podrozdziałach przedstawiamy motywacje dla definiowania nowej metody prezentując cechy projektu badawczo-wytwórczego. Cechy te czynią taki projekt trudnym przedsięwzięciem, wymagającym spójnego i dobrze zdefiniowanego, ale zarazem elastycznego podejścia. Następnie opisujemy metodę BP, wywodząc ją z modelu spiralnego przez dodanie nowych, pomocnych narzędzi. Argumentujemy, iż projekty badawczo-wytwórcze dobrze nadają się do przeprowadzenia zgodnie z modelem BP.

Adekwatność metody została praktycznie potwierdzona w innowacyjnym projekcie . Prezentujemy zarówno przebieg tego projektu, najważniejsze rezultaty, a także te jego aspekty, w których metoda BP sprawdziła się w sposób szczególny.

Wiele ze współcześnie realizowanych projektów informatycznych wykracza swoją formułą poza klasyczne ramy procesu wytwórczego, obejmując swoim zakresem również zadania związane z badaniami. W środowisku przemysłowym na przykład zachodzi konieczność ciągłej adaptacji do nowych rozwiązań technicznych lub standardów. Wiedza o nich musi zostać pozyskana przed lub w trakcie wytwarzania nowych produktów informatycznych. Dzięki temu gotowe oprogramowanie może bez zarzutu funkcjonować w kontekście ustanowionym przez nieustannie zmieniające się platformy sprzętowo-programowe. Projekty naukowe prowadzone na uczelniach są natomiast z założenia nastawione na opracowywanie innowacyjnych rozwiązań, eksplorowanie nowej dziedziny wiedzy i wykorzystywanie nowych pomysłów są więc ich integralną częścią. Samo opracowanie innowacyjnej koncepcji w większości przypadków jednak nie wystarczy, konieczne jest wytworzenie konkretnych produktów. Mogą one przyjąć postać systemu komputerowego, dokumentacji projektowej, zapisu eksperymentów itp. Produkty te ilustrują nowoopracowaną koncepcję, uzasadniają jej adekwatność a także otwierają drogę ku szerszemu zastosowaniu nowych pomysłów w praktyce. Przedstawiony powyżej typ projektu nazwaliśmy projektem badawczo-wytwórczym.Projekt badawczo-wytwórczy można scharakteryzować następującymi cechami odróżniającymi go od pozostałych:

• większe nakłady na wstępne fazy projektu – Eksplorowanie nieznanych technologii i weryfikacja hipotez wymaga zdefiniowania w harmonogramie specjalnie przeznaczonych na to zadań. Czynności związane bezpośrednio z wytwarzaniem oprogramowania odwlekają się w czasie.

• nieznane z góry założenia i wymagania – Sytuacja wejściowa w projekcie często definiuje bardzo skromny zbiór początkowych wytycznych. Na przykład może zostać sformułowana jedynie wizja projektu. Ostateczny kształt systemu zależy od wyników przeprowadzanych w trakcie projektu badań i może zostać ustalony bardzo późno w projekcie.

• nieznana z góry lista produktów – Lista ostatecznych produktów jakie zostaną dostarczone zależy od rezultatów przeprowadzanych badań. Po pierwsze, niepowodzenie na jednej z obranych dróg badań może wykluczyć stworzenie jakiegoś produktu informatycznego, który zastąpiony zostanie raportem wyjaśniający przyczyny nie osiągnięcia celów. Po drugie, w wyniku badań mogą pojawić się nowe pomysły których realizacja pociągnie za sobą wytworzenie nieprzewidzianych początkowo produktów.

• trudności w szacowaniu nakładów – Tempo pracy zespołów badawczych bardzo trudno jest przewidzieć, gdyż najczęściej wyzwania jakich się podejmują są czymś nowym w organizacji i trudno jest znaleźć odpowiednią analogię. Co więcej, wskazana jest elastyczność w wydatkowaniu zasobów na badania. Natychmiastowe przerwanie zadania które przekroczyło planowany czas i uznanie porażki może nie być optymalnym rozwiązaniem w kontekście całego projektu.

• brak możliwości przewidzenia rezultatów – Z natury działań o charakterze badawczym wynika iż nie znany jest ich ostateczny rezultat. Mimo że uzasadnione niepowodzenie jest również wynikiem w sensie poznawczym, z perspektywy projektu takie nietrafione zadanie może oznaczać skonsumowane zasoby bez wyraźnego kroku w kierunku zrealizowania celów projektu.

Projektu badawczo-wytwórczego dotyczą naturalnie wszystkie typowe ograniczenia projektów informatycznych, w szczególności ograniczone zasoby (ludzkie, budżet) oraz haromonogram.

Cechy charakterystyczne oraz ograniczenia dotyczące projektu badawczo-wytwórczego wspólnie powodują, iż projekt ten jest przedsięwzięciem wysokiego ryzyka. Podstawowe zagrożenia w takim projekcie to niezrealizowanie celów projektu oraz wyczerpanie dostępnych zasobów lub przekroczenie harmonogramu. Opis własności projektu badawczo-wytwórczego przedstawiony wyżej wskazuje na występowanie różnego rodzaju niepewności, które są głównymi czynnikami ryzyka w takim projekcie [GOR2000]. Niepewności te dotyczą zarówno kwestii technicznych, jak i związanych z zarządzaniem. Z jednej bowiem strony zespół podejmuje się zadań, które ostatecznie mogą nie przynieść spodziewanych efektów, z drugiej zaś, nawet przy pomyślnym przebiegu prac, planowanie zadań jest mocno utrudnione. Nieustabilizowana lista produktów, zmienne założenia i wymagania oraz trudności z szacowaniem mogą łatwo spowodować podjęcie niewłaściwej decyzji menedżerskiej i błędne pokierowanie projektem. W szczególności niebezpieczeństwo na szczeblu zarządzania może zrodzić się w wyniku wczesnego definiowania planów projektu, mimo istniejących niepewności, a następnie ścisłego trzymania się ich bez uwzględnienia zmian w faktycznej sytuacji.Z powyższych rozważań wynika, iż inspiracji dla strategii prowadzenia projektów badawczo-wytwórczych należy szukać wśród modeli inżynierii oprogramowania jawnie adresujących kwestie ryzyka, tolerujących zmianę i niepewność oraz umożliwiających elastyczne zarządzanie.

Spośród klasycznych modeli cyklu życia projektu informatycznego, model spiralny traktuje kwestie związane z ryzykiem szczególnie poważnie [SZEJ2002]. Projekt dzielony jest na szereg kroków, a krótkoterminowe planowanie w każdym z nich podporządkowane jest analizie dostępnych alternatyw i zarządzaniu ryzykiem. Co więcej wg tego modelu prace rozpoczynane są zwykle przy niesprecyzowanych wymaganiach, a doce-lowy system powiększa się w każdym nowym cyklu wg na bieżąco pozyskiwanej wiedzy [SZEJ2002]. Ponadto kierownictwo projektu może na bieżąco podejmować decyzje co do najlepszych posunięć, kompetentnie identyfikując potrzebne zmiany w sposobie prowadzenia projektu i skutecznie je przeprowadzając [GOR2000]. Własności te sprawiają iż model spiralny dobrze nadaje się jako podstawa metody prowadzenia projektów badawczo-wytwórczych.W istocie nasza metoda jest uszczegółowieniem modelu spiralnego, dostosowując go do specyficznych warunków panujących w projekcie badawczo-wytwórczym. W trakcie definiowania metody musieliśmy zwrócić uwagę na następujące aspekty modelu cyklu życia, tak aby uwzględnić nowe potrzeby:

• definicje aktywności – Oryginalny model spiralny został sformułowany z myślą o standardowym procesie wytwórczym. Dla projektów o charakterze badawczym należało zdefiniować przebieg cyklu tak, aby obejmował on zadania nie tylko o charakterze wytwórczym, ale i badawczym lub eksperymentalnym.

• punkty kontrolne – W trakcie projektu badawczo-wytwórczego krytyczne jest kompetentne podejmowanie decyzji związanych z kierowaniem pracami. Na bazie aktualnej wiedzy należy wyznaczać kierunki dalszych badań, przerywać te zadania które nie przynoszą rezultatów oraz w pewnym momencie zdecydować się na zakończenie badań i przystąpienie do wytwarzania systemu. Model cyklu życia projektu badawczo-wytwórczego musiał dawać kierownictwu częste okazje do wykonania analiz sytuacji i podjęcie decyzji.

• zarządzanie zakresem systemu – W trakcie projektu badawczo-wytwórczego proponowane są oryginalne rozwiązania i eksplorowane są nowe możliwości. Zachodzi więc potrzeba zarządzania zdobytą wiedzą i kontrolowanie wpływu jaki wywrze ona na ostateczny kształt systemu. Nie każda bowiem nowa koncepcja musi stać się elementem wytworzonego systemu.

• zapewnienie jakości – Projekt badawczo-wytwórczy daje w wyniku produkty różnych rodzajów, niekoniecznie będące reprezentacją systemu na pewnym poziomie abstrakcji (tak jak np. specyfikacja wymagań, projekt czy kod źródłowy). Mimo to istotne jest takie sformułowanie metody prowadzenia projektu aby dawała ona zespołowi narzędzia do kontroli jakości wytwarzanych produktów. Słaba jakość produktów wynikowych etapów związanych z badaniami może zagrozić jakości końcowego systemu.

Tradycyjny cykl spirali zastąpiliśmy dwiema iteracyjnie powtarzanymi fazami badań i prototypowania, stąd też pochodzi nazwa metody – BP (Badania-Prototypowanie). Pomiędzy fazami występują punkty kontrolne. W punktach kontrolnych zespół dokonuje podsumowania poprzedniej fazy a także wyznacza kierunki dalszych badań.Rezultatem każdego z obiegu spirali nie jest gotowy system informatyczny a pogłębiona wiedza o dziedzinie, wymaganiach, udziałowcach a także pewne produkty informatyczne – projekty podsystemów, algorytmy – oraz pomysły na wykorzystanie i rozszerzenie systemu. Rozkręcająca się spirala obrazuje tutaj rosnący poziom wiedzy a także powiększa zbiór zatwierdzonych do dalszego użycia produktów.

Aktywności w ramach projektu to:

• ocena sytuacji – dokonywana na początku każdej iteracji. Na jej podstawie musi zostać dokonana:

• ocena posiadanych produktów informatycznych,

• ocena obecnego stanu wiedzy o dziedzinie,

• identyfikacja w pełni rozpoznanych obszarów wiedzy o dziedzinie,

• identyfikacja nie w pełni rozpoznanych obszarów wiedzy o dziedzinie

• wyznaczenie najpilniejszych kierunków badań,

• plan badań, zawierający:

• termin ich zakończenia,

• przydział zadań w podziale na grupy badawcze.

• badania – faza badań to indywidualne zgłębianie wyznaczonych problemów przez wyodrębnione grupy badawcze. Każda grupa badawcza zobowiązana jest dostarczyć raport opisujący przebieg i rezultaty badań. Należy podkreślić, że badania mogą przyjąć różną postać i w miarę trwania projektu mogą zmieniać swój charakter. Na początku są to zazwyczaj działania poznawcze, eksplorujące pewną dziedzinę wiedzy, później, w zależności od specyfiki projektu, mogą przyjąć postać eksperymentów na prototypach lub przeprowadzanych z klientem sesji oceniających powstałe produkty. Bez względu na ich charakter, czas badań jest ściśle ograniczony.

• analiza wyników badań – rezultaty tej fazy to:

• ocena wzbogaconego stanu wiedzy o dziedzinie,

• identyfikacja nie branych dotąd pod uwagę obszarów wiedzy o dziedzinie,

• identyfikacja części systemu, która nie powinna ulec zmianie w toku dalszych prac,

• identyfikacja części wymagającej eksperymentu,

• plan fazy prototypowania.

• prototypowanie – faza, w trakcie której powstaje prototypowa część systemu. Nie musi to być prototyp zawierający kod, w ramach fazy prototypowania może powstać np. wstępny projekt pewnego algorytmu, podsystemu, architektury a nawet część specyfikacji wymagań. Głównym celem tej fazy jest wzbogacenie wiedzy uczestników projektu o jej praktyczne aspekty, a także weryfikacja dokonanych wcześniej ocen co do kompletności zgromadzonej wiedzy. Właściwie zaplanowana faza prototypowania powinna zakończyć się wytworzeniem dobrze udokumentowanego produkty informatycznego, który będzie mógł zostać użyty w dalszych pracach nad systemem. Czas trwania tej fazy jest w dużej mierze zależny od rodzaju wytwarzanego produktu. W szczególności może być ograniczony do kilku godzin, na przykład gdy produktem jest pewna koncepcja dyskutowana na forum projektu.

Zalecanym sposobem realizacji punktów kontrolnych są różne formy pracy zespołowej takie jak burze mózgów, dyskusje sprawozdań, inspekcje, prezentacje. Taki sposób ich przeprowadzenia dobrze wpływa na komunikację w ramach uczestników projektu i stopień zrozumienia jego celów, jest też źródłem nowych pomysłów.

Wszystkie pomysły pojawiające się w toku projektu, dotyczące dalszych kierunków prac oraz sposobów wykorzystania i popularyzacji projektu, nowych algorytmów czy podsystemów muszą być starannie dokumentowane, a także poddane ocenie i odpowiednio sklasyfikowane. Ponieważ wszystkie te działania są usystematyzowane i muszą być zaplanowane możemy mówić o zarządzaniu pomysłami.

Proces oceny pomysłu musi zawierać:

• ocenę zgodności z rozpoznanymi obszarami wiedzy dziedzinowej oraz z zatwierdzonymi produktami,

• ocenę wpływu na nierozpoznane dotąd obszary wiedzy dziedzinowej oraz odrzucone lub niezatwierdzone dotąd produkty,

• ocenę wpływu na identyfikację nowych obszarów wiedzy dziedzinowej i ewentualnych nowych produktów.

W zależności od oceny pomysł jest klasyfikowany jako przeznaczony do realizacji, odłożony do następnej wersji systemu lub odrzucony. Niezależnie od tego, jak został sklasyfikowany musi zostać dobrze udokumentowany, a dokumentacja musi zawierać jego ocenę i uzasadnienie takiej a nie innej klasyfikacji.

Równie dużej uwagi wymagają następujące elementy infrastruktury dokumentacyjnej:

• katalog wiedzy dziedzinowej: wyróżnione obszary, wyniki prac badawczych, wnioski z prac badawczych

• katalog zaakceptowanych i niezaakceptowanych produktów informatycznych: pełna dokumentacja produktów, wykaz stwierdzonych uchybień.

Metoda BP nie narzuca sposobu dokumentowania wyżej wymienionych aspektów projektu. Do dokumentowania niektórych z nich można w naturalny sposób użyć standardowych dokumentów projektowych, np. potencjalne zastosowania systemu umieszczać w postaci punktów widzenia w specyfikacji wymagań względem systemu. Jednak sposób dokumentowania powinien być ściśle ustalony na początku projektu. Niedopełnienie tego warunku może skutkować niepowodzeniem przedsięwzięcia.

Metoda BP, poprzez swoją specyfikę, kładzie bardzo duży nacisk na zarządzanie ryzykiem, jakością oraz czasem trwania projektu, a także na zarządzanie wymaganiami. Cały cykl można potraktować jako narzędzie zarządzania ryzykiem. Jest on podporządkowany zagadnieniu wzbogacania wiedzy zespołu na temat słabo rozpoznanej dziedziny. Gęste rozmieszczenie punktów kontrolnych sprawia, że krytyczne dla projektu decyzje, np. o przejściu do etapu projektowania systemu, a także ewentualne zmiany harmonogramu, mogą być podejmowane przez kierownictwo w najwłaściwszym momencie, bez zaburzania toku prac. Jednocześnie decyzje te są podejmowane w oparciu o obszerną dokumentację w jasny sposób prezentującą stan posiadanej wiedzy (z uwzględnieniem braków) i wytworzone produkty (z uwzględnieniem ich wad). Zarządzanie pomysłami wspomaga pracę zespołu, umożliwiając efektywne sterowanie zakresem projektu oraz dostarczając dobrych podstaw do świadomej analizy wymagań, identyfikacji udziałowców oraz potrzebnych produktów, czyli tych aspektów, które zostały uznane za szczególnie trudne w pracy badawczej i popularyzacyjnej.Metoda BP wspiera wykonywanie wielu zadań projakościowych, głównie w dziedzinie komunikacji wewnątrz projektu, oraz inżynierii wymagań. Punkty kontrolne są dobrą okazją do inspekcji wytworzonych produktów. W ramach punktów kontrolnych istnieje też możliwość wymiany wiedzy i doświadczeń pomiędzy członkami zespołu. Ponadto przez cały czas identyfikowane i katalogowane są informacje o udziałowcach, ich punktach widzenia oraz przyszłych ścieżkach rozwoju projektu.

Zastosowanie metody BP jest kosztowne. Główne nakłady związane są z komunikacją oraz dokumentowaniem. W celu minimalizacji tych negatywnych efektów konieczne jest odpowiednie planowanie krótkoterminowe, szczególnie w początkowym etapie prac, a także ustanowienie odpowiedniej infrastruktury projektu. Należy też unikać niepotrzebnego przedłużania aktywności związanych z punktami kontrolnymi, gdyż wiąże się z tym ryzyko długiego pozostawania projektu w stanie nieustalonym, czego skutkiem jest złe wykorzystanie zasobów (efekt „ugrzęźnięcia w dyskusjach”). Odpowiednie zaplanowanie, a także konsekwentna i sprawna realizacja punktów kontrolnych to klucz do sukcesu w wykorzystaniu metody.

Proponowana przez nas metoda BP prowadzenia przedsięwzięć badawczo-wytwórczych rozwijana była równolegle z przebiegiem projektu . Projekt realizowany był w terminie od listopada 2002 r. do kwietnia 2003 r. w ramach międzynarodowego konkursu informatycznego CSIDC [CSIDC]. Zespół projektowy składał się z czwórki studentów informatyki specjalizujących się w obszarze inżynierii oprogramowania. Uczestnicy konkursu mieli za zadanie wytworzyć system informatyczny charakteryzujący się dużą innowacyjnością i jednocześnie adresujący pewną społeczną potrzebę. Takie były również cele projektu . Potrzebą adresowaną przez system miało być zapewnienie ludziom narzędzi do łatwego i wydajnego zarządzania informacją w oparciu o Internet jako rozproszone repozytorium wiedzy, dzięki kreatywnemu wykorzystaniu koncepcji znacznikowania dokumentów elektronicznych. Taka była wyjściowa idea systemu , którego nazwa jest skrótem od angielskiej frazy Knowledge Tags czyli Znaczniki Wiedzy. Idea ta zakłada, że każda osoba czytająca dokument będzie mogła oznaczyć jego fragment i określić czego ten fragment dotyczy. Różne fragmenty będą mogły się dowolnie nakładać, z czego pośrednio będą wynikały relacje między znacznikami. Wzrost liczby oznacznikowanych dokumentów spowoduje utworzenie bogatego schematu wiedzy, który będzie automatycznie aktualizowany wraz z każdym znacznikowaniem. Taki schemat wiedzy otworzy nowe możliwości w dziedzinie analizy informacji zawartej w elektronicznych dokumentach. Tym samym umożliwi łatwy dostęp do bogatego zbioru informacji oferowanego przez Internet.Idea wymagała od twórców:

• zbadania jej przydatności – Wyjściowa idea miała charakter hipotezy, postulującej przydatność nowego pomysłu w dziedzinie zarządzania wiedzą. Przed przystąpieniem do właściwego tworzenia systemu informatycznego, hipoteza ta musiała zostać zweryfikowana.

• odnalezienia podobnych technologii i porównania ich z ideą – Innowacyjność była warunkiem koniecznym zaakceptowania rozwiązania. Z drugiej strony, rynek oferuje wiele technologii związanych z semantyczną analizą dokumentów. Konieczne było sprawdzenie czy idea istotnie oferuje nową jakość. Jednocześnie należało zbadać potencjalne możliwości wykorzystania już istniejących rozwiązania technicznych jako elementów systemu .

• opracowania sposobu popularyzacji idei – Docelowa grupa odbiorców systemu nie była znana a priori. Wprawdzie efektywny dostęp do informacji jest potrzebny właściwie każdemu, jednak różni odbiorcy reprezentują odmienne, czasem sprzeczne, punkty widzenia. W przypadku projektu aspekt popularyzacyjny był bardzo ważny, gdyż cele systemu są długoterminowe i mogą zostać osiągnięte jedynie w przypadku powszechnego użycia systemu. Istotnym jest zauważenie, że rozpoznanie powszechnej akceptacji jako celu systemu nastąpiło już podczas projektu, w trakcie identyfikacji udziałowców systemu oraz ich wymagań.

• identyfikacji i wytworzenia koniecznych produktów – Początkowa lista wymaganych produktów projektu zawierała system informatyczny (w niesprecyzowanej postaci) oraz raport z przebiegu prac. Idea już na wstępie sugerowała znaczny udział w projekcie zadań o charakterze badawczym, o z góry nie znanych produktach.

Powyższe cechy niewątpliwie pozwalają zaliczyć projekt w poczet projektów badawczo-wytwórczych. Ponadto doszły jeszcze specyficzne ograniczenia związane z niepewnością w obszarze udziałowców systemu oraz wynikające z edukacyjnego charakteru projektu. Do tych ostatnich zaliczyć można między innymi brak możliwości rozszerzenia zespołu projektowego oraz praktycznie zerowy budżet.

W trakcie całego procesu przeszliśmy aż przez osiem iteracji zgodnych z modelem BP. Poniżej przedstawiono przebieg projektu zarysowując najważniejsze z osiągniętych rezultatów i zaznaczając wzajemny wpływ jaki miały na siebie projekt i metoda.

Pierwszy obrót spirali BP polegał na ustanowieniu wizji projektu, czyli sformułowaniu jego celów i podstawowych wymagań. Jako że w ostatnich latach pojawiło się kilka propozycji standardów znacznikowania dokumentów takich jak RDF czy Semantic Web, zdecydowaliśmy się zbadać czy założenia są istotnie innowacyjne. Poszukiwaliśmy również pomysłów i rozwiązań które moglibyśmy potencjalnie zaadaptować dobez szkody dla jej innowacyjnego charakteru, w szczególności szukając inspiracji w algebrach regionów i koncepcji danych semi-strukturalnych. Powyższe czynności wykonaliśmy w ramach pierwszej w projekcie fazy badań. Polegała ona na studiowaniu dokumentacji technicznej i na jej podstawie rozpoznaniu potencjału każdej z wymienionych technologii, jak i jej wpływu na projekt . W rezultacie utwierdziliśmy się w przekonaniu o oryginalności naszego pomysłu, identyfikując przy okazji kilka potencjalnie przydatnych w projekcie rozwiązań technicznych, katalogując je do późniejszego zbadania, np. użycie algorytmów przetwarzania języka naturalnego do interpretacji zapytań użytkowników. Dla porównania, odrzuciliśmy całkowicie znany z koncepcjiSemantic Web pomysł globalnej ontologii, czyli swoistego schematu wiedzy z którego użytkownicy mogą czerpać pojęcia w trakcie znacznikowania. Rozwiązanie oparte na ontologii nie byłoby skalowalne do rozmiaru globalnego schematu wiedzy.W toku dyskusji nad pomysłem sformułowaliśmy krótkoterminowe cele projektu, jakimi były opracowanie podstaw teoretycznych, standardu znacznikowania, oraz narzędzi informatycznych służących do wprowadzania danych o znacznikowaniu oraz przetwarzania tych danych w celu efektywnego wyszukiwania informacji w sieci. Celami długoterminowymi miały być wykorzystanie zgromadzonej w systemie wiedzy w celach badawczych, np. w celu rozpoznania potencjału w automatycznym tłumaczeniu dokumentów. Tym samym zakończony został pierwszy etap pracy, który postrzegać można również jako doprecyzowanie tematu projektu. Metoda BP pozwoliła nam podejść do niego w sposób konstruktywny, nie traktując go jak stan, w którym prace stanęły w miejscu w oczekiwaniu na wytyczenie kursu projektu, lecz jak etap intensywnego i aktywnego pozyskiwania wiedzy. Ponadto już w trakcie przeprowadzania wstępnych badań zidentyfikowaliśmy potrzebę zarządzania nabytą wiedzą, tak by móc efektywnie korzystać z niej w przyszłości jako źródła pomysłów. Znalazło to wyraz w ostatecznym sformułowaniu metody BP.

Otrzymaną wizję systemu , co do którego mieliśmy pewność, że będzie zarówno innowacyjny jak i potencjalnie społecznie użyteczny, spisaliśmy w postaci odpowiedniego dokumentu w ramach fazy prototypowania. Ocena sytuacji przeprowadzona na zakończenie pierwszego cyklu BP ujawniła potrzebę sformułowania wizji architektury systemu, co stało się celem drugiej iteracji. Faza badań w tym cyklu miała wzbogacić nas o wiedzę potrzebną do zidentyfikowania podstawowych rozwiązań technicznych potrzebnych do zrealizowania systemu opisanego w dokumencie wizji. Pomysłów na architekturę dla systemu było kilka, dlatego aby mieć możliwość dokonania wyboru bazującego na faktach nie zaś domniemaniach, stworzyliśmy dokument specyfikacji wymagań. W tym celu należało zidentyfikować udziałowców systemu, jak i reprezentowane przez nich punkty widzenia. Specyfika projektu wymagała od nas samodzielnego zdefiniowania grupy odbiorców systemu i takiego sformułowania wymagań, aby gotowe rozwiązanie mogło być konkurencyjne wobec już istniejących. Wykorzystaliśmy burzę mózgów jako narzędzie stymulujące aktywność w zespole katalogując pomysły w dokumencie specyfikacji wymagań, który został specjalnie w tym celu rozszerzony, tak że zawierał obok samych wymagań opis potencjalnych konsekwencji dla przyszłego kształtu rozwiązania. Co więcej, tylko część wymagań potraktowana została jako wiążąca, reszta miała status pomysłów poddanych pod dalsze badania. Kandydujące pomysły były ocenianie względem postawionych wymagań, jasnym stało się że realizacja wszystkich zamiarów jest niemożliwa z braku zasobów. Dlatego niezbędna okazała się priorytetyzacja wymagań oraz przedyskutowanie na forum zespołu wszystkich wad i zalet proponowanych rozwiązań, tak aby uzyskany kompromis między badawczymi zamiarami a inżynierskimi ograniczeniami był przez każdego członka zespołu dobrze rozumiany i akceptowany. Doskonale służył temu celowi punkt kontrolny cyklu BP polegający na ocenie sytuacji, jako że z założenia nastawiony jest on na intensywną komunikację wewnątrz zespołu. Jako wynikowe prototypy cyklu spisano wymagania wraz z wnioskami z dyskusji oraz sformułowano opis wizji kandydującej architektury dla systemu . Szereg pomysłów i wniosków zostało zaakceptowanych i przeszło do dalszej fazy jako decyzje projektowe, w tym oparcie systemu o rozproszoną infrastrukturę serwerów przechowujących informację o znacznikach.

Inne koncepcje pozostawiono do dalszego zbadania, w tym kluczową decyzję, czy system ma przechowywać tylko informacje o znacznikowaniu czy może także same dokumenty. Intrygujące okazały się również propozycje ustanowienia serwerów tematycznych, przechowujących dane o pewnej klasie dokumentów oraz stworzenia niezależnych hierarchii serwerów dla różnych organizacji obok jednej publicznie dostępnej. Koncepcję stworzenia oprogramowania służącego do znacznikowania jako dodatku do wybranego popularnego edytora, np. do MS Worda również odłożyliśmy do zbadania nie wiedząc czy jest ona możliwa do zrealizowania w rozsądnym czasie.

Aby móc przystąpić do dalszych prac projektowych musieliśmy w pierwszej kolejności ukończyć opracowanie standardu znacznikowania i algorytmu wydobywania wiedzy ze znaczników. Aby ukończyć to zadanie niezbędne okazały się aż dwa obroty spirali BP. Pierwszy z nich pozwolił na sformułowanie propozycji modelu znacznikowania polegającego na używaniu prostych znaczników, bez atrybutów, nazwanych w języku naturalnym dowolnie wybraną przez użytkownika frazą. Alternatywny pomysł z wprowadzeniem klas znaczników z ustaloną listą atrybutów (np.: znacznik osoba mógłby posiadać atrybuty imię i nazwisko) został odrzucony. Po pierwsze wymagałby on od użytkownika wiedzy o dostępnych klasach znaczników, po drugie niebezpiecznie zbliżałby do idei globalnej ontologii. Potencjalne zalety tego podejścia, takie jak posiadanie większej ilości informacji pomocnej maszynie w przetwarzaniu tekstu, były niewystarczające. Rozważania te pozwoliły w fazie prototypowania zbudować pierwsze eksperymentalne narzędzie do znacznikowania dokumentów tekstowych. Następny obrót spirali polegał głównie na wykorzystaniu stworzonego prototypu do przygotowania zestawu przykładowych oznacznikowanych dokumentów i wykonaniu na nim eksperymentów z różnymi podejściami do wydobywania informacji z dostępnych znaczników. Wyniki okazały się bardzo obiecujące. Od strony metodologicznej wskazać można pozytywny skutek precyzyjnego planowania i przeprowadzenia eksperymentów – poczynając od opracowania pomocniczego narzędzia, przez zebranie przykładowych danych aż po ich analizę. W ten sposób uzyskano oczekiwany efekt w przewidzianym i kontrolowanym czasie.

Kolejnym etapem naszej pracy było zaprojektowanie architektury systemu. Etap ten wymagał trzech obrotów spirali BP:

• opracowanie struktury i dynamiki systemu

• analiza i wybór technologii

• opracowanie warstwy pośredniej (SDK)

W pierwszym cyklu skupiliśmy się na stworzeniu, w oparciu o wcześniej sformułowaną wizję architektury, szczegółowego projektu architektury odpowiedniej dla naszego systemu. Faza badań polegała na przygotowaniu projektów kilku niezależnych rozwiązań, biorąc pod uwagę głównie dynamikę systemu i ich porównaniu pod kątem wad i zalet. Chcieliśmy ostatecznie opracować takie rozwiązanie, które z jednej strony pozwoliłoby na wykorzystanie istniejących w Internecie struktur serwerów, a z drugiej strony byłoby wystarczająco wydajne, aby obsługiwać wielu użytkowników w tym samym czasie.

Efektem naszych prac było opracowanie obiektowych diagramów kolaboracji obrazujących komunikację między klientami i serwerami oraz opisujących wymieniane między nimi informacje. Opracowaliśmy także diagram ze strukturą serwera opisujący budowę i działanie pojedynczego serwera . Dodatkowym wynikiem naszych rozważań był szczegółowy projekt algorytmu wydobywania wiedzy. Został on uszczegółowiony dopiero w tym momencie, ponieważ wcześniej nie była znana architektura sieci ani serwerów. Te produkty złożyły się na prototypowy projekt rozwiązania , na razie oderwany od konkretnej technologii wytwarzania.

W trakcie pracy pojawiło się wiele nowych pomysłów, część nich została zaakceptowana. W szczególności podjęliśmy decyzję o zbudowaniu infrastruktury w oparciu o tzw. serwery autorytatywne wobec danej klasy dokumentów, identyfikowanej po nazwie URL. Serwery przekazywałyby sobie zapytania i żądania uaktualnienia danych dotyczące różnych dokumentów, tak aby tylko serwer autorytatywny wykonywał zadania wobec dokumentów którymi zarządza. Każdy serwer miałby wewnętrzną tablicę routingu, na podstawie której kierowałby ruch do odpowiednich serwerów. Jest to analogia do znanej internetowej usługi DNS. Pozostając w zgodzie z obecną strukturą Internetu, właściwe dokumenty byłyby fizycznie umiejscowione na serwerach sieci WWW. Każdy posiadałby unikatowy URL, niezbędny do określenia autorytatywnego dla dokumentu serwera. Infrastruktura przechowywałaby tylko dane o znacznikach.

Niektóre z innych ciekawych pomysłów postanowiliśmy zbadać w kolejnych etapach pracy. Należała do nich koncepcja stworzenia wtyczki do Internet Explorera jako demonstracyjnego oprogramowania klienta – była to ewolucja wspomnianego już pomysłu wykorzystania technologii MS Word. Postanowiliśmy również zbadać możliwości wykorzystania w projekcie powszechnie stosowanych technologii obiektowych takich jak Java, CORBA, RMI, DCOM.

Z powodu ograniczonych zasobów i trudności technicznych musieliśmy niektóre pomysły odrzucić, takie jak stworzenie hierarchii serwerów tematycznych (zastąpiliśmy je wspomnianą już koncepcją serwerów autorytatywnych). Rozwiązanie to pozwoliło uniknąć wielu kłopotów m.in. z automatycznym określeniem tematyki dokumentu.

Gdy zakończyliśmy cykl BP dedykowany opracowywaniu struktury systemu, przeszliśmy do oceny istniejących technologii, które mogłyby pomóc nam w realizacji systemu. Służyć temu miała kolejna iteracja BP, prawie w całości składająca się z prototypowania. Postanowiliśmy wykonać prototypy dla różnych technologii, celem zbadania, czy i w jaki sposób można daną technologię wykorzystać. Udało nam się zaimplementować działający prototyp wtyczki do Internet Explorera oraz prototypowy zestaw klient – serwer korzystający z technologii CORBA.

Bardzo ważnym z punktu widzenia dalszego przebiegu projektu okazał się punkt kontrolny oceniający przygotowane prototypy, gdyż w jego wyniku zapadły decyzje o użytych do wytworzenia systemu środkach technicznych. Dzięki przeprowadzonym eksperymentom zdecydowaliśmy się ostatecznie na wykorzystanie języków Java i C++ oraz technologii CORBA do komunikacji między klientem i serwerem, oraz między serwerami. Dodatkowo zachęceni udanym prototypem wtyczki zaakceptowaliśmy pomysł stworzenia pełnej wersji wtyczki do Internet Explorera.

Prace przy prototypie obsługującym technologię CORBA doprowadziły do dodatkowego pomysłu – stworzenia klas pomocniczych, które umożliwiałyby łatwą obsługę tej technologii – pierwotna wersja była dosyć skomplikowana implementacyjnie, przez co łatwo było popełnić w niej błędy. Pomysł ten doprowadził później do pojawienia się opisanej dalej koncepcji Software Development Kit (SDK).

Trzecim i ostatnim cyklem BP w ramach etapu projektowania architektury było zaprojektowanie warstwy pośredniej – SDK. Sam pomysł utworzenia dodatkowej warstwy pośredniej pojawił się podczas eksperymentów z technologią CORBA, a dokładniej z trudnościami implementacyjnymi niektórych bardziej skomplikowanych fragmentów. Doszliśmy do wniosku, że mimo iż stworzenie SDK będzie wymagało dodatkowych (i to niemałych) nakładów pracy, to jednak w późniejszych etapach pozwoli nam to szybko i bez większych problemów implementować dodatkową funkcjonalność systemu. W ramach tego cyklu zaprojektowaliśmy SDK, czego efektem był diagram UML opisujący opracowaną architekturę. Interesującą cechą SDK jest oparcie go o tzw.Services – rozszerzalny i modyfikowalny zestaw usług dostępnych zarówno po stronie klienta jak i serwera, umożliwiający nie tylko łatwą obsługę komunikacji, ale również tworzenie własnych wersji serwerów lub klientów.

Pozytywne zakończenie etapu projektowania architektury systemu doprowadziło nas do ostatniego cyklu BP projektu – wytworzenia zestawu prototypowych narzędzi składających się na pierwsze wydanie systemu. W ramach tej iteracji, a konkretnie fazy prototypowania w ramach tej iteracji, przygotowaliśmy implementacje następujących komponentów systemu:KaTie SDK – bardzo elastyczna warstwa pośrednia udostępniająca nie tylko usługi związane z komunikacją, ale także usługi publikowania, modyfikacji i wyszukiwania informacji przechowywanych w systemie .

Serwer – obsługujący zapytania od klientów i pozwalający na gromadzenie przesyłanych danych (rozbudowywanie bazy wiedzy)

Dodatkowy moduł do Internet Explorera – wtyczka rozszerzająca możliwości przeglądarki o usługi – znacznikowanie dokumentów HTML, publikowanie i wyszukiwanie informacji w sieci.

Wykorzystanie metody BP pomogło nam przeprowadzić z powodzeniem projekt, który stanowił wyzwanie zarówno intelektualne jak i inżynierskie. Pomocne okazały się przede wszystkim dwa z dostarczonych przez metodę narzędzi. Po pierwsze, dzięki krótkim iteracjom i gęsto umieszczonym na osi czasu punktom kontrolnym mogliśmy na bieżąco dokonywać podsumowania dotychczasowych wyników i systematycznie atakować kolejne napotykane problemy. W ten sposób zachowaliśmy kontrolę nad konstruowanym systemem, który niejednokrotnie okazał się być trudny do całościowego objęcia. Po drugie decyzje podejmowane w trakcie realizacji projektu dotyczące kolejnych posunięć dokonywane były z uwzględnieniem aktualnego stanu projektu jak i pozostałych do dyspozycji zasobów. Pozwoliło to nam skutecznie opierać się pokusie zbudowania rozwiązania „idealnego” i umożliwiło kontrolowanie zakresu systemu, w rezultacie oddalając ryzyko wyczerpania zasobów i nie zrealizowania celów projektu.

W trakcie projektu dużą rolę odegrała komunikacja wewnątrz zespołu. Niemal każdy z wielu punktów kontrolnych związany był z jakąś formą pracy grupowej. Sprawna komunikacja była konieczna dla ich sprawnego przeprowadzenia i podjęcia właściwych decyzji. W projekcie komunikacja była w istocie efektywna, na co pozytywny wpływ mógł mieć niewielki rozmiar zespołu – cztery osoby. Pojawia się więc hipoteza, czy metoda BP może dać najlepsze wyniki dla projektów małych i średnich, dla których rozmiar zespołu i nieskomplikowana hierarchia zarządzania nie zakłóca komunikacji. Nie oznacza to, iż projekt dużych rozmiarów nie może skorzystać z metody BP, jednakże pod warunkiem odpowiedniej dekompozycji na podprojekty i zespoły robocze. Problem ten stanowi interesujące wyzwanie i może być tematem dalszych badań.

Rozdział przedstawia wywodzącą się z modelu spiralnego metodę BP prowadzenia projektów informatycznych łączących zadania o charakterze badawczym z czynnościami typowo wytwórczymi. Metoda została przedstawiona zarówno od strony motywacji i dziedziny zastosowań, jak i procesu przez nią definiowanego. Praktycznym potwierdzeniem skuteczności metody było pomyślne jej wykorzystanie w projekcie , którego celem było wytworzenie istotnie użytecznego systemu realizującego innowacyjną koncepcję zarządzania elektronicznymi dokumentami. Sprawne przeprowadzenie badań i eksperymentów w celu rozwinięcia nowej idei naukowej, a następnie płynne przejście do zakończonego powodzeniem etapu wytwarzania systemu wskazuje na przydatność metody w danej klasie projektów. Oczywiście wymagana jest dalsza praca nad metodą. Szczególnie cenne byłoby dobranie miar pozwalających obiektywnie porównać ją z innymi podejściami do wytwarzania oprogramowania. Możliwe wówczas byłoby precyzyjne wskazanie zakresu zastosowań metody oraz jej pełniejsza ocena.