Dokumenty w Krajowym Systemie e‑Faktur i nie tylko te dokumenty

Wstęp

Tym razem opi­su­ję kwe­stie doku­men­tu, doku­men­to­wej posta­ci czyn­no­ści praw­nej i fak­tur w wer­sji elek­tro­nicz­nej, któ­rych wysta­wia­nie jest jak naj­bar­dziej czyn­no­ścią praw­ną, i o inno­wa­cji jaką Minister Finansów ser­wu­je nam od nowe­go roku. 

W 2018 roku opi­sy­wa­łem meto­dy uwia­ry­god­nia­nia tre­ści (doku­men­tów) podsumowując: 

Tego typu meto­dy zabez­pie­cze­nia (tak zwa­ne sys­te­mo­we, w prze­ci­wień­stwie do tech­nicz­nych, jaką jest kwa­li­fi­ko­wa­ny pod­pis elek­tro­nicz­ny), są opar­te na zało­że­niu, że sfał­szo­wa­nie tre­ści doku­men­tu jest nie­moż­li­we (lub jest wykry­wal­ne w 100%) przy zacho­wa­niu usta­lo­nej pro­ce­du­ry dorę­cze­nia doku­men­tu (patrz: Zasada Kerckhoffs?a). Wymagania nakła­da­ne for­mal­nie na pod­miot sta­no­wią­cy Trzecią stro­nę zaufa­nia (nota­riusz) powo­du­ją, że ryzy­ko nie­wy­kry­cia fał­szer­stwa jest bli­skie zeru. Opisane powy­żej meto­dy wymia­ny doku­men­tów nie wyma­ga­ją kosz­tow­ne­go i trud­ne­go w uży­ciu kwa­li­fi­ko­wa­ne­go pod­pi­su elek­tro­nicz­ne­go (źr.: Przesyłki sądo­we dostar­cza­ne przez inter­net czy­li e‑dokumenty c.d.)

Generalnie cho­dzi­ło o alter­na­ty­wę dla e‑podpisu, któ­ry nadal uwa­żam za śle­pą ulicz­kę. Od wie­lu lat, pro­jek­tu­jąc sys­te­my infor­ma­tycz­ne, sto­su­ją zasa­dę mówią­cą. że sys­tem infor­ma­tycz­ny, jako roz­wią­za­nie, nie powi­nien two­rzyć nowych, sztucz­nych bytów infor­ma­cyj­nych, bo im wię­cej takich sztucz­nych (nie ist­nie­ją­cych w rze­czy­wi­sto­ści) bytów powsta­nie, tym bar­dziej sys­tem odsta­je od realiów rze­czy­wi­sto­ści, któ­rą (podob­no) ma wspie­rać. Praktyka poka­zu­je, że pró­by imple­men­ta­cji w sys­te­mach infor­ma­cyj­nych mecha­ni­zmów dale­kich od realiów życia, koń­czy się ogrom­nym kosz­tem i czę­sto po pro­stu porażką. 

Warto mieć świa­do­mość, że struk­tu­ral­ne i sta­łe w cza­sie dane, sta­no­wią mniej niż 20% pro­cent wszyst­kich danych jakie czło­wiek two­rzy, pró­by sto­so­wa­nia mode­lu rela­cyj­ne­go i SQL do pozo­sta­łych ponad 80% danych (doku­men­tów) to dro­ga do klęski. 

On top of this, the­re is sim­ply much more unstruc­tu­red data than struc­tu­red. Unstructured data makes up 80% and more of enter­pri­se data, and is gro­wing at the rate of 55% and 65% per year. (źr.: Structured vs Unstructured Data 101: Top Guide | Datamation)

Czytaj dalej… Dokumenty w Krajowym Systemie e‑Faktur i nie tyl­ko te doku­men­ty”

Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten arty­kuł to uzu­peł­nie­nie opi­su: Dokument jako wyma­ga­nie.

Często jestem i ja pyta­ny o to Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?” Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. Zauważyli to tak­że inni:

A Mock-up is a sli­gh­tly glo­ri­fied pic­tu­re, so you will be answe­ring with at least 1001 words ! 

Bardzo czę­sto widu­ję wyma­ga­nia spi­sy­wa­ne jako tak zwa­na lista funk­cji lub funk­cjo­nal­no­ści. Pojęcia te mają takie defi­ni­cje w języ­ku polskim: 

funk­cja ?zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz?, ?moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez urzą­dze­nie lub pro­gram komputerowy?

Funkcjonalność jest defi­nio­wa­na jako funk­cja cze­goś w jakimś systemie. 

Czytaj dalej… Struktury for­mu­la­rzy jako for­ma wyra­ża­nia wyma­gań”

IEEE830-1998 ? czy produkuje dobre wymagania?

Często moż­na spo­tkać opi­sy wyma­gań w posta­ci tek­stu opi­su­ją­ce­go ?wyma­ga­nia funk­cjo­nal­ne? i ?jakieś inne? np. wydaj­no­ścio­we, sys­te­mo­we itp. Nie raz są to doku­men­ty opar­te na zale­ce­niach opi­sa­nych w doku­men­cie IEEE 830‑1998, któ­ry opi­su­je doku­men­to­wa­nie wyma­gań. Czy zale­ce­nia te są roz­wią­za­niem pro­ble­mu złych spe­cy­fi­ka­cji? Tylko troszkę.

Co znaj­dzie­my w tych zale­ce­niach? Otóż zapi­sa­no tam, że spe­cy­fi­ka­cja powin­na być:

  • Poprawna: nie może być np. nie­zgod­na z prawem
  • Jednoznaczna: o tym za moment
  • Kompletna: o tym za moment
  • Spójna: brak kon­flik­tów logicz­nych ale o tym tak­że za moment
  • Uporządkowana wg ważności/stabilności: np. meto­dą tria­ge czy­li każ­de wyma­ga­nie ma jeden z trzech atry­bu­tów ? musi być, powin­no być, mogło by być (inna wer­sja to waga wyma­ga­nia dla całe­go pro­jek­tu: duża śred­nia, mała)
  • Weryfikowalna: moż­na jed­no­znacz­nie stwier­dzić, że wyma­ga­nie zosta­ło zrealizowane
  • Modyfikowalna: to doty­czy struk­tu­ry doku­men­tu i narzę­dzia jakim powstał doku­ment wymagań
  • Umożliwiająca śle­dze­nie powią­zań: doty­czy struk­tu­ry doku­men­tu jak i jego for­ma­tu (doku­men­ta­cja html będzie lep­sza od doku­men­ta­cji tek­sto­wej do prze­glą­da­nia ale nie do druku).

