Metodyka tworzenia oprogramowania dla systemów zarządzania wiedzą oparta na języku UML

W każdej organizacji biznesowej, nawet najmniejszej, istnieje obieg wiedzy. Wiedza jest przez członków tej organizacji (pracowników, kierownictwo, itd.) produkowana, weryfikowana, wdrażana do użytku i wreszcie – używana ([FIRE2001]). Używanie wiedzy powoduje potrzebę wyprodukowania nowej wiedzy i w ten sposób cykl obiegu się zamyka. Niestety, efektywność opisanego powyżej procesu jest coraz bardziej niezadowalająca. Dotyczy to szczególnie dużych organizacji, dla których często sposób wykorzystania zgromadzonej wiedzy decyduje o ich przewadze konkurencyjnej ([TIWA2000]). Odpowiedzią na te rosnące potrzeby są systemy wspomagania obiegiem wiedzy. W niniejszym rozdziale zajmiemy się problematyką tworzenia takich systemów (patrz np. [WIIG1993], [SCHR1994], [EKMF2002]). Ze względu na ich złożoność oraz specyfikę, bardzo istotne jest odpowiednie zorganizowanie cyklu wytwórczego. Podstawową cechą prezentowanego tutaj podejścia jest założenie, że korzystamy z gotowych komponentów szkieletu architektonicznego. Nie opisujemy zatem sposobu budowy poszczególnych elementów konstrukcyjnych. Zakładamy, że są one dostarczone w postaci gotowej do skonfigurowania i powiązania w jedną spójną całość. Przykładem takiego szkieletu gotowych komponentów dla tworzenia inteligentnych systemów zarządzania obiegiem wiedzy jest platforma ICONS [ICON2002a]. Bardzo istotne dla naszej metodyki jest to, że dostarczone komponenty (tak jak to ma miejsce w przypadku ICONS) są wykonane w jednej technologii komponentowej (np. Enterprise Java Beans) i posiadają ściśle zdefiniowany protokół porozumiewania się (interfejsy). Główny wysiłek podczas tworzenia systemu opartego na takim szkielecie jest skierowany na określenie wymagań funkcjonalnych, stworzenie odpowiedniego interfejsu użytkownika, wybór odpowiednich komponentów i wreszcie ich umiejętna konfiguracja. Trzeba jednak podkreślić, że „konfiguracja” komponentów dla systemu zarządzania wiedzą jest nadal zadaniem nie trywialnym i wymaga znajomości odpowiednich technik, notacji czy języków programowania wiedzy.

Bardzo istotnym aspektem metodyki wytwarzania oprogramowania jest wykorzystywana notacja i sposób opisu. Ponieważ metodyka powinna być zrozumiała dla wszystkich, nawet niedoświadczonych, uczestników procesu, bardzo ważna jest komunikatywność prezentacji. Najbardziej komunikatywne są notacje wizualne, zatem proponujemy tutaj wykorzystanie standardowej notacji graficznej UML (Unified Modelling Language) [BOCH2002], [MULL2000], [FOWL2002]. Notacja ta sprawdziła się w przypadku modelowania systemów oprogramowania (jak również systemów i procesów biznesowych) i jest zrozumiała dla coraz szerszej rzeszy ich twórców. Opis tych elementów UML-a, które zostały zastosowane w naszej metodyce jest przedstawiony w następnej sekcji.

W kolejnych sekcjach zostaną zaprezentowane poszczególne elementy proponowanej przez nas metodyki. Na początku, przedstawiony zostanie model cyklu życia, czyli podział na fazy wytwórcze oraz dyscypliny grupujące podobne czynności. W następnej sekcji zostaną opisane najważniejsze role w procesie wytwórczym oraz artefakty (produkty), za które są one odpowiedzialne. Należy zaznaczyć, że opis ten zawiera jedynie role, które są najściślej związane z samym procesem wytwórczym oraz z wytwarzaniem artefaktów dotyczących właściwego przetwarzania wiedzy. Pominęliśmy np. role związane z dyscypliną testowania czy dyscypliną zarządzania projektem. Role te są oczywiście bardzo istotne, ale uznaliśmy, że ich opis wykracza poza tematykę niniejszej pracy. Kolejna sekcja zawiera opis przepływu pracy w ramach realizacji dwóch rodzajów iteracji cyklu wytwórczego. Wreszcie, ostatnia sekcja zawiera podsumowanie.

