Studia Podyplomowe IT w Biznesie Tworzenie Portali Biznesowych

1. Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Studia Podyplomowe IT w BiznesieTworzenie Portali Biznesowych Wykład 1 Systemy zarządzania treścią Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK subieta@ipipan.waw.pl http://www.ipipan.waw.pl/~subieta

2. Co to jest "zarządzanie treścią"? content management • Komercyjny buzzword związany z ekspansją zastosowań Internetu (WWW) oraz rozwojem narzędzi służących do budowy aplikacji internetowych. • Istnieją w tej chwili dziesiątki (a może już i setki) systemów określanych jako "systemy zarządzania treścią" (Content Management Systems, CMS). • Nie istnieje wyróżnik określający, co CMS ma zawierać. Poszczególne systemy różnią się zarówno oferowaną funkcjonalnością, jak i ceną (0$  kilku mln.$). • Istnieje duży chaos w zakresie terminologii, standardów, technologii i biznesowej retoryki związanej z systemami CMS oraz ich zastosowaniami.

3. Co to jest "treść"? content • Termin "treść" nie ma jednej definicji. Niektóre rodzaje: • Treść ukazująca się na ekranie przeglądarki: tekst, grafika, tło, dźwięk, animacja, video, przyciski, pola do zapełnienia, menu do wybrania, wykonywane na ekranie skrypty,...; • Odpowiedniki, elementy składowe lub generatory tej treści przechowywane po stronie serwera (np. w bazie danych); • Procesy, programy, reguły, metody, algorytmy pozwalające na generowanie treści z określonych źródeł, np. z bazy danych serwera lub z innych stron Web. • Różne formy opisu treści lub metadanych dotyczących treści, formaty, schematy, opisy dotyczące autorów treści, daty utworzenia, daty obowiązywania, własności, itd. • Różne formy kontroli i organizacji treści oraz usprawnienia dostępu: katalogi, klasyfikacje, indeksy, słowniki, ...

4. Treść vs. dane, informacja, wiedza content, data, information, knowledge • Jest dość trudno podać definicje różnicujące te terminy. • Są często używane jako synonimy. • Niekiedy odzwierciedlają emocjonalny stosunek do przedmiotu, np. dla ludzi AI "wiedza" lepiej pasuje do "inteligencji". • Niekiedy odzwierciedlają specyfikę celu przetwarzania i jakąś jego nową jakość: np: "wydobywanie wiedzy", a nie "wydobywanie danych"; "baza wiedzy", a nie "baza danych". • Niekiedy odzwierciedlają stosunek do procesów decyzyjnych zachodzących w ludzkim umyśle (dane muszą zamienić się w informację, ta zaś w wiedzę, aby mogła być podjęta decyzja). • Treść jest rozumiana jako informacja, dane lub wiedza: • przekazywana do końcowego użytkownika przeglądarki, • zawarta w repozytorium serwera aplikacji internetowej.

5. Formaty i standardy treści • Setki formatów i standardów obowiązujących w zakresie reprezentacji, przechowywania, przetwarzania i udostępniania treści. • Klasycznym standardem jest HTML, z licznymi rozszerzeniami w kierunku dynamizacji stron (JavaScript, aplety, ASP, JSP, ...) • Najnowszym buzzwordem jest XML oraz związane z nim technologie lub standardy (DTD, RDF, XSL, XSLT, XQL, SOAP, ...) • Wiele formatów reprezentacji tekstu: .txt, .doc, .rtf, .pdf, .ppt,... • Dziesiątki formatów graficznych (grafiki wektorowej i pikselowej), formatów animacji, audio i video. • Formaty, modele i standardy baz danych. • Formaty i standardy języków programowania stron Webu (Java, SQL, ODBC, JDBC, PHP, Perl, Python, ...).

6. Twórczy chaos w dziedzinie CMS • Nowość technologiczna i rynkowa oraz możliwość zarobienia wielkich pieniędzy rodzi na początku chaos. • Jeżeli dla danego typu treści są popularne formaty A, B, C, to potrzebne będą odwzorowania A  B, B  A, A  C, ... Liczba odwzorowań rośnie w kwadracie do liczby formatów. • Brak standardów i niekompatybilne rozwiązania implikuje oprogramowanie pośredniczące (middleware), bazujące najczęściej na nowym formacie (patrz CORBA, również XML). • Syndrom "dwóch programistów w garażu": sukces rozwiązania dla mikro-skali powoduje rozszerzanie bottom-up tego rozwiązania dla makro-skali (patrz HTML, XML, PHP, ...). Skutek: 1000-stronicowe podręczniki "prostego" języka XML. • Twórczy chaos był już w innych dziedzinach (np. w językach programowania). Zwykle po pewnym czasie ustępuje.