A teraz ?ten moment?. Jednoznaczność, cóż to jest? Podczas pisa­nia spe­cy­fi­ka­cji wyma­gań za pomo­cą języ­ka natu­ral­ne­go, nigdy nie osią­gnie­my peł­nej jed­no­znacz­no­ści. Jedynie zapis wyma­gań za pomo­cą metod for­mal­nych pozwa­la w peł­ni unik­nąć wieloznaczności.

Dla sto­sun­ko­wo nie­du­żych pro­jek­tów poziom nie­jed­no­znacz­no­ści osią­ga­ny pod­czas pisa­nia wyma­gań języ­kiem natu­ral­nym jest wystar­cza­ją­cy. Jednak do ?poważ­niej­szych? zasto­so­wań (np. duże sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie np. CRM czy w szcze­gól­no­ści sys­te­my kry­tycz­ne) nale­ży spe­cy­fi­ko­wać wyma­ga­nia za pomo­cą metod for­mal­nych lub tak zwa­nych quasi-for­mal­nych. Metody for­mal­ne to mate­ma­tycz­ne zapi­sy, o któ­rych tu nie będzie­my pisać gdyż są rzad­ko sto­so­wa­ne z uwa­gi koszty.

Metody quasi-for­mal­ne to meto­dy zorien­to­wa­ne na mode­le. Modele moż­na prak­tycz­nie uznać za jed­no­znacz­ne choć obec­nie nie ma narzę­dzi to auto­ma­tycz­ne­go spraw­dza­nia ich jako­ści (są dla metod for­mal­nych). Poprawny model jed­nak wyko­na­ny jest za pomo­cą popraw­nej nota­cji a tu moż­na wery­fi­ko­wać auto­ma­tycz­nie jej gra­ma­ty­kę i słow­ni­ki (syn­tak­ty­kę i semantykę).

A jak odpo­wie­dzieć na pyta­nia: Czy wyma­ga­nia są kom­plet­ne (czy cze­goś nie pomi­nę­li­śmy)? Czy są logicz­nie spój­ne (może ich być kil­ka­dzie­siąt, kil­ka­set i wię­cej)? Czy wyma­ga­nia nie są redun­dant­ne (czy nie opi­su­ją tych samych zacho­wań róż­nym językiem)?

Na moment zmia­na dzie­dzi­ny. Wyobraźmy sobie, że mamy pro­jekt pole­ga­ją­cy na poma­lo­wa­niu ele­wa­cji domów w pew­nym mie­ście. Z ana­li­zy ren­tow­no­ści wyni­ka, że moż­li­we jest poma­lo­wa­nie tyl­ko domów mają­cych nie wię­cej niż czte­ry kon­dy­gna­cje. Potrzebny jest doku­ment z listą tych budyn­ków i ich adre­sów. Jaki doku­ment otrzy­ma­my jeże­li wyko­na­my go na bazie wywia­dów z pew­nym odset­kiem miesz­kań­ców tego mia­sta? A teraz dru­gie pyta­nie: czy doku­ment, któ­ry powsta­nie na pod­sta­wie mapy mia­sta z dany­mi o wszyst­kich budyn­kach będzie lepszy?

Dlatego moim zda­niem zale­ce­nie IEEE830-1998 jest bar­dzo dobrym spi­sem tre­ści doku­men­tu wyma­gań wraz z komen­ta­rza­mi ale abso­lut­nie nie opi­su­je jak taki, wyso­kiej jako­ści doku­ment stwo­rzyć (nie licząc spi­su tre­ści). Tu kła­nia się meto­dy­ka pozy­ski­wa­nia wyma­gań oraz spo­sób ich specyfikowania.

Pozyskiwanie wymagań

Podobnie jak w przy­pad­ku opi­sa­nej powy­żej listy budyn­ków kom­plet­ne i spój­ne wyma­ga­nia naj­ła­twiej zro­bić na bazie mode­lu orga­ni­za­cji, fir­my itp.. Zwracam uwa­gę, że plan mia­sta to nic inne­go jak jego model z per­spek­ty­wy topo­lo­gii. Należy więc naj­pierw wyko­nać model orga­ni­za­cji, a jest nim tu model pro­ce­sów biz­ne­so­wych. Na tym mode­lu (podob­nie jak budyn­ki na pla­nie) zazna­cza­my czyn­no­ści zakwa­li­fi­ko­wa­ne do zakre­su pro­jek­tu. Czynności te sta­ną się przy­pad­ka­mi uży­cia opro­gra­mo­wa­nia. Każdy taki przy­pa­dek ma auto­ma­tycz­nie swój kon­tekst (miej­sce na mapie pro­ce­sów) i akto­ra (rola na napie pro­ce­sów), wystar­czy opi­sać jego sce­na­riusz i zbu­do­wać pro­to­typ ekra­nu lub doku­men­tu. Lista taka wyko­na­na na bazie mode­lu pro­ce­sów z zasa­dy jest spój­na i kompletna.

Paradoksalnie wyko­na­nie takie­go mode­lu jest tu naj­więk­szą trud­no­ścią. Dlaczego? Tworząc go nale­ży bez­względ­nie pano­wać na jego zło­żo­no­ścią, pano­wać nad subiek­ty­wi­zmem osób z któ­ry­mi pro­wa­dzi­my wywia­dy, rozu­mieć stra­te­gię mode­lo­wa­nej fir­my i jej model biz­ne­so­wy, wie­le innych. Identyfikacja pro­ce­sów sama w sobie jest trud­na, wyma­ga posia­da­nia metod ich iden­ty­fi­ka­cji i wery­fi­ka­cji popraw­no­ści samej ana­li­zy i mode­lu, to jed­nak temat na książ­kę a nie na taki artykuł.

Wymagania pozafunkcjonalne i interfejsy