Zastosowana przez nas notacja opisu metodyki oparta jest na dwóch podstawowych modelach języka UML: modelu klas oraz modelu czynności. Składnikami tych modeli będą „role”, „artefakty”, „czynności” oraz relacje między nimi. Role i artefakty występują na diagramach klas. Czynności występują na diagramach czynności. Wszystkie te elementy są opisane poniżej.

Rola, w rozumieniu opisywanej tu metodyki, to osoba lub grupa osób będących członkami zespołu tworzącego system oprogramowania, odpowiedzialnych za wykonywanie określonego zakresu czynności i wytwarzanie określonych artefaktów. Warto podkreślić, że członek zespołu może pełnić kilka ról. Rola jest elementem modelu stanowiącym klasę w rozumieniu języka UML, o odpowiednim stereotypie (<>). Na diagramach rola oznaczana jest jako figura człowieka zawarta w okręgu ze strzałką.

Artefakt to element informacyjny, który jest tworzony, modyfikowany lub wykorzystywany przez proces wytwarzania oprogramowania. Artefakt wyznacza zakres odpowiedzialności roli i podlega kontroli zmian. Artefaktem może być cały model, element modelu, dokument czy też element oprogramowania (program). Artefaktem nie jest natomiast diagram, który stanowi tylko wizualizację jakiegoś fragmentu modelu. Podobnie jak w przypadku roli, artefakt jest klasą o odpowiednim stereotypie (<>). Na diagramach, artefakt oznaczany jest jako okrąg z podkreśleniem.

Znaczenie diagramu klas (ang. class diagram) jest identyczne z jego znaczeniem w języku UML. Na diagramach klas prezentowanych w niniejszej pracy występują role, artefakty oraz relacje między nimi. Wykorzystywane są relacje asocjacji, agregacji oraz dziedziczenia. W opisie prezentowanej tu metodyki można znaleźć dwa rodzaje diagramów klas. Pierwszy rodzaj przedstawia powiązania między artefaktami, a drugi rodzaj – powiązania między rolą i artefaktami, które ta rola używa (stereotyp <>), bądź, za które jest odpowiedzialna (stereotyp <>).

Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. Na diagramie umieszczamy stan początkowy i końcowy oraz stany pośrednie. Stany określają wykonywane czynności. Przejścia między stanami następują po zakończeniu trwania czynności i są zaznaczane strzałkami. Przejście do następnej czynności może być obwarowane pewnym warunkiem, który opisany jest obok strzałki. Możliwe jest też równoległe wykonywanie czynności, co zaznaczane jest poziomymi belkami (synchronizacja początkowa i końcowa). Diagramy czynności w naszej metodyce służą do prezentacji przepływu pracy w ramach poszczególnych iteracji.

Cykl życia oprogramowania w proponowanej przez nas metodyce oparty jest na zasadzie iteracyjności. Oznacza to budowę systemu poprzez realizację kolejnych elementów funkcjonalności systemu w kolejnych podcyklach produkcyjnych (iteracjach). Należy podkreślić, że zasada iteracyjności jest wykorzystywana przez większość współczesnych metodyk tworzenia oprogramowania, zarówno tych wykorzystujących techniki obiektowe, jak i inne. Iteracja jest podstawą metodyki RUP [RUP2002], obejmującej bardzo szeroko cały proces techniczny. Również cykl wytwórczy tzw. metodyk zwinnych (ang. agile) [BECK2000], [HIGH2000], [CONS2001] jest oparty na procesie iteracyjnym. Jeszcze inna metodyka – ISO/IEC 12207 [ISO2002], również dopuszcza stosowanie cyklu iteracyjnego (mimo, że raczej stosuje elastyczną wersję cyklu kaskadowego).

Cykl iteracyjny wydaje się być szczególnie uzasadniony w przypadku tworzenia systemów wspomagających zarządzanie wiedzą. W takich systemach bardzo istotne jest bowiem zapewnienie funkcjonowania procesu obiegu wiedzy ściśle zgodnie z oczekiwaniami użytkowników. Taki proces obejmuje szeroki zakres bardzo różnych i zmiennych czynności biznesowych. W związku z tym, tylko elastyczne podejście iteracyjne pozwala zapanować nad zmieniającymi się wymaganiami i zapewnić możliwość ciągłej weryfikacji. Ważnym dodatkowym uwarunkowaniem jest konieczność stopniowego rozszerzania funkcjonalności systemu wraz ze stopniowym wdrażaniem cyklu obiegu wiedzy w organizacji. Proces iteracyjny budowy systemu daje niewątpliwie takie możliwości.