7. Techniczna architektura CMS Content Management System interakcja poprzez HTTP zapytania SQL i ich wyniki klient Serwer bazy danych Serwer Web: generacja dynamicznych stron HTML dla klienta, zlecenia do bazy danych klient klient zapytania SQL i ich wyniki klient pracownik Zaplecze (back office): Wewnętrzne procesy podtrzymywania i obsługi aplikacji internetowej pracownik pracownik

8. Tematy związane z zarządzaniem treścią Mobilni agenci Technologie agentowe Mobilne i rozproszone przetwarzanie Rozproszona sztuczna inteligencja Semantyczny Web i ontologie Odkrywanie wiedzy Eksploracja danych Techniki markup Zarządzanie treścią na Webie Zarządzanie wiedzą Maszynowe uczenie się Klasyfikacja Metamodelowanie wiedzy Zarządzanie wierzeniami Handel Elektroniczny Inteligentna integracja informacji Personalizacja Zarządzanie treścią Budowa profili E-serwisy Zarzadzanie profilami i lokacjami Zarządzanie transakcjami Filtrowanie Mobilny Handel

9. Główne komponenty CMS SYSTEM TWORZENIA I GROMADZENIA Procesy pozyskiwania i rozkładania pierwotnej informacji na składowe treści SYSTEM ZARZĄDZANIA Odpowiedzialny za automatyzację manipulacji treścią przez użytkowników biznesowych SYSTEM PUBLIKOWANIA Zautomatyzowany proces wyciągania treści i zasobów z repozytorium do publikacji REPOZYTORIUM TREŚCI Treść, dane biznesowe, metainformacje SYSTEM STEROWANIA PROCESAMI PRACY Koordynacja, planowania i wprowadzanie w życie pracowniczych harmonogramów oraz zadań systemu SYSTEM ADMINISTRACYJNY Proces podtrzymywania eksploatacji, ustawiania i utrzymywania parametrów i struktury systemu

10. System tworzenia i gromadzenia treści • Składa się z narzędzi, procedur oraz personelu, który jest zatrudniony w celu tworzenia i zbierania treści oraz wykonywania czynności redakcyjnych. Zadania: • Wytwarzanie treści "od zera": autorzy projektują, tworzą i poprawiają treść w wybranych przez siebie narzędziach. • Pozyskiwanie: dostosowywanie i redakcja treści z zewnętrznych źródeł. • Agregacja: formatowanie stylistyki informacji i ustalanie jej przeznaczenia: użyteczne składowe, meta-dane. • Konwersja: zmiany formatu i struktury informacji tak, aby spełniała ona wymagane standardy przechowywania treści; oddzielanie niepotrzebnych informacji np., nagłówków i stopek; odwzorowania tego formatu na wymagany standard, np. XML, który może być wprowadzony do systemu. • Usługi: są częścią logiki aplikacji oraz usług biznesowych dostarczonych przez CMS, wspomagających gromadzenie informacji oraz jej transformację. Usługi wspierają tworzenie, aktualizację i usuwanie składowych treści.

11. System zarządzania • Odpowiada za gromadzenie, przechowywanie, udostępnianie, pielęgnację i administrację składowych treści i innych zasobów informacji. • Jest oparty na bazie danych treści, meta-informacji oraz danych biznesowych. • Obejmuje procesy i narzędzia umożliwiające dostęp, aktualizację i administrowanie zgromadzoną informacją. • Jest odpowiedzialny za bezpieczeństwo i autoryzację dostępu do treści. • Jest odpowiedzialny za połączenia z innymi systemami.

12. System sterowania procesami pracy • Realizuje koordynację, planowanie i wprowadzanie w życie harmonogramów oraz zadań pracowników. • Obejmuje narzędzia, procedury i ludzi zatrudnionych w celu zapewnienia skutecznych procesów zbierania, przechowywania i publikacji treści. • System sterowania procesami pracy ma wpływ na system gromadzenia treści, system zarządzania oraz system publikowania. • Każdy krok procesu, od wytwarzania po ostateczną publikację, powinien być możliwy do zamodelowania i śledzenia w obrębie tego samego systemu. • Aspekty procesów pracy włączają: pracowników, zadania, czynności, standardowe procesy, narzędzia, czas, przepływ danych i dokumentów.

13. System publikowania • Jest odpowiedzialny za wyciąganie składowych treści i innych zasobów z repozytorium, formatowanie ich i automatyczne tworzenie z nich publikacji. • Składa się z narzędzi, procedur i ludzi pobierających treść z repozytorium i tworzących publikacje. • Powinien zawierać: • Szablony publikacji, • Kompletny język programowania, • Zależności pomiędzy treścią, • Dobrze zorganizowany system plików i katalogów, • Mechanizm ostatecznej publikacji.