Tu poja­wia się pierw­szy roz­dź­więk pomię­dzy meto­dy­ką, któ­rą np. ja sto­su­ję (nie ja jeden!) a zale­ce­nia­mi IEEE. Otóż takie cechy jak wydaj­ność, nie­za­wod­ność czy bez­pie­czeń­stwo w kate­go­riach meto­dy­ki, któ­rą sto­su­ję sta­no­wią ogra­ni­cze­nia nakła­da­ne na funk­cjo­nal­no­ści. Jeżeli np. chce­my powie­dzieć, że raport X musi się wyko­ny­wać w cza­sie nie dłuż­szym niż N sekund to jest to nic inne­go jak ogra­ni­cze­nie nało­żo­ne na przy­pa­dek uży­cia Tworzenie rapor­tu X czyż nie? Podobnie nie­za­wod­ność np. dostęp­ność czyn­no­ści zwią­za­nych z two­rze­niem rapor­tów finan­so­wych nie może zejść poni­żej 99,99% cza­su w ska­li roku. I tak dalej?

Interfejsy to tak­że nic inne­go jak przy­pad­ki uży­cia. Np. sys­tem musi udo­stęp­niać dane maga­zy­no­we w posta­ci XML dla każ­de­go upraw­nio­ne­go zewnętrz­ne­go sys­te­mu (jest nawet aktor: zewnętrz­ny sys­tem). Przypadkiem uży­cia jest tu przy­pa­dek żąda­nia tych danych przez zewnętrz­ny sys­tem. Przykłady moż­na mno­żyć. Dzięki takie­mu podej­ściu uni­ka­my np. wyma­gań w rodza­ju: sys­tem ma być dostęp­ny co naj­mniej 99,99% cza­su w ska­li roku bo tą meto­dą wszyst­kie funk­cjo­nal­no­ści, nawet mało istot­ne, zrów­nu­je­my w górę czy­li po pro­stu pod­no­si­my kosz­ty sys­te­mu wła­ści­wie bez uzasadnienia.

A gdzie przetwarzane dane?

Powyższe zale­ce­nia nie wyma­ga­ją wyspe­cy­fi­ko­wa­nia mode­lu danych, pod­sta­wo­wej infor­ma­cji. Oczekiwanie, że model danych zapro­jek­tu­ją dopie­ro pro­gra­mi­ści to ocze­ki­wa­nie od ludzi nie zna­ją­cych zama­wia­ją­ce­go, że opi­szą jego biznes.

Tyle na dzisiaj, ale na zakończenie.

Nie jest to kry­ty­ka zale­ceń IEEE830-1998 a zwró­ce­nie uwa­gi na to, że same one nie sta­no­wią lekar­stwa podob­nie jak sam tytuł i spis tre­ści powie­ści nie czy­ni jesz­cze z pisa­rza kan­dy­da­ta do nagro­dy Pen Clubu.

Co piszą inni?

Powołam się tu na zawar­tość książ­ki Iana Sommervill?a ?Inżynieria opro­gra­mo­wa­nia?. Wymagania dzie­li­my na:

  1. Funkcjonalne czy­li jakie usłu­gi ma ofe­ro­wać system
  2. Niefunkcjonalne to ogra­ni­cze­nia usług i funk­cji systemu
  3. Dziedzinowe, któ­re pocho­dzą z dzie­dzi­ny zasto­so­wa­nia systemu

?Standard IEEE nie jest ide­al­ny, zawie­ra jed­nak bar­dzo wie­le cen­nych rad, jak pisać wyma­ga­nia i uni­kać pro­ble­mów. Jest zbyt ogól­ny, aby sam mógł być stan­dar­dem fir­mo­wym? (Ian Sommerville ? Inżynieria opro­gra­mo­wa­nia, WNT Warszawa 2003).

Metodyka, którą stosuję

  1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia systemu 
    1. Przypadki uży­cia sys­te­mu to czyn­no­ści wyse­lek­cjo­no­wa­ne z mode­lu pro­ce­sów na bazie zakre­su projektu.
  2. Wymagania nie­funk­cjo­nal­ne to ogra­ni­cze­nia nakła­da­ne na poszcze­gól­ne przy­pad­ki uży­cia (mogą być gru­po­wa­ne np. mak­sy­mal­ny czas odpo­wie­dzi sys­te­mu nie może prze­kro­czyć 1 s. z wyjąt­kiem rapor­tów, gdzie mak­sy­mal­ny czas odpo­wie­dzi to 1 minuta)
  3. Wymagania dzie­dzi­no­we opi­sy­wa­ne są mode­lem dzie­dzi­ny sys­te­mu (dia­gram klas lub ERD)

c.d. kie­dyś nastąpi…

Co tam Panie w Software czyli mały przegląd prasy

Wakacje spo­wo­do­wa­ły u mnie mały zator pra­sy dla­te­go posta­no­wi­łem napi­sać kil­ka słów o tym co w całej kup­ce a nie o tym co poje­dyn­czym nume­rze. Od pew­ne­go cza­su jestem czy­tel­ni­kiem mie­sięcz­ni­ka Software Developer’s Journal (SDJ). Co praw­da jestem ana­li­ty­kiem a nie np. kode­rem ale w koń­cu nie­któ­re pro­jek­ty i UML’owe obraz­ki piszę dla kode­rów wła­śnie a dobrze jest znać swo­je­go klien­ta” i jego potrze­by. A co znaj­dzie­my w nume­rach z Czerwca, Lipca i Sierpnia? Kilka ciekawostek

AJAX