Podstawowym artefaktem, w oparciu o który sterowany jest proponowany przez nas proces iteracyjny, jest przypadek użycia (patrz: sekcja 4.2). Stanowi on jedyny i wystarczający miernik przyrostu funkcjonalności systemu. Uzyskujemy to dzięki temu, że przypadki użycia stanowią opis zamkniętego fragmentu funkcjonalności, o ściśle określonej interakcji początkowej (życzenie użytkownika) i ściśle określonej wartości dostarczonej na końcu (oczekiwania użytkownika). Dzięki temu, możliwa jest budowa systemu „przypadek po przypadku”. Zrealizowanie kolejnego przypadku użycia oznacza, że system wzbogacił się o konkretną dla użytkownika wartość z punktu widzenia jego oczekiwań od systemu. Oczywiście, tutaj „zrealizowanie” oznacza przejście przez wszystkie dyscypliny produkcji oprogramowania, łącznie z testowaniem i oceną użytkowników.

W naszym podejściu proponujemy zatem iteracyjny cykl wytwórczy sterowany przypadkami użycia. Ponadto, w ramach iteracji wyróżniamy szereg dyscyplin grupujących czynności o podobnym znaczeniu dla procesu. Bardzo istotne jest to, że pierwsza iteracja zdecydowanie różni się od pozostałych. Jest to tzw. iteracja rozpoczęcia. W trakcie tej iteracji dokonywane są głównie czynności w ramach dyscypliny „projektowania wiedzy i funkcjonalności” (oraz „projektowania systemu wiedzy” – głównie projekt architektoniczny). Podstawowym zadaniem tej iteracji z punktu widzenia cyklu wytwórczego jest wytworzenie zestawu przypadków użycia, które będą realizowane w pozostałych iteracjach – konstrukcyjnych. Rysunek 1 przedstawia omówiony tutaj cykl wytwórczy z podziałem na iteracje oraz dyscypliny, a także pokazuje sterowanie przypadkami użycia. Na rysunku, dyscypliny reprezentowane są przez poziome belki. Sterowanie przypadkami użycia zaznaczone jest przerywanymi strzałkami. Strzałki pełne obrazują przepływ wymagań i ich realizacji.

Zgodnie z opisem cyklu życia, najważniejszymi artefaktami procesu wytwórczego są System wspomagania zarządzania wiedzą (SWZW) i Model przypadków użycia (patrz rysunek 1). Te dwa podstawowe produkty są uzupełnione o szereg innych (rysunek 2). SWZW składa się z Komponentów, które tworzą Architekturę logiczną. Każdy komponent udostępnia szereg Interfejsów oraz korzysta z interfejsów innych komponentów. W naszej metodyce zakładamy, że interfejsy (i komponenty) powinny być stworzone w technologii J2EE, czy innej opartej na języku Java.

Wszystkie komponenty zostały przez nas pogrupowane w trzech klasach będących specjalizacjami klasy Komponent. Komponenty stosowane oznaczają te spośród komponentów szkieletu architektonicznego, które są stosowane praktycznie bez ingerencji w ich strukturę. Są one jedynie w pewnym stopniu parametryzowane, tak, aby dopasować swe działanie do potrzeb reszty systemu. Komponenty konfigurowane stanowią grupę tych elementów systemu, które wymagają znaczącej konfiguracji wynikającej z wymagań na schemat wiedzy w nich zawartej. Konfigurowanie tych komponentów często polega na pisaniu kodu lub tworzeniu złożonych modeli graficznych. Dlatego też komponenty z tej grupy wymagają stworzenia szeregu artefaktów pomocniczych wspomagających proces ich konfiguracji. Komponenty wytwarzane to grupa komponentów nie zawartych bezpośrednio w szkielecie architektury. Są one tworzone w miarę potrzeb wynikłych ze specyfikacji funkcjonalnej i specyfikacji wiedzy. Najczęściej komponenty te są tworzone w sposób tradycyjny – przy wykorzystaniu języków programowania wysokiego poziomu (np. Java).