14. Procesy zarządzania treścią • Włączają projektowanie, tworzenie, pozyskiwanie, recenzowanie, zatwierdzanie, konwersję, składowanie, testowanie i wdrożenie treści we wszystkich wymaganych miejscach Webu. • Włączają pielęgnowanie, monitorowani, uaktualnianie, wycofywanie i archiwizowanie treści. • Włączają komponenty raportujące i analityczne, celem świadomego usprawniania i poszerzania procesów zarządzania treścią. • Wymagają jasnego zdefiniowania ról personelu oraz udokumentowanych procesów pracy dla wszystkich form treści. • Mogą lecz nie muszą być wspomagane komputerowo. • Dla małych zastosowań wspomaganie jest często niepotrzebne. • Dla dużych zastosowań wspomaganie jest zazwyczaj niezbędne.

15. Scenariusze i formy aplikacji zarządzania treścią • Udostępnianie wiadomości (portale), np. internetowe gazety, • w tym wortale (vortals), czyli wiadomości ukierunkowane branżowo. • Wyszukiwarki stron WWW (Yahoo, Altavista, Google, ...) • Techniczne wspomaganie produktów danej firmy. • B2C (Business-To-Customer): e-handel - sklepy internetowe. • Portale wymiany informacji w danej dziedzinie, portale edukacyjne. • B2B (Business-To-Business): e-biznes (portale biznesowe): transakcje, sprzedaż lub wymiana towarów i usług, w skali hurtowej. • B2E (Business-To-Employee): wewnętrzne systemy internetowe lub intranetowe do obsługi procesów biznesowych wewnątrz firmy. • C2C (Customer-To-Customer): ogłoszenia drobne, aukcje, ... • Portale korporacyjne (corporate portals) - organizują rozproszone i heterogeniczne zasoby i usługi informacyjne danej organizacji. • Praca grupowa rozproszonych zespołów, wirtualne biura projektowe. • .... wiele innych możliwości ....

16. Funkcje wspólne dla wielu form i scenariuszy zarządzania treścią (1) • Projektowanie. Zasadniczo nie odbiega od metod projektowania baz danych np. poprzez diagramy encja-związek lub UML. • Tworzenie. Rola wykonywana przez autorów tekstu, fotografów, artystów grafików, producentów video, producentów dźwięku, specjalistów od reklamy i marketingu, prawników, lub kogokolwiek innego, kto produkuje oryginalny materiał przeznaczony dla użytkownika WWW. • Pozyskiwanie lub adoptowanie treści z istniejących źródeł. • Klasyfikacja, indeksowanie. Treść musi mieć przypisane cechy formalne (np. datę utworzenia, autora, itd.) oraz cechy klasyfikacji przedmiotowej (np. kategorię przedmiotową lub słowa kluczowe). Funkcja jest często określana jako wiązanie treści i metadanych.

17. Funkcje wspólne dla wielu form i scenariuszy zarządzania treścią (2) • Recenzje i przeglądy. Są wymagane dla wszystkich rodzajów udostępnianej treści. • Zatwierdzenie. Formalne zatwierdzenie publikowanej treści jest niezbędnym składnikiem prawnej odpowiedzialności za treść. • Konwersja. Tekst, grafika, dźwięk, i inne formy treści musza być przystosowane do formatu najwygodniejszego lub obowiązującego w danym CMS, np. do formatu HTML lub XML. • Przechowywanie. Treść jest zwykle przechowywana w plikach lub w bazie danych. • Dla większych zastosowań treść musi podlegać zarządzaniu konfiguracji (Software Configuration Management, SCM), w szczególności musi podlegać zarządzaniu wersjami oraz śledzeniu i kontrolowaniu zmian.

18. Funkcje wspólne dla wielu form i scenariuszy zarządzania treścią (3) • Testowanie. Może dotyczyć różnych aspektów: • błędnych lub nieaktualnych linek, • stron wolno ładujących się, • błędów w skryptach lub apletach, np. pętli, • błędów w komunikacji od klienta do serwera • Dojrzewanie. Rodzaj testowania, polegający na weryfikacji kompletności i spójności większego zespołu treści, np. informacji o różnych aspektach nowej usługi. • Wdrożenie. Obejmuje wszelkie fizyczne aspekty udostępnienia treści dla jej użytkowników, w tym replikacje treści na różnych serwerach. • Pielęgnacja, aktualizacja, zmiany. Obserwowanie udostępnianej treści i reakcja na wszelkie sygnały i potrzeby zmian.

19. Funkcje wspólne dla wielu form i scenariuszy zarządzania treścią (4) • Wycofywanie i archiwizacja. Wycofanie może nastąpić z wielu powodów, np. utraty aktualności, utraty praw do treści, uatrakcyjnienie portalu nowszą treścią, niską frekwencją odwiedzania, itd. Przyjmuje się, że dowolna wycofywana treść podlega archiwizacji a/a. • Raporty i analizy. Obejmuje różne formy raportów i analiz mających na celu lepszą obsługę użytkowników, zwiększenia atrakcyjności portalu, zbadania efektywności biznesowej, itd. • Ponowne użycie. Wyodrębnienie i generalizacja pewnych elementów treści, metadanych, procesów, funkcji, szablonów formularzy, itd. jako udokumentowanych aktywów ponownego użycia w ramach danego repozytorium; opisywanie i propagowanie aktywów ponownego użycia wśród personelu.