Co to jest AJAX, sko­ro nie jest to tyl­ko klub pił­kar­ski? AJAX (ang. Asynchronous JavaScript and XML, Asynchroniczny JavaScript i XML) ? tech­ni­ka pro­jek­to­wa­nia apli­ka­cji inter­ne­to­wych, w któ­rej inte­rak­cja użyt­kow­ni­ka z ser­we­rem odby­wa się bez prze­ła­do­wy­wa­nia całe­go doku­men­tu. (źr. WIKI). Łatwo to zauwa­żyć korzy­sta­jąc np. z nie­któ­rych apli­ka­cji dostęp­nych w Google takich jak choć­by Kalendarz. Nie będę się roz­pi­sy­wał o szcze­gó­łach bo nie taki mam cel, rzecz w tym, że tech­no­lo­gia ta uwal­nia nas od nie­któ­rych wad apli­ka­cji two­rzo­nych dla WWW a mia­no­wi­cie tego, że HTTP to pro­to­kół bez­po­łą­cze­nio­wy. Efektem tego jest uciąż­li­we nie­jed­no­krot­nie wyma­ga­ne każ­do­ra­zo­we prze­ła­do­wa­nie stro­ny WWW jeże­li pra­cu­je­my z inte­rak­tyw­na zawar­to­ścią i for­mu­la­rza­mi: po wypeł­nie­niu for­mu­la­rza nale­ży prze­ła­do­wać stro­ny by obej­rzeć skut­ki (np. spo­ty­ka­na powszech­nie na stro­nach książ­ka gości wyma­ga prze­ła­do­wa­nia w celu obej­rze­nia wła­sne­go do niej wpi­su). Użycie AJAX zbli­ża nas do kom­for­tu pra­cy z apli­ka­cja­mi webo­wy­mi bli­skie­mu pra­cy z apli­ka­cja­mi lokal­ny­mi. Tyle o moż­li­wo­ściach, zain­te­re­so­wa­nych odsy­łam do nume­ru. Warto tu zazna­czyć, że Microsoft przy­stą­pił do gru­py OpenAJAX zrze­sza­ją­cej fir­my pro­pa­gu­ją­ce ten standard.

Obiektowe dane w relacyjnej bazie

Pewnie nie napi­sze nic nowe­go jeśli stwier­dzę, że tech­no­lo­gia obiek­to­wa rośnie w siłę. Jednak kto zaj­mu­je się ana­li­zą obiek­to­wą, pro­jek­to­wa­niem obiek­to­wym i pro­gra­mo­wa­nie pew­nie nie raz wal­czył” z pro­ble­mem danych. Naturalnym spo­so­bem zapi­su danych była by tu obiek­to­wa baza danych (motor bazy) jed­nak jak wie­my na ryn­ku domi­nu­ją nadal bazy rela­cyj­ne. Mapowanie ORM (Object Relational Mapping) to dość trud­ne zaję­cie, two­rze­nie dodat­ko­wych klas odpo­wia­da­ją­cych za zarzą­dza­nie dany­mi w bazach rela­cyj­nych jest dość żmud­nym zaję­ciem. Dlatego war­to się zapo­znać z taki­mi narzę­dzia­mi jak iBATIS czy jego kon­ku­ren­tem Hibernate. Są to spe­cja­li­zo­wa­ne pro­gra­my pośred­ni­czą­ce pomię­dzy obiek­to­wą apli­ka­cją a rela­cyj­na bazą danych. Upraszczają pro­jek­to­wa­nie i two­rze­nie obiek­to­wych sys­te­mów korzy­sta­ją­cych z baz relacyjnych.

UML ‑standaryzacja notacji

UML to nie tyl­ko nota­cja i gra­ficz­ny język mode­lo­wa­nia. To moim zda­niem przede wszyst­kim narzę­dzie komu­ni­ka­cji. Pojawił sie już UML v.2.1 więc war­to go poznać. Notacja sta­no­wi małe wyzwa­nie, jed­nak po pierw­sze poma­ga po dru­gie jak ktoś już posiadł meto­dy obiek­to­we w ana­li­zie i pro­jek­to­wa­niu to peł­ny UML będzie dla nie­go uzu­peł­nie­niem tego co już wie. Tak więc zarów­no ana­li­ty­kom jak i pro­gra­mi­stom pole­cam. Dlaczego? Bo kość nie­zgo­dy jaką są wyma­ga­nia i spo­so­by ich doku­men­to­wa­nia nie­mal­że zni­ka gdy wyma­ga­nia te są opi­sa­ne za pomo­cą cze­goś co jest jed­no­znacz­ne i zro­zu­mia­łe dla wyko­naw­cy (chy­ba nie ma nic bar­dziej mylą­ce­go niż wyma­ga­nia na sys­tem opi­sa­ne prozą).

Open Office 2.2 PL

Zupełnym przy­pad­kiem sta­łem się użyt­kow­ni­kiem OpenOffice 2.2. Mała awa­ria” moje­go note­bo­oka i potrze­ba rein­sta­la­cji całe­go opro­gra­mo­wa­nia przy­po­mnia­ła mi, że posia­da­na licen­cja na MS Office to tak na praw­dę legal­na licen­cja ale otrzy­ma­na od ostat­nie­go zatrud­nia­ją­ce­go mnie pod­mio­tu do pro­jek­tu. Projekt się skoń­czył i moja pro­jek­to­wa” insta­la­cja tak­że wła­ści­wie stra­ci­ła racje bytu. A tu napa­to­czy­ła mi się wie­dza” o nowej wer­sji pakie­tu 2.2 w Lipcowym nume­rze SDJ. Pomyślałem, chcę mieć legal­nie wiec spraw­dzę co to za zwie­rze ten OpenOffice. Nie będę się roz­pi­sy­wał o tym czym jest OpenOffice, to moż­na same­mu spraw­dzić. Na pew­no nie­któ­re nawy­ki po MS są jed­nak do zmia­ny jed­nak co inne­go mnie wręcz urze­kło cze­go nawet nie podej­rze­wa­łem: OpenOffice z nikim nie kon­ku­ru­je dla­te­go zawie­ra wbu­do­wa­ne np. eks­port do PDF, flash i wie­le innych dro­bia­zgów uła­twia­ją­cych życie, któ­re mając MS Office musia­łem doin­sta­lo­wy­wać pobie­ra­jac z sie­ci dodat­ki w posta­ci róż­ne­go rodza­ju freeware’ów.

UML – Przypadki Użycia