W dalszej części opisu zajmiemy się głównie Komponentami konfigurowanymi, gdyż ich parametryzacja stanowi zasadniczą część czynności podczas tworzenia SWZW. Najważniejsze komponenty tego typu zostały przedstawione na rysunku 3. i w tabeli 1.

Tabela zawiera też listę artefaktów pomocniczych dla każdego komponentu z podziałem na dyscypliny cyklu wytwórczego. Poszczególne artefakty z dyscyplin „projektowych” stanowią niezbędną dokumentację komponentów. Artefakty z dyscypliny implementacji są artefaktami wykonanymi w oparciu o tę dokumentację i stanowią faktyczną realizację funkcjonalności interfejsów dostarczanych przez poszczególne komponenty.

Z poszczególnymi artefaktami są ściśle związane role, które je wytwarzają i które z nich korzystają (rysunek 4). Ekspert dziedziny wiedzy komunikuje się z Projektantem wymagań wiedzy. Ten z kolei tworzy artefakty wykorzystywane przez Architekta, oraz Projektanta struktur wiedzy. Z Architektem współpracuje Projektant funkcjonalności. Projektant struktur wiedzy przekazuje swoje produkty Projektantowi struktur treści. Obydwaj projektanci struktur współpracują z odpowiadającymi im programistami.

Wszystkie wymienione role i artefakty są przedstawione w kolejnych sekcjach. Artefakty pogrupowane są ze względu na wytwarzające je role.

Ekspert dziedziny wiedzy (rysunek 5) uczestniczy we wszystkich czynnościach związanych z artykułowaniem wiedzy w zadanej dziedzinie. Podstawowy zakres odpowiedzialności eksperta obejmuje tworzenie i uaktualnianie Opisu dziedziny wiedzy. Osoby będące ekspertami dziedziny wiedzy często występują również w rolach Projektanta wymagań wiedzy lub Projektanta funkcjonalności.

Opis dziedziny wiedzy stanowi wizję możliwych zastosowań Systemu zarządzania wiedzą. Treść tego dokumentu wywiera istotny wpływ na wszystkie najważniejsze komponenty składowe systemu. Opis dziedziny wiedzy jest zasadniczo dokumentem tekstowym o swobodnej strukturze. Dokument ten powinien opisywać w niezbędnych szczegółach zakres zadanej dziedziny wiedzy.

Rolą Projektanta wymagań wiedzy (rysunek 6) jest określenie zakresu wiedzy, która będzie bezpośrednio dostępna w ramach Systemu. Projektant wymagań wiedzy zamienia wizję skonstruowaną przez Eksperta dziedziny problemu na konkretną specyfikację.

Specyfikacja wymagań wiedzy składa się z kilku artefaktów związanych z różnymi komponentami (patrz tabela 1). Wynika to z konieczności reprezentacji różnych rodzajów wiedzy przy pomocy różnych notacji. Na podstawie analizy Opisu dziedziny problemu, Projektant (w porozumieniu z Architektem) powinien wybrać niezbędne reprezentacje i stworzyć odpowiednie artefakty.

Specyfikacja słownika pojęć powinna zawierać opis dziedziny wiedzy obejmowanej przez słownik oraz wymagania pozafunkcjonalne dotyczące słownika. Dziedzina wiedzy opisana wcześniej przez Eksperta dziedziny wiedzy powinna zostać tu przedstawiona w sposób formalny, przy pomocy zestawu tematów definiujących zawartość słownika. Tematy posłużą do zdefiniowania pojęć (ang. topic) w ramach Schematu słownika pojęć.

Specyfikacja mapy wiedzy to opis zbioru kategorii, według których obiekty z Bazy treści zostaną wyselekcjonowane i pogrupowane w ramach pojedynczej Mapy wiedzy. Specyfikacja mapy wiedzy definiuje także sposób materializacji Mapy wiedzy (manualny, automatyczny).

Specyfikacja schematu wiedzy to model klas (w języku UML) schematu wiedzy oraz nieformalny (tekstowy) opis tego modelu. Klasy modelu reprezentują poszczególne typy i postaci wiedzy istniejące w systemie (procedury, obrazy struktur, definicje procesów biznesowych, programy wnioskujące itp.).