20. Klasyfikacja i przegląd CMS (1) • Duże pakiety obejmujące funkcjonalnością wszystkie etapy i aspekty tworzenia systemów internetowych. • Przykłady: V/6 Content Management Suite (Vignette), One-To-One Publishing (Broadvision), Content Server (Divine). • Produkty o cechach podobnych jw., o mniejszych możliwościach integracji z istniejącymi systemami produkcyjnymi • Przykłady: Content Management Server (Microsoft), PVCS Content Manager(Merant), RedDot Solutions(RedDot), Mediasurface 3.5 (Mediasurface)) • Narzędzia, w których główny nacisk położono na zarządzanie dużymi repozytoriami dokumentów i wspomaganie pracy grupowej • Przykłady: Xpedio Content Management Suite (Stellent), 4I WCM Edition (Documentum), Panagon (FileNET)

21. Klasyfikacja i przegląd CMS (2) • Systemy, które służą do zarządzania cyklem wytwarzania elementów stanowiących treść serwisu (zagadnienia związane z rolami użytkowników, procesem prac) • Przykłady: TeamSite (Interwoven), CommonSpot Content Server (PaperThin) • Narzędzia wspierające końcową fazę powstawania serwisu internetowego czyli jego publikację, personalizację itp. • Przykłady: WebLogic E-Business Platform (BEA), Dynamo e-business Platform (ATG), Oracle9iAS(Oracle) • Systemy tworzone w ramach projektów „open-source”: • Przykłady: Content Management Framework (Zope), Arsdigita Community System (ArsDigita)

22. Rodzaje rozwiązań CMS

23. Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Studia Podyplomowe IT w BiznesieTworzenie Portali Biznesowych Wykład 2 Systemy zarządzania treścią Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK subieta@ipipan.waw.pl http://www.ipipan.waw.pl/~subieta

24. CMS jako katalizator rozwoju • Dla wspomagania funkcji zarządzania treścią dostawcy oprogramowania wytworzyli ogromną liczbę różnych narzędzi, zintegrowanych systemów, oraz rozszerzeń istniejących systemów. • Tradycyjna dziedzina zarządzania dokumentami została w dużym stopniu zdominowana przez funkcje CMS. • Pojawiły się obiektowe repozytoria do przechowywania treści dowolnego typu, w szczególności repozytoria XML. • Dostawcy systemów zarządzania bazami danych, tacy jak Oracle, CA, Sybase, Informix, IBM, przesunęli punkt ciężkości oferowanych SZBD z tradycyjnego zarządzania danymi na zarządzanie treścią, ze wspomaganiem tworzenia i podtrzymywania aplikacji internetowych. • Znaczenia nabrały różnorodne formy procesów pracy (workflows) jako środka kontroli funkcji CMS. • Pojawiły się kompleksowe narzędzia typu "wszystko w jednym".

25. Cechy CMS: procesy pracy i automatyzacja procesów biznesowych workflow Workflow Management System • Zarządzanie treścią wymaga rutynowych usług znanych z procesów pracy (workflows), takich jak: śledzenie, przypisywanie ról i odpowiedzialności, zintegrowane bezpieczeństwo, zautomatyzowane zawiadamianie, monitorowanie populacji procesów. • Systemy zarządzania procesami prac umożliwiają zdefiniowanie wielo-krokowych procesów włączających różnorodną treść, personel, oraz akcje takie jak wysłanie, recenzja, zatwierdzenie, itd. • Systemy zarządzania procesami prac zapewniają automatyzację takich zadań jak: • ustalenie zespołów ludzkich i ról osób w zespołach • projektowanie procesów pracy • tworzenie i podtrzymywanie działania instancji procesów pracy.

26. Cechy CMS: personalizacja personalization • Istotą personalizacji jest: • Rejestracja i autentyfikacja użytkowników aplikacji internetowej. • Dostosowanie się serwisu internetowego do indywidualnych preferencji użytkownika; np. jego preferencje tematyczne. • Przechowywanie i udostępnianie spersonifikowanych treści wprowadzanych przez użytkownika lub sparametryzowanych przez użytkownika; np. jego notatki, zakładki, kalendarz, terminarz zdarzeń, terminarz przypomnień, itd. • Przechowywanie historii odwiedzin serwisu przez użytkowników oraz transakcji lub zakupów, które oni dokonali. • Syntetyczne analizy i raporty dotyczące użytkowników mające na celu zwiększenie jakości i efektywności treści i usług oferowanych przez aplikację internetową.