Lipcowy numer SDJ zawie­ra cie­ka­wy arty­kuł o Przypadkach Użycia czy­li meto­dzie zapi­su powszech­nie uży­wa­nej do doku­men­to­wa­nia wyma­gań funk­cjo­nal­nych. Artykuł inte­re­su­ją­cy bo w cie­ka­wy i jasny spo­sób opi­su­je sto­so­wa­nie ten meto­dy jed­nak moim zda­niem minu­sem jest umiesz­cze­nie w pod­su­mo­wa­niu stwier­dze­nia, że przy­pad­ki uży­cia są pod­sta­wo­wym ele­men­tem współ­cze­snych meto­dyk wytwa­rza­nia opro­gra­mo­wa­nia”. Zdania na ten tema są podzie­lo­ne, coraz czę­ściej jed­nak spo­ty­kam się z tezą, że przy­pad­ki uży­cia są dobrym spo­so­bem na udo­ku­men­to­wa­nie wyni­ków ana­liz pro­ce­sów biz­ne­so­wych. Zastosowanie tyl­ko przy­pad­ków uży­cia jako meto­dy kolek­cjo­no­wa­nia wyma­gań rodzi poważ­ne ryzy­ko pomi­nię­cia istot­nych rze­czy gdyż wszel­kie meto­dy ankie­to­we mają tę wadę, że otrzy­ma­my tyl­ko odpo­wie­dzi na zada­ne pyta­nia. Jeżeli nie mamy innej meto­dy sko­re­lo­wa­nia zebra­nych tak infor­ma­cji z fak­tycz­ną orga­ni­za­cją fir­my bar­dzo łatwo może­my pomi­nąć istot­ne wyma­ga­nia, któ­re dla przy­szłych użyt­kow­ni­ków są tak oczy­wi­ste, ze nie raczy­li o nich wspomnieć.

Zarządzanie ryzykiem

Polecam arty­kuł na ten temat z nume­ry sierp­nio­we­go SDJ. Temat powszech­nie nie lubia­ny, trak­to­wa­ny po maco­sze­mu. opi­su­je w zro­zu­mia­ły spo­sób jak zarzą­dzać ryzy­kiem zgod­nie z nor­ma ISO 27001:2005. Poprawnie prze­pro­wa­dzo­na ana­li­za ryzy­ka daje infor­ma­cje o tym: co nale­ży chro­nić, jakie zagro­że­nia mogą wystą­pić, jaką szko­dę mogą wyrzą­dzić. Tak więc zasta­na­wia­jąc się jakie roz­wią­za­nie wdro­żyć mamy klu­czo­wa infor­ma­cję w sfe­rze wyma­gań: budżet czy­li jaki kosz­tem ma sens ochro­na, a pro­giem ren­tow­no­ści do obli­czeń jest wła­śnie infor­ma­cja jaka szko­dę i z jakim praw­do­po­do­bień­stwem mogą wyrzą­dzić ziden­ty­fi­ko­wa­ne czyn­ni­ki ryzyka.

UML – statyczne aspekty modelowania

Ten obszar to pole dla dwóch ról” w pro­jek­cie. Analityka i archi­tek­ta sys­te­mu. Diagram klas to pra­ca dla ana­li­ty­ka, dia­gra­my kom­po­nen­tów to robo­ta dla oso­by pla­nu­ją­cej fizycz­na imple­men­ta­cje sys­te­mu zaś dia­gram wdro­że­nia pole­cam jed­nym i dru­gim. Analityk ma narzę­dzie do udo­ku­men­to­wa­nia śro­do­wi­ska wdro­że­nia a archi­tekt do doku­men­to­wa­nia jego dal­sze­go roz­wi­ja­nia pod kątem budo­wa­ne­go sys­te­mu. Diagram wdro­że­nia sta­no­wi tak­że dosko­na­ła meto­dę jed­no­znacz­ne­go doku­men­to­wa­nia posta­ci przy­szłe­go sys­te­mu co nie raz sta­no­wi potem ostat­nia deskę ratun­ku pod­czas oda­wa­nia goto­we­go sys­te­mu klientowi.

eZ Publish

To nazwa sys­te­mu CMS (ang. Content Management System, System Zarządzania Treścią) do budo­wy ser­wi­sów WWW. eZ Publish to tak­że tytuł dodat­ku SDJ Extra zawie­ra­ją­ce­go wyczer­pu­ją­cy opis uży­cia tego CMS’a wraz z CD zawie­ra­ją­cym kod CMS’a i narzę­dzi uła­twia­ją­cych jego insta­la­cje i roz­bu­do­wę. Sa tam więc śro­do­wi­sko pro­gra­mi­stycz­ne mię­dzy inny­mi dla PHP Eclipse 3.2.2 jak i edHTML 5.02 roz­bu­do­wa­ny edy­tor HTML. Oba narzę­dzia są bezpłatne.

(na pod­sta­wie nume­rów SDJ Czerwiec, Lipiec i Sierpień 2007)

SOA: Czy to już nadchodzący koniec zintegrowanych ERP?

Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. Technologia obiek­to­wa bar­dzo ten pro­ces uła­twi­ła. Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić koszt wspar­cia poje­dyn­cze­go pro­ce­su. Z tego też powo­du rośnie zain­te­re­so­wa­nie sys­te­ma­mi typu mid­dle­wa­re. Do tej pory były wyko­rzy­sty­wa­ne rzad­ko i dużych fir­mach, głów­nie w sek­to­rze finan­so­wym, głow­nie z uwa­gi na ich koszt. Obecnie roz­wią­za­nie to sta­je się coraz popu­lar­niej­sze. Dlatego?

Pojawienie się stan­dar­dów w mode­lo­wa­niu, usta­no­wie­nie mode­lo­wa­nia peł­no­war­to­ścio­wym eta­pem pro­jek­tu (a nie eks­tra­wa­gan­cją), otwie­ra­nie się tech­no­lo­gii, poja­wia­cie się stan­dar­dów wymia­ny meta­da­nych i mode­li toru­ją dro­gę do znacz­ne­go obni­że­nia kosz­tów i uspraw­nie­nia two­rze­nia sys­te­mów opar­tych o kom­po­nen­ty. To wszyst­ko powo­du­je, że nie trze­ba jed­ne­go wiel­kie­go sys­te­mu zin­te­gro­wa­ne­go. Wystarczy tak zwa­ny motor pro­ce­sów biz­ne­so­wych i spe­cja­li­zo­wa­ne sys­te­my, mogą one pocho­dzić od róż­nych pro­du­cen­tów i pra­co­wać na róż­nych platformach.

Jedyne cze­go trze­ba prze­strze­gać to pra­ca od samej góry: model biz­ne­so­wy orga­ni­za­cji, model pro­ce­sów biz­ne­so­wych, struk­tu­ra work­flow (sce­na­riu­sze dzia­łań czy­li wewnętrz­ny opis pro­ce­sów), lista ocze­ki­wa­nych usług sys­te­mu IT i sam sys­tem skła­da­ny z kom­po­nen­tów. Tak to widzę. Te trzy ele­men­ty: model biz­ne­so­wy, model pro­ce­sów, usłu­gi IT sta­no­wią pew­ną całość. Ubranie opi­su usług w cia­ło to wła­śnie obiek­to­we tech­no­lo­gie w IT, archi­tek­tu­ra SOA i MDA, języ­ki i nota­cje BPEL, BPMN, UML, XMI, obiek­to­we języ­ki programowania.

