Dva roky, dvě cifry

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/y2kfif­ty.htm .