27. Podejścia do personalizacji • Środki techniczne: • Informacja dokładna o zarejestrowanych użytkownikach zgromadzona w bazie danych po stronie serwera • Informacja o konkretnym koncie i konkretnym komputerze na którym pracuje użytkownik, na podstawie tzw. ciasteczek (cookies). • Ciasteczka są plikami pamiętanymi przez komputer klienta, w których serwer może zapisać dowolną (niezbyt długą) informację. • Konkretny użytkownik jest nieznany, znana jest tylko jego "tożsamość" z dokładnością do konta i komputera. • Ciasteczka nie są dzielone pomiędzy różne portale, każdy portal ma swoje. • Środki dostosowywania treści do profilu użytkownika: • Określanie profilu zainteresowań explicite przez użytkownika. • Wadą jest to, że on zwykle tego nie robi, a jeżeli robi, to niezbyt dokładnie. • Kolaboracyjne filtrowanie (collaborative filtering): tworzenie kategorii użytkowników i przypisywanie użytkownika do określonej kategorii na podstawie historii jego zachowania się na portalu (klikologii)..

28. Cechy CMS: wyszukiwanie search • Sprawny mechanizm wyszukiwania informacji przez końcowych użytkowników jest czynnikiem powodzenia aplikacji internetowej. • Wyszukiwanie oznacza konieczność klasyfikacji treści i inteligentnego jej zaindeksowania. • Wyszukiwanie często odbywać się po cechach formalnych (data publikacji, autor, kategoria tematyczna, słowa kluczowe), które są niekiedy określane (w RDF) jako "metadane". • Częściej wyszukiwanie odbywa się: • w pełnym tekście przechowywanych składników treści • poprzez asocjacje elementów treści z innymi elementami treści • Klasyczne formy wyszukiwania (znane) z bibliotek są mało użyteczne. • Konieczne są nowe paradygmaty, z reguły oparte o metafory graficzne.

29. Cechy CMS: ontologia ontology • W filozofii: nauka o bytach, teoria bytu, opis charakteru i struktury rzeczywistości, specyfikacja konceptualizacji. • W sztucznej inteligencji: formalna specyfikacja (przy użyciu logiki matematycznej) obiektów, pojęć i innych bytów, które istnieją w pewnej dziedzinie, oraz formalna specyfikacja związków, które pomiędzy tymi bytami zachodzą. • Podejście sztucznej inteligencji jest naiwne. Np. Giełda Papierów Wartościowych: wiele tysięcy stron aktów prawnych, zarządzeń, regulacji, itd. Kto to zapisze przy użyciu formuł rachunku predykatów? • W biznesie (ontologia biznesowa, business ontology): wszystko to, co projektanci systemów informatycznych powinni wiedzieć o biznesie, aby poprawnie napisać aplikacje wspomagające ten biznes. • Wiedza ta powinna być formalnie zapisana. "Formalnie" oznacza zwykle pewien standardowy i uzgodniony język, np. XML/RDF.

30. Cechy CMS: metadane metadata • Ogólna definicja: są to dane o danych - co dane zawierają, jaką mają budowę, jakie jest ich znaczenie, jakim podlegają ograniczeniom, jak są zorganizowane, przechowywane, zabezpieczane, udostępniane, itd. • Metadane są pewnym rozszerzeniem pojęcia schematu bazy danych, albo też pewną implementacją tego schematu w postaci katalogów. • Metadane przykrywają także informację niezależną od treści samych danych, np. kiedy pewna dana została utworzona, w jakim jest formacie, kto jest jej autorem, do kiedy jest ważna, itd. • Opisy danych zawarte w metadanych mają dwie podstawowe zalety: • Zawierają wspólne abstrakcje dotyczące reprezentacji danych, takie jak format; ogólnie "wyciągają przed nawias" wszystkie wspólne informacje, co redukuje znacznie objętość samych danych; • Reprezentują wiedzę dziedzinową (ontologię); umożliwiają wnioskowanie o danych, mogą być przez to użyte do redukowania dostępu do samych danych.

31. Ontologia i metadane • Głównym celem prac na biznesową ontologią jest standardyzacja następujących elementów: • Gramatyki opisów poszczególnych bytów, • Nazw i znaczeń nazw obowiązujących w ramach danego biznesu (np. co oznaczają słowa "autor", "klient", "instrument", "akcja", itd.), • Ograniczeń związanych z opisywanymi bytami, • Metadanych związanych z bytami (autor opisu, data stworzenia opisu, data ostatniej aktualizacji, itd.), • Dopuszczalnych operacji na bytach. • W tym zakresie zapis ontologii jest pewną meta-bazą danych, w które ustala się zarówno strukturę samej bazy danych, jak i pewne dodatkowe informacje (meta-atrybuty) będące podstawą przetwarzania bazy danych.