Koniec quasimonopolu dostawców systemów

No i oka­za­ło sie, że stan­dar­dy spraw­dzo­ne same się bro­nią. Microsoft W BizTalk Server będzie sup­por­to­wał BPEL (Business Proces Execution Language, opar­ty na XML język skryp­to­wy opi­su pro­ce­sów mię­dzy inny­mi w sys­te­mach BPM i work­flow mana­ge­ment uży­wa­ny już mię­dzy inny­mi w nie­któ­rych sys­te­mach CASE). Oracle tak­że ?rozu­mie? BPEL. Modelowanie sta­je się nor­mą a otwar­tość stan­dar­dem. Notacje UML i BPMN sta­ją się stan­dar­dem modelowania.

Co to zna­czy? Moim zda­niem to, że powo­li sta­je się coś o czym pisa­łem swe­go cza­su na stro­nach IT-Consulting. Monopolistę zaczę­li doga­niać kon­ku­ren­ci. Monopolista zaczy­na czuć poko­rę: już nie wyzna­cza sam stan­dar­dów de’fac­to (np. for­ma­ty pli­ków doku­men­tów, narzę­dzia pro­gra­mi­stycz­ne, inter­fej­sy komu­ni­ka­cyj­ne). Tracąc powo­li rynek na rzecz roz­wią­zań kon­ku­ren­cji dostrzegł, że to co było prze­wa­gą ryn­ko­wą (zamknię­te roz­wią­za­nia) sta­ło się w dal­szej per­spek­ty­wie hamul­cem. Przyszła pora na otwar­tość i kon­ku­ro­wa­nie jako­ścią a nie szan­taż ponad 80% udzia­łem w ryn­ku (vide współ­pra­ca Microsoft i Novell).

Kierunki rozwoju systemów IT

Albo ana­li­za pro­ce­so­wa i obiek­to­wa albo na mar­gi­nes życia. Coraz powszech­niej­sze zro­zu­mie­nie idei zorien­to­wa­nia na pro­ce­sy, inte­ro­pe­ra­cyj­no­ści (w tym zarzą­dza­nie łań­cu­cha­mi dostaw), archi­tek­tu­ry SOA (któ­ra moim zda­niem dosko­na­le się wpa­so­wu­je w meto­dy zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy i reor­ga­ni­za­cję w fir­mach) powo­du­je sta­wia­nie takich wyma­gań tak­że dostaw­com roz­wią­zań IT. Te któ­re się do tego nie dosto­su­ją, moim zda­niem odej­dą z rynku.

Model biz­ne­so­wy fir­my, infor­ma­cje i dane jakich fir­ma wyma­ga do spraw­ne­go funk­cjo­no­wa­nia to już jeden orga­nizm. Stało się fak­tem, że żad­na fir­ma na ryn­ku już nie będzie w sta­nie kon­ku­ro­wać bez spraw­ne­go zarzą­dza­nia infor­ma­cją. Do zarzą­dza­nia infor­ma­cją i prze­twa­rza­nia danych zaś potrzeb­ne są spraw­nie dzia­ła­ją­ce i przede wszyst­kim łatwe w ich roz­wi­ja­niu sys­te­my. Warunek taki speł­nia­ją obec­nie zorien­to­wa­ne na pro­ce­sy sys­te­my two­rzo­ne w tech­no­lo­giach obiektowych.

Drugi waru­nek spraw­no­ści orga­ni­za­cji to opty­ma­li­za­cja jej wewnętrz­nej wydaj­no­ści. Tu wkra­cza­my dla odmia­ny w zarzą­dza­nie i jego pro­ce­so­wą natu­rę. Jak to pogo­dzić? Postrzegam tu wła­śnie miej­sce dla archi­tek­tu­ry SOA. Firmę i jej miej­sce w ryn­ko­wym łań­cu­chu war­to­ści moż­na, moim zda­niem, jed­no­znacz­nie opi­sać tyl­ko za pomo­cą mode­lu pro­ce­so­we­go zorien­to­wa­ne­go na pro­duk­ty. Zasoby (tu sys­tem IT) potrzeb­ne do reali­za­cji tej stra­te­gii ana­li­zu­je­my już obiektowo.

Namiastką takich opi­sów i ana­liz były pro­ce­du­ry w księ­gach jako­ści ISO. Do peł­nej ana­li­zy wyma­ga­ny jest jed­nak opis (mapa pro­ce­sów) uwzględ­nia­ją­cy cały obraz fir­my. SOA to archi­tek­tu­ra wska­zu­ją­ca natu­ral­ny pro­ces pro­jek­to­wa­nia sys­te­mów IT: model pro­ce­so­wy fir­my (orga­ni­za­cji), ana­li­za pro­ce­sów z per­spek­ty­wy zaso­bów IT jaki­mi mogą być wspie­ra­ne, na bazie tej ana­li­zy powsta­je lista usług na rzecz pro­ce­sów biz­ne­so­wych jakich ocze­ku­je­my od nowe­go systemu.

Następnie w pro­ce­sie ana­li­zy obiek­to­wej usłu­gi te trans­po­no­wa­ne są na model obiek­to­wy przy­szłe­go sys­te­mu IT. Analiza obiek­to­wa powin­na dać jako pro­dukt tak­że opis dzie­dzi­ny sys­te­mu czy­li repre­zen­ta­cję rze­czy­wi­stych obiek­tów w sys­te­mie. Jest to pod­sta­wa mode­lu danych dla powsta­ją­ce­go sys­te­mu. Kolejne eta­py to już pro­jekt obiek­to­we­go pro­gra­mu (apli­ka­cji) i jego implementacja.

Zarządzanie IT w czasach nowych wyzwań rynkowych

Diagnoza sta­nu obec­ne­go i nie­da­le­kiej historii. 