Projektant funkcjonalności (rysunek 7) jest odpowiedzialny za określenie ram funkcjonalnych SWZW. Oznacza to tworzenie modelu przypadków użycia.

Projektant funkcjonalności powinien posiadać wiedzę na temat wykorzystywanego szkieletu architektonicznego. Dzięki temu, jest w stanie zaprojektować zestaw przypadków użycia oraz ich szczegółowych scenariuszy, tak, aby możliwe było pełne wykorzystanie możliwości szkieletu (w szczególności – komponentów opisu wiedzy).

Model przypadków użycia grupuje aktorów i przypadki użycia, którzy umieszczani są na diagramach przypadków użycia. Zarówno notacja modelu jak i jego znaczenie jest identyczne jak w języku UML (patrz np. [BOCH2002]).

Scenariusz przypadku użycia ilustruje sposób wykonania przypadku użycia. Scenariusz taki stanowi zatem jedną z instancji przypadku użycia (podobnie jak obiekt stanowi instancję klasy). Dla każdego przypadku użycia należy (w miarę możliwości) wyspecyfikować wszystkie możliwe scenariusze. Scenariusz przypadku użycia powinien mieć formę krótkiego opisu tekstowego (np. kolejno numerowane zdania) zgodnego z wybraną gramatyką dla scenariuszy przypadków użycia (patrz [GRAH1995]).

Projektant struktur wiedzy odpowiada za opracowanie projektu realizacji komponentów związanych z reprezentacją wiedzy. Rola ta bezpośrednio korzysta ze specyfikacji tworzonych przez Projektanta wymagań wiedzy. Schemat słownika pojęć jest tworzony przez rolę jako artefakt pomocniczy dla Wykonawcy aplikacji wiedzy. Schemat wiedzy stanowi natomiast bezpośrednią implementację odpowiedniego komponentu.

Schemat słownika pojęć wynika ze standardu Topic Map [ISO2000] stosowanego dla Słownika pojęć. Schemat składa się z klas tzw. pojęć (ang. topic), klas związków między nimi oraz klas tzw. wystąpień (ang. occurence). Schemat zawiera również zbiór ograniczeń (wzorców klas) nałożonych na zbiór instancji poszczególnych klas.

Schemat wiedzy prezentuje w ujęciu globalnym informacje o wiedzy (strukturalnej, proceduralnej i deklaratywnej), składowanej w Bazie treści oraz o powiązaniach pomiędzy komponentami wiedzy różnych typów. Schemat wiedzy zrealizowany jest jako zbiór obiektów, oparty o odpowiedni model klas, zdefiniowany w Specyfikacji schematu wiedzy.

Projekt wnioskowania zawiera wyszczególnienie obszarów funkcjonalnych systemu, które zostaną zrealizowane z wykorzystaniem mechanizmów wnioskowania oraz szczegółowy opis realizacji tych mechanizmów (rodzaj wnioskowania, specyfikacja odpowiedniego narzędzia/systemu wspomagającego wnioskowanie itp.).

Projektant struktur treści jest odpowiedzialny za tworzenie i utrzymywanie artefaktów dotyczących Repozytorium treści na poziomie projektu systemu. Rola ta korzysta bezpośrednio z produktów wytworzonych przez Projektanta struktur wiedzy. Artefakty tworzone przez Projektanta struktur treści są bezpośrednio tworzone w ramach szkieletu architektonicznego i stanowią składowe komponenty Repozytorium.

Indeks semantyczny to część Repozytorium treści. Indeks przechowuje informacje o powiązaniach pomiędzy klasami w Schemacie treści oraz o faktycznych powiązaniach pomiędzy obiektami w Repozytorium treści, co podczas nawigacji po Repozytorium pozwala uzyskać informacje o kontekście obiektów.

Schemat treści definiuje model danych dla Repozytorium treści. W istocie schemat treści będzie traktowany również jako warstwa metadanych Repozytorium treści, poprzez którą będzie realizowany dostęp do właściwej zawartości.

