Ano, dva roky zbývají do začátku posledního roku 20. století. To
sice končí až 31.prosince 2000, pro svět počítačů však nastává
překlopení do nového století o rok dříve.
U mnohých, především rozsáhlých informačních systémů, je
historicky kódováno datum běžně do šestimístného čísla či řetězce
(tvar DDMMRR nebo RRMMDD). Samozřejmě existuje mnoho jiných délek
a kombinací, všechny však mají společné dvě cifry pro zakódování
roku. Tento problém je celkem známý, ale co s ním? Zahodit
existující projekty a nakoupit jiné? To je ale řešení, které
většinou přináší ještě větší problémy, pokud je vůbec
realizovatelné. U zavedených rozsáhlých systémů zbývá jediná
možnost -- pustit se do úprav stávajícího projektu.
Obvykle je největším pokrokem v řešení problému roku 2000
uvědomit si, o jak závažnou a rozsáhlou otázky se jedná ve všech
vazbách a důsledcích. Jen plánování a "supervize" řešení běžně
zabírají 25 až 40 % veškerých nákladů a lidských zdrojů
vyhrazených na úpravu určitého informačního systému (IS).
Některé otázky a problémy, které se vyskytují při plánování
projektu:
-- Je lépe najmout větší množství "kódovačů" a testerů,
nebo soustředit menší, kvalifikovaný, dobře vybavený a zaplacený
pracovní tým?
Odpověď není jednoznačná. V dosavadní praxi vychází spíše řešení
čím větší IS, tím příklon k druhé možnosti. Pro tento trend
hovoří i dříve zmíněné vysoké procento nákladů na plánování
a organizaci (méně lidí znamená menší nároky na organizaci).
-- Jak provést rozbor IS a všech vazeb v něm?
Bez dokonalé analýzy a zdokumentování celého informačního systému
nelze pomýšlet na kvalifikované řešení problému, a především na
kvalitní otestování jednotlivých částí i IS jako celku.
U rozsáhlých systémů nepřichází ruční rozbor a testování
prakticky v úvahu. Jako jediná reálná možnost se jeví využít
některý z produktů pro analýzu, zdokumentování a testování
systému.
-- Stanovení celkových nákladů.
-- Stanovení a zajištění potřebného počtu pracovníků.
-- Zaškolení projektantů, programátorů a testerů.
-- Jak rozdělit projekt mezi jednotlivé programátory či pracovní
skupiny a jak zajistit vazby mezi nimi?
-- Jak se budou předávat výsledky k testování?
-- Zajištění strojového času.
-- Testování IS při simulaci systémového data před a po
31.12.1999.
-- Provádět převod a testování na provozní platformě, či
v simulovaném prostředí na PC?
-- Bude upravený IS vyhovovat současnému provozu?
-- Předávání systému do rutinního provozu.
-- Konverze datové základny -- kdy, kde, jak?
-- Co s archivními daty?
-- Jak je to s autorskými právy? Může jít o zásah do cizího
systému bez souhlasu autorů .
-- "Překlopit" systém naráz či postupně?
-- Přichází v úvahu použití specializovaného softwaru pro analýzu,
zautomatizování některých činností a testování projektu?
-- Projekt je třeba předat do rutinního provozu dříve než
31.12.1999! Jsou případy, kdy rok 1999 (dvouciferně 99) je
vyhrazen jako speciální příznak.
-- Jak pokračovat s IS dále (přechod na c/s architekturu,
GUI,...)?
Pokud je IS schopen pracovat bezchybně i po 1.1.2000, co s ním
dál? I "prastaré" cobolské programy lze upravit do moderní podoby
s¦grafickým uživatelským rozhraním, prezentací na Internetu
a zachovat tradičně vysokou výkonnost, komunikační schopnosti
a snadnou údržbu.
Přejděme však k řešení roku 2000 ve vlastním systému. V čem
spočívá jádro problému? Dvoubytový formát roku se ve svých
důsledcích promítá do mnoha dílčích problémů:
-- třídění souborů a tabulek (SORT, MERGE)
-- sekundární (alternativní) klíče v souborech
-- konstanty
IF ROK = '00' (Má se provést v roce 2000, nebo v případě,
THEN ... že není položka ROK vyplněna?)
-- vazby v deklarativní části (REDEFINE, copy moduly, ...)
-- vazby v procedurální části
převzetí systémového data
MOVE, IF, ...
přepočet data
-- vazby přes soubory -- soubory jsou běžně definovány ve více
programech
-- dvojčíslí roku v názvech archivních souborů
-- vyvolávání různých modulů v závislosti na datu
Tři základní přístupy k řešení: date expansion, hashing,
windowing
Změna struktury datových položek (těžiště úprav je v deklarativní
části):
-- rozšíření popisu položky, vyhrazení dodatečných dvou číslic pro
století ( date expansion ). Toto je nejúplnější řešení, přináší
však velkou pracnost, a v některých případech nepřichází v úvahu
(viz dále).
-- ponechání původních dvou bytů, avšak zkomprimovaných tak, aby
do nich bylo možno buď přidat příznak století (např. 0=20.stol.
1=21.stol.), či uložit celý rok (dva byty přijmou binárně čísla
až do 65535), tzv hashing.
Zásah výhradně do procedurální části (tzv. windowing ). U tohoto
řešení se rozsahy položek nemění, jenom se ošetřují kritická
místa v programu, to znamená porovnání dvou podezřelých položek
(pouze větší či menší, neboť rovnost neznamená problém) či
přepočet data. V daném kritickém bodě je nutno rozhodnout dle
obsahu položky ROK, zda se jedná o 20. (19RR) či 21. (20RR)
století. Např. rok v rozsahu 00 -- 59 znamená ve skutečnosti
rozsah let 2000 -- 2059, rozsah 60 -- 99 znamená 1960 -- 1999. Daný,
rozsah či jinak okno (anglicky window, odtud windowing), může být
stanoven jako:
pevné okno (fixed window), např. okno 1960 -- 2059
IF ROK > 59 THEN STOLETI = 19 ...
IF ROK < 60 THEN STOLETI = 20 ...
klouzavé okno (sliding window)
okno se posouvá každý rok o jeden vpřed, např. v roce 1998 okno
1960 -- 2059, v roce 1999 okno 1961 -- 2060 (zpět o 38 let, vpřed
o 61 let)
HORNI-MEZ = LETOSNI-ROK -- 1938
DOLNI-MEZ = LETOSNI-ROK + 61 -- 1900
IF ROK > DOLNI-MEZ THEN STOLETI = 19 ...
IF ROK < HORNI-MEZ THEN STOLETI = 20 ...
měnitelné okno (dynamic window)
Poloha okna se neodvozuje přímo od běžného roku, ale lze ji měnit
např. pomocí parametrického souboru. Také lze nastavit různá okna
pro různé části projektu. Použití této metody má některé
podstatné výhody: Jednak výrazné snížení počtu kritických míst
v programu, která je nutno podrobně analyzovat, případně upravit
(běžně o jeden až dva řády), dále možnost postupného převodu
částí projektu či jednotlivých programů a jejich uvedení do
rutinního provozu, a konečně nezávislost na interním formátu
uložení data v počítači
Všechny tři uvedené způsoby řešení -- date expansion, hashing,
windowing -- mají své klady a zápory. Ve většině konkrétních
projektů se uplatní jejich kombinace. Je jasné, že použití
windowingu nepřichází v úvahu třeba při evidenci osob. Méně
patrné je, že změna struktury datových položek v určitých
případech není možná -- např. archivní soubory, u kterých je
nepřípustný jakýkoliv zásah. Jsou země, kde by toto řešení
znamenalo porušení zákona. Z poznatků získaných z již
probíhajících projektů vyplývá, že použití metody windowingu
šetří 40 až 60% času a nákladů na analýzu, úpravy a testování
projektu (méně úprav => méně chyb => méně testovacích cyklů). Pro
minimalizaci nákladů a času je optimální nejprve stanovit, ve
kterých případech je nezbytná (a přípustná) změna struktury
datových položek. Ve zbývajících částech projektu pak použít
windowing.
/* tabulka */
<T>Úprava datových<T> položek Windowing
počet řádků, které je nutno analyzovat <T> 1/4 -- 1/20
z celkového počtu <T>1/500 -- 1/10 000 z celkového počtu, případně
upravit
časová náročnost a pracnost <T>vysoká <T>nízká
časové omezení <T>není rozsah <T>100 let (lze posouvat)
testování <T>po ucelených částech <T>průběžně
přechod do rutinního provozu <T>kvůli vazbám možné až po
provedení všech změn <T>průběžně
pracovní síly <T>větší množství méně kvalifikovaných
programátorů<T> menší množství vysoce kvalifikovaných
programátorů
Konverze datové základny
Pokud se jedná o některou z databází (DB2, IMS, Oracle ...)
a jsou důsledně využívány příslušné datové struktury, není
přechod s touto datovou základnou problémem. U datových souborů
lze využít utilit obsažených v některých softwarových balících.
Testování
Vzhledem k nedostatku kvalifikovaných sil a času se na problému
roku 2000 jeví jako nejnáročnější otestovat změny a chování
celého systému po provedených úpravách. Zcela výjimečně lze plně
prověřit pouze jeden či malou skupinu programů. Navíc uživatel
mnohdy požaduje otestovat celý IS za nepřetržitého
(a nepřerušitelného!) provozu. Dle dřívějších odhadů (např.
Gartner Group, U.S.A., Micro Focus, Velká Británie) potvrzených
praxí vychází poměr nákladů na převod a testování IS v¦poměru
přibližně 1:2, ve výjimečných případech (např. u výše zmíněných
"nepřerušitelných" systémů) až 1:4. Známé pravidlo "Nejlepším
testem je rutinní provoz" skrývá jeden velký problém. Jakákoliv
chyba při tomto "testu" může mít velmi vážné následky. Při
převodu IS proto hodně záleží na jeho řádném prověření. Do
rutinního provozu se nesmí dostat neupravené či chybně upravené
moduly a data.
Pro testování systému přicházejí v úvahu dvě možnosti:
-- testovat aplikaci přímo v prostředí, kde je a bude provozována
-- simulovat provozní prostředí (CICS, IMS, JCL, ...) na PC
V obou případech je téměř vyloučeno "ruční" testování a je nutné
použití některého specializovaného softwaru.
/* tabulka */
Provozní platforma <T> Jiná (PC) platforma
kompatibilní <T>možná nekompatibilita
dražší <T>levnější
dlouhý cyklus úprava zdrojového textu / test <T>úzká vazba
úpravy / testy
závislost na zdroji <T>operativnější
závislost na místě <T>mobilní (pracovní tým není trvale
místně vázán)
Závěr
Účelem tohoto článku není dokonalý rozbor problému roku 2000,
a to především proto, že velmi záleží na typu projektu, jeho
velikosti a zbývajícím čase. Článek by měl být pouze vodítkem při
rozhodování a plánování přechodu velkých IS do 21.století. Pro
řešení existuje mnoho softwarových prostředků. Od jednoduchých
jednoúčelových přípravků vyhledávajících datové položky až po
výkonné produkty, které ušetří až 80 % času a sil při analýze,
dokumentaci a testování projektu. Některé z nich dokáží po
základní analýze i propočítat náklady na úpravu a otestování
projektu. Záměrně zde nejsou uvedeny žádné příklady takových
produktů, abych nebyl nařčen ze skryté reklamy. Čtenáře však mohu
odkázat na následující internetové adresy, kde se lze dozvědět
více o mnoha produktech i o problému roku 2000 obecně:
www.year2000.com , www.microfocus.com/year2000 , a pro pobavení
(v angličtině) www.microfocus.com/year2000/y2kfifty.htm .
PŘEDPLATNÉ
ČLÁNKY DO MAILU