Kryzys na ryn­ku opro­gra­mo­wa­nia to naj­więk­szy pro­blem z jakie­go się wydo­sta­ją zarów­no twór­cy i dosta­wy opro­gra­mo­wa­nia jak i jego odbiorcy.

Odbiorcy bory­ka­ją się z nie­uda­ny­mi wdro­że­nia­mi, mniej­szą od ocze­ki­wa­nej wydaj­no­ścią kadr korzy­sta­ją­cych z zaku­pio­ne­go opro­gra­mo­wa­nia. Dostawcy cier­pią z powo­du rosną­cej nie­chę­ci do pono­sze­nia przez kupu­ją­cych ogrom­nych kosz­tów wdro­żeń i bra­nia całe­go ryzy­ka na sie­bie. Poniższy dia­gram obra­zu­je wizję pro­ce­su ewo­lu­cji opro­gra­mo­wa­nia wraz z pro­gno­zą na naj­bliż­sze lata.

Ewolucja opro­gra­mo­wa­nia to natu­ral­ny pro­ces roz­wo­ju usług na ryn­ku IT. Długoterminowo to odbior­cy tych tech­no­lo­gii mają decy­du­ją­cy wpływ na kształt i funk­cjo­nal­ność tech­no­lo­gii IT gdyż tak na praw­dę to oni są głów­ny­mi inwe­sto­ra­mi w fir­my inte­gra­tor­skie. Każdy duży pro­jekt infor­ma­tycz­ny to tak napraw­dę pro­jekt inwe­sto­wa­nia w fir­mę wdra­ża­ją­cą przez odbior­cę wdra­ża­ne­go roz­wią­za­nia. Mając to na uwa­dze łatwo zro­zu­mieć dla­cze­go nowe tren­dy wyge­ne­ro­wa­ne przez inno­wa­cyj­ne fir­my nie zawsze znaj­du­ją swój dal­szy ciąg. Bywa, że poja­wia­ją się za wcze­śnie a bywa, że tak na praw­dę potrze­ba wykre­owa­na przez taką inno­wa­cyj­na fir­mę jest fał­szy­wą potrze­bą. To zna­czy, potrze­ba ist­nie­je ale jej zaspo­ko­je­nie przy­no­si efek­ty dale­ko mniej­sze od ofe­ro­wa­nych. Tak było z dotcomm?ami, w dużym stop­niu tak­że z sys­te­ma­mi MRP/ERP czy CRM (kil­ka firm w Polsce zban­kru­to­wa­ło z powo­du bra­ku ocze­ki­wa­ne­go zwro­tu z inwe­sty­cji w sys­tem infor­ma­tycz­ny). Jednym z pod­sta­wo­wych mier­ni­ków oce­ny takich inwe­sty­cji sta­ją się TCO, ROI, bench­mar­king. Jeżeli trud­no jest oce­nić zwrot z inwe­sty­cji (ROI) moż­na porów­nać (bench­mar­king) swój pro­jekt z inny­mi spraw­dzo­ny­mi w innych podob­nych fir­mach. Przed zaku­pem oce­nić kosz­ty posia­da­nia (TCO) sys­te­mu infor­ma­tycz­ne­go obec­nie eks­plo­ato­wa­ne­go i pla­no­wa­ne­go do wdrożenia.

Koszty sys­te­mów infor­ma­tycz­nych są bar­dzo duże, dla­te­go fir­my two­rzą­ce opro­gra­mo­wa­nie poświę­ca­ją nie mało środ­ków na to, by ich pro­duk­ty były tań­sze we wdro­że­niach i w eks­plo­ata­cji. Największe kosz­ty pono­szo­ne były swe­go cza­su na zapew­nie­nie wymia­ny danych pomię­dzy użyt­ko­wa­ny­mi sys­te­ma­mi pocho­dzą­cy­mi od róż­nych pro­du­cen­tów. Systemy pośred­ni­czą­ce w wymia­nie danych pomię­dzy apli­ka­cja­mi nie­jed­no­krot­nie były droż­sze od tych apli­ka­cji. Dlatego ewo­lu­cja opro­gra­mo­wa­nia zmie­rza w stro­ną total­nej kom­pa­ty­bil­no­ści. Obserwujemy rosną­cą popu­lar­ność tech­no­lo­gii XML (uni­wer­sal­ne inter­fej­sy do wymia­ny danych), sys­te­my SAN i NAS czy­li współ­dzie­lo­nych zaso­bów pamię­ci maso­wych. Motory baz danych (RDBMS) już są na tyle uni­wer­sal­ne, ze więk­szość apli­ka­cji może korzy­stać z dowol­ne­go, dostęp­ne­go na ryn­ku pro­duk­tu tego typu. W efek­cie sys­te­my infor­ma­tycz­ne jako zaso­by będą na tyle uni­wer­sal­ne i kom­pa­ty­bil­ne mie­dzy sobą, że poszcze­gól­ne typy zaso­bów będą w danym sys­te­mie wystę­po­wa­ły tyl­ko raz i będą dostęp­ne dla każ­dej potrze­bu­ją­cej ich aplikacji.

Największy boom cze­ka roz­wią­za­nia bazu­ją­ce na inter­fej­sie WWW. Jest to obec­nie naj­bar­dziej uni­wer­sal­ny inter­fejs za pomo­cą któ­re­go może­my mieć dostęp do potrzeb­nych apli­ka­cji. Jak już wyżej napi­sa­łem, użyt­kow­ni­cy pre­fe­ru­ją pła­ce­nia za to co przy­no­si bez­po­śred­nie korzy­ści. Dlatego pro­ces two­rze­nia i roz­wo­ju sys­te­mów sta­je się wła­sno­ścią dostaw­cy opro­gra­mo­wa­nia. Nadwieszą war­tość ma sama apli­ka­cja a tak na praw­dę funk­cjo­nal­ność jaką ofe­ru­ję. Drugim waż­nym czyn­ni­kiem jest bez­pie­czeń­stwo prze­twa­rza­nych danych. Udział pozo­sta­łych kosz­tów jest powo­li mar­gi­na­li­zo­wa­ny u kupu­ją­cych. W efek­cie daje się zaob­ser­wo­wać to o czym wspo­mnia­łem: inwe­stor bie­rze na sie­bie ryzy­ko przy­dat­no­ści i póź­niej­sze­go użyt­ko­wa­nia sys­te­mu infor­ma­tycz­ne­go, ryzy­ko two­rze­nia i roz­wo­ju pozo­sta­je po stro­nie dostaw­cy. Poniższy dia­gram obra­zu­je pro­ces rosną­ce­go zna­cze­nia jako­ści apli­ka­cji (wytwo­rzo­nej war­to­ści) nad pra­cą jaką poświę­ca na to jej dostawca.

