Tworzenie Portali Biznesowych

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

2. 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żą.

3. 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.

4. 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.

5. 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.

6. 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

7. 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

8. 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ą

9. 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

10. 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

11. Projektowanie Portalu Biznesowego ost 9.X

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

13. 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.

14. 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).

15. 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.

16. 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.

17. 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.

18. 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).