32. Cechy CMS: zarządzanie wiedzą knowledge management • Obejmuje wszystkie aspekty związane z rejestrowaniem, dokumentowaniem oraz wykorzystaniem wiedzy pracowników firmy. • Wiedza dzieli się na: • Wiedzę jawną, bezpośrednio zapisaną w dokumentach, plikach i bazach danych; • Wiedzę cichą, będącą własnością ludzi - pracowników firmy • Wiedza cicha jest zdobywana w praktyce, jest kwintesencją doświadczenia, wyczucia, asocjacji, uświadomionych lub nieuświadomionych poglądów, trenowanych umiejętności rozpoznawania spraw i sytuacji, itd. • Wiedza cicha jest kluczowym strategicznym czynnikiem decydującym o konkurencyjności organizacji na rynku. • Wiedza cicha, mimo że tkwiąca w umysłach poszczególnych osób, jest wiedzą obiektywną - może być sprawdzana, testowana i badana empirycznie ze względu na jej jakość i skuteczność. • Z punktu widzenia organizacji jest więc istotne, aby wprząc tę indywidualną wiedzę pracowników w ogólną kulturę organizacyjną, do której oni należą.

33. Zalecenia w zakresie zarządzania wiedzą • Skupienie się na wiedzy cichej. Niedocenianie, ignorowanie tej wiedzy może mieć negatywne konsekwencje dla konkurencyjności organizacji. • Nacisk na kolektywną bazę wiedzy całej organizacji. Wiedza ta jest sumą wiedzy jawnej i cichej. Oba rodzaje są istotne dla sukcesu biznesowego. • Skupienie się na procesach innowacyjnych, które tworzą przewagę organizacji na rynku. • Skupienie się na ciągłych procesach usprawniania funkcjonowania organizacji, które w zasadniczy sposób są uzależnione od cichej wiedzy. • Skupienie się na procesach kształcenia, ponieważ wiedza, zarówno jawna jak i cicha, jest bezpośrednią ich konsekwencją. • Skupienie się na kompetencji kolektywnej (społecznej), czyli uzupełnianie się wiedzy różnych osóbwewnątrz organizacji i jej części. • Rozwój myślenia systemowego: rozumienie relacji pomiędzy częścią i całością systemu, relacji wewnątrz systemu, wzorców zachowania się wewnątrz systemuoraz związków systemu z jego otoczeniem.

34. Cechy CMS: Zarządzanie konfiguracją Celem zarządzania konfiguracją (treści, oprogramowania) jest planowanie, organizowanie, sterowanie i koordynowanie działań mających na celu identyfikację, przechowywanie i zmiany oprogramowania w trakcie jego rozwoju, integracji i przekazania do użycia. Każdy projekt musi podlegać konfiguracji oprogramowania. Ma ono krytyczny wpływ na jakość końcowego produktu. Jest niezbędne dla efektywnego rozwoju oprogramowania i jego późniejszej pielęgnacyjności. Zarządzanie konfiguracją jest szczególnie ważne, jeżeli projekt może toczyć się przez wiele lat, jeżeli cel lub wymagania na oprogramowanie są niestabilne, jeżeli oprogramowanie może mieć wielu użytkowników, i/lub jeżeli oprogramowanie jest przewidziane na wiele platform sprzętowo-programowych. W takich sytuacjach złe zarządzanie konfiguracją oprogramowania może całkowicie sparaliżować projekt lub doprowadzić do chaosu w zakresie ewidencji i organizacji treści.

35. Cechy CMS: integracja z istniejącymi aplikacjami • Obecne systemy CMS muszą współdziałać z: • Popularnym oprogramowaniem: Word, Excell, Acrobat, PowerPoint, formaty graficzne, formaty multimedialne; • Mogą lub nawet powinny integrować oprogramowanie, które dotychczas działało w organizacji niezależnie od powstałego systemu CMS, np. systemem finansowo-ksiegowym, systemem bibliotecznym: • Współdziałanie oznacza, że: • Praktycznie dowolne aplikacje mogą być wywołane w środowisku CMS • Rezultat tych aplikacji nie jest zakłócony przez to, że jednocześnie działa CMS • Rezultaty tych aplikacji są przejmowane przez CMS • Rezultaty są opakowane w kontekst HTML i przekazywane do klienta jako strony HTML. • W praktyce osiągnięcie takiej integracji nie jest łatwe, • szczególnie przy założeniu, że klient jest "chudy" i nie ma zainstalowanych odpowiednich programów.

36. Wizja architektury ICONS Tekst Mapy wiedzy Systemy biznesowej inteligencji Własności Bazy danych Wyszukiwanie Sieci semantyczne Mapy wiedzy Modele semantyczne Reprezentacja czasu Integracja informacji Strony Web Pliki Reprezentacja wiedzy Wnioskowanie Drzewa koncepcyjne Sieci semantyczne Hiper-tekst Spadkowe systemy informacyjne Zarzadzanie dokumentami Modele semantyczne Grafy procesów System zarządzania wiedzą XML RDF Szyfrowanie Pliki Bezpieczeństwo Repozytorium Forum dyskusyjne Zarządzanie wersjami Podpis elektroniczny Kontrola dostępu Współpraca Inżynieria wiedzy Autentyfikacja HSM SZBD Zarządzanie procesami pracy Wymiana komunikatów Internet Intranet