Kolejną tech­no­lo­gią prze­zy­wa­ją­cą boom jest są bez­prze­wo­do­we sys­te­my dostę­po­we. Zdalny dostęp a w kon­se­kwen­cji peł­na mobil­ność to pod­sta­wo­we cechy nowo­cze­sne­go sys­te­mu infor­ma­tycz­ne­go. Podstawowe korzy­ści jakie nie­sie ze sobą mobil­ność to łatwość wyko­na­nia potrzeb­nej pra­cy w dowol­nym miej­scu. Rzecz w tym, że pro­ce­sy biz­ne­so­we wspo­ma­ga­ne przez tech­no­lo­gie IT były do tej pory zwią­za­ne z zaso­ba­mi infor­ma­tycz­ny­mi, któ­re je wspie­ra­ły. W efek­cie wydaj­ność pra­cy nie zawsze mogła rosnąć lub kosz­ty nie­któ­rych pro­ce­sów były wie­sze. Podstawowym pro­ble­mem jest dostęp do infor­ma­cji i jej aktu­al­ność. Wielu pra­cow­ni­ków firm znacz­ną część cza­su prze­by­wa poza fir­mą, w miej­scach gdzie tra­dy­cyj­ny dostęp do zaso­bów IT macie­rzy­stej fir­my jest nie­moż­li­wy. Pierwszym ele­men­tem roz­wią­zu­ją­cym ten pro­blem w czę­ści jest sieć Internet, dzię­ki któ­rej może­my mieć dostęp do zaso­bów fir­my z każ­de­go miej­sca w któ­rym jest dostęp do sie­ci Internet. Jednak te wła­śnie miej­sca do tej pory były zwią­za­ne fizycz­nie z punk­tem ich insta­la­cji (biu­ra innych firm, kawia­ren­ki inter­ne­to­we itp.). Technologie bez­prze­wo­do­we uwal­nia­ją nas od tych ogra­ni­czeń. Przemieszczanie się z kom­pu­te­rem w ręku prze­sta­je ozna­czać brak dostę­pu do fir­mo­wej sie­ci. Rozwój tele­fo­nii komór­ko­wej i sprzę­tu prze­no­śne­go powo­li pro­wa­dzi do uwol­nie­nia zależ­no­ści tech­no­lo­gii infor­ma­tycz­nych od miej­sca pobytu.

Podsumowanie

Systemy infor­ma­tycz­ne sta­ją się coraz bar­dziej uni­wer­sal­ne patrząc na nie od stro­ny kom­pa­ty­bil­no­ści baz danych czy miejsc ich skła­do­wa­nia. W efek­cie moż­na już je podzie­lić na nie­za­leż­ne zbio­ry prze­twa­rza­nych danych oraz apli­ka­cje słu­żą­ce do wpro­wa­dza­nia, prze­twa­rza­nia i wypro­wa­dza­nia tych danych.

Firmy infor­ma­tycz­ne, szcze­gól­ne twór­cy opro­gra­mo­wa­nia muszą zacząć szcze­gól­nie dbać o jakoś dostar­cza­nych pro­duk­tów, gdyż ryzy­ko wyni­ka­ją­ce z ich jako­ści i przy­dat­no­ści coraz czę­ściej jest zrzu­ca­ne wła­śnie na nich. Odbiorcy sys­te­mów (spon­so­rzy pro­jek­tów) zaczy­na­ją wymu­szać w umo­wach rów­no­mier­ne roz­kła­da­nie ryzy­ka na obie stro­ny kontraktu.

Jednym z efek­tów tego pro­ce­su jest coraz czę­ściej spo­ty­ka­na meto­da opłat za roz­wią­za­nia infor­ma­tycz­ne na zasa­dzie ?za zuży­cie? a nie jako zakup na wła­sność. Jednym z tych tren­dów jest out­so­ur­cing. Opłacalny jest szcze­gól­nie tam, gdzie zaso­by infor­ma­tycz­ne są wyko­rzy­sty­wa­ne w spo­sób trud­ny do szcze­gó­ło­we­go zapla­no­wa­na albo w spo­sób bar­dzo nie­rów­no­mier­ny w cza­sie (np. wydru­ki fak­tur na koniec okre­su roz­li­cze­nio­we­go). Obserwujemy zarów­no zmia­ny w sys­te­mach opłat licen­cyj­nych za opro­gra­mo­wa­nie (cyklicz­ne opła­ty za okres użyt­ko­wa­nia opro­gra­mo­wa­nia zamiast jed­no­ra­zo­wej przy zaku­pie) jak i w sys­te­mach opłat za usłu­gi kon­sul­tin­go­we (poja­wia się skład­nik par­ty­cy­pa­cji finan­so­wej w efek­tach takiej pracy).

? Jarosław Żeliński (Źródło dia­gra­mów: mate­ria­ły kon­fe­ren­cyj­ne IDC., kon­fe­ren­cja odbę­dzie się w dniach 29 i 30 Września 2003. Koszt Udziału to 1.940 EUR w przy­pad­ku reje­stra­cji do koń­ca Lipca, 2.300 EUR po tym ter­mi­nie, szcze­gó­ły i for­mu­larz reje­stra­cyj­ny na stro­nach Konferencja Managing IT in Challenging Times).

Notatka: IDC orga­ni­zu­je w dniach 29 – 30 Września 2003r. corocz­ne spo­tka­nie dla CEO/CIO. W tym roku poświę­co­ne ono będzie temu jak tech­no­lo­gie IT mogą pomóc oso­bom zarzą­dza­ją­cym w cza­sie nowych ryn­ko­wych wyzwań.

Trzy pod­sta­wo­we tema­ty zosta­ły potrak­to­wa­ne jako priorytety:
– zasto­so­wa­nia tech­no­lo­gii IT
– sys­te­my pra­cu­ją­ce w opar­ciu o WWW
– sys­te­my mobil­ne i bezprzewodowe