Architekt jest odpowiedzialny za stworzenie i utrzymywanie logicznej architektury tworzonego systemu. Osoba pełniąca rolę architekta komponuje strukturę całego systemu poprzez określenie poszczególnych logicznych komponentów oraz zdefiniowanie interfejsów pomiędzy nimi (w oparciu o wykorzystywany szkielet architektury). Zadaniem architekta jest zapewnić, aby koncepcja architektury systemu pozwoliła na realizację wymaganej funkcjonalności i zawartości wiedzy.

Architektura logiczna reprezentuje strukturę organizacyjną tworzonego systemu (logiczne warstwy systemu, główne komponenty oraz interfejsy). Notacja Architektury oparta jest na diagramach komponentów (ang. component diagrams) udostępnianych przez język UML. Dodatkowo, stosowane są diagramy interakcji umożliwiające prezentację dynamiki działania systemu. W naszej metodyce, architektura jest oparta na ustalonym szkielecie architektonicznym służącym tworzeniu SWZW (np. szkielet ICONS). Należy tu jednak podkreślić, że opis struktury tego szkieletu leży poza zakresem niniejszej pracy, i jest przedmiotem osobnych opracowań (patrz np. [ICON2002b]).

Interfejs definiuje zbiór operacji oferowanych przez komponent innym komponentom. Definicja każdej operacji powinna być złożona co najmniej z opisu tekstowego, sygnatury, oraz opisu zbioru parametrów wejściowych i wyjściowych. Implementacje interfejsu pozwalają na komunikację pomiędzy poszczególnymi częściami systemu oraz pomiędzy systemem a systemami zewnętrznymi.

Komponent reprezentuje fragment kodu programu (źródłowy, binarny, wykonywany) lub inny fizyczny, wymienialny składnik systemu (np. skrypt), który realizuje specyficzną funkcjonalność, może udostępniać swoje funkcje innym komponentom i sam może korzystać z funkcji oferowanych przez inne komponenty. Komponent może być złożony z komponentów składowych.

Zadaniem Wykonawcy aplikacji wiedzy jest implementacja komponentów związanych z reprezentacją wiedzy w systemie. Rola ta działa bezpośrednio w środowiskach wytwórczych stworzonych dla poszczególnych komponentów. Przeważają tutaj czynności związane z programowaniem (w sposób tekstowy i graficzny).

Słownik pojęć jest bezpośrednio oparty na standardzie Topic Map [ISO2000]. Jest to plik tekstowy zapisany np. w języku XTM zawierający m.in. poszczególne pojęcia i wystąpienia zgodnie ze Schematem słownika wiedzy. Słownik pojęć jest realizacją ontologii dla obsługiwanej dziedziny wiedzy.

Mapa wiedzy to zbiór obiektów z Bazy treści pogrupowanych według kategorii zdefiniowanych w specyfikacji mapy wiedzy. W systemie może istnieć wiele Map wiedzy, także tworzonych przez użytkowników końcowych systemu.

Program wnioskujący to program realizujący mechanizmy wnioskowania dla wybranego obszaru funkcjonalnego systemu. Może być zaimplementowany w języku programowania reguł wiedzy (np. DLV), programowania w logice (np. Prolog), systemie eksperckim itp.

Wykonawca repozytorium treści jest rolą tworzącą bazodanowe struktury repozytorium przechowującego treść (Baza treści). Podstawą do stworzenia Bazy treści są artefakty wytworzone przez Projektanta struktur treści. Rola ta jest bardzo podobna do roli wykonawcy klasycznej bazy danych, gdyż Baza treści jest oparta na modelu relacyjnym.

Baza treści przechowuje wszystkie właściwe obiekty informacyjne stanowiące o wiedzy udostępnianej przez system (opisy doświadczeń, procedury, opisy procesów, opisy struktur itp). Obiekty są instancjami klas zdefiniowanych w Schemacie treści. Baza treści łącznie z Indeksem semantycznym oraz Schematem treści tworzy Repozytorium treści.

Proces wytwórczy określa kolejność wykonywanych czynności w ramach iteracji rozpoczęcia i iteracji konstrukcyjnych cyklu życia (patrz rysunek 1). Na diagramach zamieszczonych poniżej, czynności z szarym tłem reprezentują operacje przetwarzania artefaktów wymienionych w poprzednich sekcjach.