37. Wstępna architektura prototypu ICONS Mapa wiedzy Definicja reguł wnioskowania Strona XML/ DHTML Definicja modelu treści (DTD, RDF) Poziom prezentacji wiedzy HTTP/ WebDav Serwer Odwzorowanie obiektów informacyjnych (XSL, SVG) Odwzorowanie struktury treści Odwzorowanie regyuł wnioskowania Silnik inferencyjny dyzjunktywnego Datalogu Rama zarządzania wiedzą Baza treści (XML) Baza ontologii (RDF) Poziom manipulacji wiedzą Ekstrakcja i asocjacja wiedzy Zarządca hierarchicznej pamięci (Hierarchical Storage Manager, HSM) Wielo-formatowy mechanizm odwzorowania informacji Poziom integracji Istniejące heterogeniczne bazy danych Systemy spadkowe Źródła informacji na WWW

38. Inna wizja architektury projektu ICONS • Przedstawiona poprzednio architektura wydaje się zbyt eklektyczna i odzwierciedla bardziej stan obecnego chaosu w zakresie CMS niż docelową architekturę o logicznych i konsekwentnych założeniach. API oparte na obiektowym języku zapytań a la SQL Peryferia systemu Peryferia systemu Repozytorium aktywnej obiektowej bazy danych z dynamicznymi rolami obiektów Relacyjne bazy danych i inne spadkowe technologie XML, RDF i inne technologie Web Repozytorium metadanych zintegrowane z zarządzaniem konfiguracją

39. Architektura oparta na XML Przeglądarka WWW Przeglądarka WWW Dokumenty XML na Webie Inne dokumenty na Webie: HTML Word,... Dokumenty XML na Webie Inne dokumenty na Webie: HTML Word,... Narzędzia wspomagające XML : system autorski, itd. Warstwa klienta XML XML Serwer Web Serwer aplikacji Logiczna warstwa pośrednia Interakcja z aplikacjami poprzez protokoły oparte na XML Baza danych w XML (strukturalizowana) Serwer integrujący XML, serwer zapytań, serwer hurtowni danych XML XML XML XML Translatory formatów z/do XML, pomosty Zasoby danych Obiektowo-relacyjna baza danych wspomagająca XML Obiektowa baza danych wspomagająca XML Zasoby danych pod OLE/DB

40. Architektura z modelem kanonicznym HTML Program aplikacyjny Użytkownik API graficzne parametryzacja Moduł GUI język zapytań Procesor języka zapytań dla modelu kanonicznego API komunikacyjne Osłona dla bazy danych 1 Osłona dla XML/RDF inna osłona XML/RDF API inne API API 1 BD 1 pliki XML/RDF inna BD/plik

41. Projektowanie Portalu Biznesowego

42. Tak może wyglądać portal....Ale co dzieje się zanim on powstanie?

43. Definicja projektu portalu • Projekt portalu powinien być dobrze zdefiniowany zanim przystąpimy do jego realizacji. • Definicja projektu obejmuje • Analizę strategicznych uwarunkowań portalu w misji danej organizacji; • Nakłady niezbędne dla realizacji, wdrożenia i utrzymania portalu; • Realistyczny harmonogram realizacji i wdrożenia portalu; • Założenia odnośnie zawartości treściowej portalu; • Założenia odnośnie usług dostarczanych przez portal • Założenia odnośnie transakcji biznesowych realizowanych przez portal • Cel portalu z punktu widzenia biznesu, który będzie realizował; • Podstawowe, strategiczne wymagania w stosunku do portalu • Model biznesowy (biznes plan) zwrotu nakładów na stworzenie i utrzymanie portalu; • Analizę zagrożeń podczas realizacji i funkcjonowania portalu.

44. Studium osiągalności (1) • Rozmiar projektu (w punktach funkcyjnych) w stosunku do rozmiaru zespołu projektowego, realizacyjnego i wdrożeniowego. • Dostępność podstawowych zasobów (budżet, ludzie, osobomiesiące) • Ograniczenia czasowe (dostępność czasu, w przekroju poszczególnych zadań i etapów projektu). • Warunki wstępne niezbędne do realizacji projektu (aktywności lub inwestycje, które muszą być wykonane przed przystąpieniem do realizacji projektu). • Dostępność sprzętu i sieci do realizacji projektu i do działania portalu. • Dostępność oprogramowania na którym będzie zrealizowany i na którym będzie działał portal, dostępność narzędzi rozwoju oprogramowania (narzędzi CASE).

45. Studium osiągalności (2) • Dostępność infrastruktury organizacyjnej i technicznej niezbędnej dla realizacji projektu (obsługa administracyjna, kadrowa, księgowa, zaopatrzeniowa, magazynowa, marketingowa, itd.) • Dostępność infrastruktury organizacyjnej i technicznej niezbędnej dla funkcjonowania portalu; realistyczna ocena możliwości stworzenia takiej infrastruktury o ile ona nie istnieje. • Dostępność technologii i know-how. • Dostępność specjalistów wewnątrz organizacji tworzącej portal oraz zewnętrznych ekspertów (np. specjalistów grafików, programistów, stylistów, redaktorów, doradców, itd.) • Dostępność zewnętrznych usług (outsourcing), kooperantów i dostawców.