Podstawą dla rozpoczęcia projektu i samej iteracji rozpoczęcia (rysunek 13) jest powstanie opisu dziedziny wiedzy. Na tej podstawie, Architekt dokonuje wyboru struktur reprezentacji wiedzy, a Kierownik projektu dokonuje planowania całego projektu (w tym – podział na iteracje). Następnie równolegle (przez Projektanta funkcjonalności i Projektanta wymagań wiedzy) wykonywane są czynności, których sumaryczny rezultat daje wstępny obraz funkcjonalności systemu i zawartości wiedzy. W zależności od potrzeb dotyczących zawartości wiedzy, powinny powstać artefakty wybrane spośród wymienionych w sekcji 4.2.

W wyniku kolejnych czynności powstaje ogólny projekt systemu (architektury logicznej, interfejsu użytkownika oraz źródeł wiedzy). Iteracja kończy się fazą oceny wyników bieżącej iteracji oraz stworzeniem ogólnego planu iteracji konstrukcyjnych (przydzielenie do każdej iteracji konstrukcyjnej zestawu przypadków użycia do realizacji) i szczegółowego planu dla pierwszej iteracji konstrukcyjnej.

Iteracja konstrukcyjna (rysunek 14) rozpoczyna się od czynności polegających na szczegółowym zaprojektowaniu fragmentu funkcjonalności opisywanego przez wybrane dla tej iteracji przypadki użycia. Są tutaj tworzone m.in. szczegółowe scenariusze przypadków użycia. Na podstawie projektu funkcjonalności, Architekt dokonuje szczegółowego opisu dynamiki systemu w wybranym zakresie, czyli tworzy diagramy interakcji będące fragmentem architektury logicznej. Równocześnie, Projektant struktur wiedzy tworzy projekt struktur reprezentacji wiedzy (schemat słownika pojęć i schemat wiedzy). W ramach implementacji systemu wykonywanych jest równocześnie szereg czynności. Są tu m.in. wykonywane komponenty opisane w tabeli 1 (artefakty implementacyjne). Na tym poziomie jest też projektowane i wykonywane Repozytorium treści. Po etapie implementacji, następuje etap integracji systemu. Równolegle, Repozytorium treści jest wstępnie zasilane danymi. Po tym wykonywane są odpowiednie testy akceptacyjne dla zaimplementowanych w tej iteracji przypadków użycia (oraz regresyjnie – dla zaimplementowanych wcześniej). Iteracja konstrukcyjna kończy się fazą oceny wyników bieżącej iteracji oraz stworzeniem szczegółowego planu dla kolejnej iteracji konstrukcyjnej.

W rozdziale został zaproponowany sposób postępowania prowadzący do wytworzenia systemu wspomagającego zarządzanie wiedzą. Metodyka tutaj przedstawiona jest metodyką ogólną i nie jest ograniczona do konkretnej technologii czy konkretnego szkieletu architektonicznego. Mimo swej ogólności, metodyka zawiera szczegółowo określony zestaw ról i artefaktów, które powinny występować w projektach tworzenia Systemów wspomagających zarządzanie wiedzą. Metodyka przez nas proponowana dostarcza konkretnego materiału dla inżynierów procesu w organizacji tworzącej czy zamawiającej tego typu oprogramowanie. Inżynier procesu, czy kierownik projektu, planując proces techniczny dostaje wsparcie w postaci gotowych opisów ról czy artefaktów. Takie opisy mogą być (po dokładnym opisaniu notacji i konwencji) bezpośrednio stosowane przez uczestników procesu wytwórczego pełniących poszczególne role. Ze względu na swoją ogólność, zastosowanie metodyki w projekcie powinno być poprzedzone fazą jej konfiguracji (przystosowania do uwarunkowań konkretnego Systemu czy organizacji). Należy podkreślić, że proponowana metodyka wyróżnia się wśród istniejących metodyk dostarczeniem kompleksowego opisu procesu wytwórczego łączącego w sobie cechy metodyk wytwarzania oprogramowania z cechami szczegółowych metodyk tworzenia elementów opisu wiedzy.

Zaprezentowana metodyka jest obecnie wykorzystywana w projekcie ICONS, gdzie służy do organizacji procesu wytwarzania portalu wiedzy o projektach strukturalnych UE. Obecne doświadczenia wskazują na dużą elastyczność opisu metody i możliwość jej łatwego przystosowania do projektów budowy SWZW.