46. Zarządzanie ryzykiem • Na ryzyko projektu składają się wszystkie okoliczności, które mogą: • Spowodować opóźnienie realizacji portalu, • Zwiększenie kosztów tej realizacji, • Nie spełnienie oczekiwań klientów. • Wszystkie projekty są obarczone ryzykiem. • Zarządzanie ryzykiem polega na: • Zredukowaniu prawdopodobieństwa wystąpienia okoliczności zagrożeń, • Zminimalizowaniu skutków zagrożeń, które wystąpiły. • Aktywności niezbędne dla uniknięcia ryzyka: • Ciągłe śledzenie okoliczności, które mogą stać się zagrożeniami projektu, • Poprawianie planu celem zminimalizowania prawdopodobieństwa zagrożenia, • Określenie planu awaryjnego na wypadek okoliczności zagrożenia, • Wdrożenie planu w wypadku wystąpienia okoliczności zagrażającej. • Zarządzanie ryzykiem nigdy nie powinno zaczynać się od optymistycznego założenia „wszystko pójdzie dobrze” („jakoś to będzie”), ale raczej od pytania „co najprawdopodobniej może pójść źle?”. Nie jest to pesymizm, ale realizm.

47. Czynniki ryzyka (1) • Czynniki doświadczenia • brak doświadczenia i/lub kwalifikacji kierownika projektu (niedoświadczony kierownik jest poważnym zagrożeniem dla projektu), • brak doświadczenia i/lub kwalifikacji personelu (personel powinien być sprawdzony pod względem kwalifikacji) • niedojrzałość dostawców (brak sukcesów w rozwijaniu podobnych projektów, brak standardów, brak certyfikatu ISO 9000, ...). • Czynniki planowania • niedokładność metod szacowania czasu, kosztów, zasobów, • zbyt krótka skala czasowa (niemożliwość zrównoleglenia pewnych prac), • zbyt długa skala czasowa (zmiany wymagań, personelu, technologii), • zależność od awarii losowych, wandalizmu i sabotażu (zniszczenie sprzętu, zniszczenie danych, itd.), • zła lokalizacja personelu (utrudnienia w komunikacji), • zła definicja odpowiedzialności (brak odpowiedzialnych za kluczowe zadania, wykonywanie niepotrzebnych lub drugorzędnych zadań, ...), • częste zmiany personelu.

48. Czynniki ryzyka (2) • Czynniki technologiczne • nowość technologiczna (brak doświadczeń, konieczność dodatkowego wysiłku na rozpoznanie, ...), • niedojrzałość lub nieodpowiedniość stosowanych metod (nowe metody są często niesprawdzone, konieczne jest praktyczne doświadczenie, ...), • niedojrzałość lub nieodpowiedniość narzędzi (personel powinien umieć je używać, mogą być nieodpowiednie w stosunku do metod, są zmieniane w trakcie projektu, ...), • niska jakość użytego komercyjnego oprogramowania (może być zawodne, słabo pielęgnowalne, niebezpieczne, nie stabilne, ...), • Czynniki zewnętrzne • niska jakość lub niestabilność wymagań użytkownika, • słabo zdefiniowane, niestabilne lub niestandardowe interfejsy zewnętrzne, • niska jakość lub słaba dostępność systemów zewnętrznych (od których zależy powodzenie projektu; może być konieczne rozwijanie możliwości symulujących systemy zewnętrzne).

49. Opis i charakterystyki ryzyka (1) • Opis: krótki opis wyjaśniający charakter ryzyka • Prawdopodobieństwo subiektywne wystąpienia ryzyka (małe, średnie, duże, lub w przedziale 0..1). • Wpływ ryzyka na projekt: (mały, średni, duży, lub w przedziale 0..1). • Mitygacja (łagodzenie ryzyka): opis metod, akcji, reguł, zarządzeń, zapisów w kontrakcie które mają na celu zminimalizowanie prawdopodobieństwa wystąpienia ryzyka. • Akcje ratunkowe: zminimalizowanie negatywnych skutków ryzyka.

50. Opis i charakterystyki ryzyka (2) • Data decyzji: data kiedy podane wyżej informacje zostały wprowadzone lub zmodyfikowane (dla ewentualnej identyfikacji spraw nieaktualnych). • Odpowiedzialność: osoba personalnie odpowiedzialna za monitorowanie ryzyka, jego mitygację oraz uruchomienie akcji ratunkowych. • Oczekiwane zwiększenie kosztów projektu w razie wystąpienia ryzyka. • Oczekiwane zwiększenie czasu projektu w razie wystąpienia ryzyka. • Oczekiwane straty cech produktu w razie wystąpienia ryzyka: brak funkcji, osłabienie wymagań niefunkcjonalnych, obniżenie jakości.