Životný cyklus databázy

Pod pojmom životný cyklus databázy rozumieme všetky udalosti, ktoré nastanú od okamihu, kedy si prvýkrát uvedomíme potrebu existencie databázy na spracovanie dát vo firme alebo v organizácii, cez akýkoľvek jej vývoj a nasadenie do prevádzky, až po jej konečné odstavenie z činnosti. Väčšina firiem, ktoré vyvíjajú počítačové systémy, dodržujú pri svojej práci určitý formálny proces. Pomocou tohto procesu zaisťujú, že vývoj prebehne hladko, že bude nákladovo efektívny a že jeho výsledkom bude kompletný počítačový systém, ktorý spĺňa stanovené očakávania. Návrh a implementácia databáz neprebieha nikdy v akomsi vákuu, keďže spolu s vlastnou databázou vyvíjame vždy ďalšie komponenty uceleného systému, ako je užívateľské rozhranie, aplikačné programy, zostavy. Dlhodobé práce na celom systéme sa väčšinou rozdeľujú do projektov, z ktorých každý má svoj vlastný konečný zoznam cieľov,  je mu pridelený plánovaný časový rámec na dokončenie, ako aj  manažér alebo vedúci zodpovedný za úspešný priebeh práce. Aby sme pochopili celý životný cyklus databáz, musíme mať vedomosť o životnom cykle počítačových systémov a o organizovaní a riadení projektov vývoja týchto systémov.

Poznámka: Procesom vývoja počítačových systémov sa zaoberá softvérové inžinierstvo. Databázové (resp. informačné) systémy sú jedným z druhov počítačových systémov, preto pre ne platí všetko to, čo zo softvérového inžinierstva poznáme.

Klasická metóda vývoja počítačových systémov sa opiera o proces označovaný ako životný cyklus vývoja systémov (system development life cycle, SDLC). Pri tomto procese sú akékoľvek práce rozdelené do etáp (fáz) znázornených na obrázku 6.1. Variantov opísaného životného cyklu je asi toľko, koľko je na svete rôznych autorov, výrobcov softvéru pre riadenie projektov a firiem, ktoré si vytvorili svoju vlastnú metodológiu. Všetky tieto varianty majú však tri základné komponenty, takže sa dá povedať, že sú „ušité z rovnakej látky“. Mohli by sme hovoriť o výhodách jedného variantu oproti iným, ale tým by sme si všetko zbytočne skomplikovali, keďže my potrebujeme skôr základný, všeobecný prehľad.   

Na obrázku 6.1 sú v ľavom stĺpci uvedené tradičné kroky životného cyklu vývoja systémov, v strede základné aktivity projektu a vpravo potom potrebné kroky, ktoré v rámci aktivít musíme uskutočniť vo vlastnej databáze.

Proces vývoja nemusí byť vždy iba jednosmerný. Často prídeme počas vývoja na to, že niektoré informácie chýbajú alebo sú neúplné, takže sa musíme vrátiť do inej etapy, a chýbajúcu prácu doriešiť. Tento spätný chod naznačujú na uvedenom obrázku čiarkované čiary so šípkami, a v podstate nám  tak pripomínajú, že prerábanie projektu je – do istej miery – normálne a v opísanej metodológii životného cyklu plne očakávateľné.

Obrázok 6.1: Klasický životný cyklus vývoja systémov.

Vo fáze plánovania musí organizácia v rámcovom pohľade pochopiť, kde sa momentálne nachádza, kam to chce s projektom dosiahnuť, a rozhodnúť sa, aký rozumný postup alebo plán prijme na prechod zo súčasného stavu do stavu cieľového. Plánovanie sa často realizuje na podstatne dlhšie časové obdobie, ako je len jeden jediný projekt, a celkový plán informačných systémov v organizácii je základom pre rozhodovanie, ktoré projekty – v súlade s dosahovaním všeobecne stanovených cieľov – otvoriť. Dlhodobý cieľ plánu môže byť formulovaný napríklad vetou „zvýšiť zisky o 15 percent“. V rámci tohto cieľa potom môže byť navrhnutý projekt vývoja aplikačného systému a databázy pre sledovanie ziskovosti zákazníkov.

Pre navrhnutie konkrétneho projektu sa väčšinou otvorí riešenie štúdie uskutočniteľnosti projektu (feasibility study), ktorá opíše, či je v projekte možné rozumne očakávať naplnenie konkrétnych stanovených cieľov, a určí prvotné odhady času, ľudských zdrojov (zamestnancov) a materiálov, potrebných pre dokončenie projektu. Tak zistíme, či sa projekt zmestí do požadovaného časového rámca a dostupného finančného rozpočtu. Očakávaná hodnota projektu pre vlastnú organizáciu sa často zisťuje pomocou návratnosti investícií (return on investment, ROI) alebo iného výpočtu. Pokiaľ je štúdia uskutočniteľnosti schválená vedením firmy, zaradí sa projekt do celkového plánu organizácie, a začne sa formovať projektový tím. Zloženie projektového tímu sa v priebehu doby riešenia projektu mení, a pridávajú sa doň noví ľudia s príslušnými vedomosťami a zručnosťami, alebo sa aktuálni účastníci odvolávajú – podľa toho, ako to povaha projektu vyžaduje. Jedným z nemenných členov projektového tímu je vedúci – manažér projektu, ktorý je zodpovedný za celkové riadenie a priebeh projektu.     

Vo viacerých organizáciách býva do projektového tímu hneď na začiatku zaradený databázový špecialista (databázový administrátor alebo dátový modelár). V prístupe riešenia riadenom dátami, kde kladieme dôraz na analýzu dát, a až následne podľa ich výsledkov stanovíme potrebné spracovanie a transformáciu dát, je včasné zaradenie kvalifikovaného dátového špecialistu veľmi dôležité. Pri procesnom riadení, kedy najprv študujeme potrebné procesy, a až potom stanovíme, aké dáta systém vyžaduje, nie je prítomnosť databázového špecialistu hneď v prvých fázach projektu taká podstatná. Skúsenosti z praxe ukazujú, že najlepšie výsledky dosiahneme jedine kombináciou procesného a dátového modelovania. Na plne dvojaké spracovanie projektu nie je väčšinou dosť času ani ľudí, takže sa musíme uspokojiť s druhým najlepším výsledkom, a tým je pri databázach dátovo orientované riešenie. Procesy musíme v systéme ako-tak navrhnúť, ale v prípade, že najskôr uskutočníme dôkladnú analýzu dát, potrebné procesy z nich vyplynú pomerne rýchlo. Ak napríklad pri návrhu nášho systému zameraného na ziskovosť zákazníkov zistíme, že máme „niekde“ k dispozícii dáta o predajoch zákazníkom, a ak si naviac uvedomíme, že ziskovejší sú tí zákazníci, ktorí podávajú menšie množstvo objemovo veľkých objednávok, môžeme vyvodiť závery, podľa ktorých potrebujeme v určitom procese hodnotiť zákazníkov podľa počtu a veľkosti ich objednávok. Na strane druhej, pokiaľ by sme na začiatku vedeli len to, že musíme v nejakom procese hodnotiť zákazníkov, trvalo by nám odvodenie potrebných kritérií pre hodnotenie výrazne dlhšie.      

Medzi databázové aktivity uskutočňované v tejto fáze projektu patrí kontrola možností databázového systému a stanovenie, či momentálne používané technológie spĺňajú celkové potreby projektu. Veľa organizácií sa väčšinou „usadí“ na jednom, prípadne dvoch štandardných produktoch z relačných databáz, pod ktorými riešia akékoľvek projekty. V tomto okamihu je preto nutné porovnať ciele projektu so súčasným stavom technológií a overiť, či má projekt pri použití tejto technológie rozumnú šancu na úspech. Pokiaľ sa v tejto fázy zistí, že je potrebné siahnuť po novšej databáze alebo po úplne inom relačnom databázovom systéme, je presne ten správny čas začať proces jeho zakúpenia a uvedenia do prevádzky.  

Počas fázy zberu požiadaviek musí projektový tím zhromažďovať a zdokumentovať rámcový, no napriek tomu dostatočne presný opis cieľov, ktoré ma projekt dosiahnuť. Pri zbere požiadaviek sa ale musíme zamerať na to, čo sa má dosiahnuť, a nie ako to dosiahnuť. Na otázku „ako“ odpovieme v ďalších fáza vývoja. Do požiadaviek je dôležité zahrnúť čo najviac informácií o existujúcich a očakávaných obchodných (aplikačných) procesoch, aplikačných pravidlách a entinách. Čím viac práce zvládneme v týchto úvodných fázach projektu, tým hladší priebeh v nasledujúcich etapách môžeme očakávať. Na druhej strane, pokiaľ nedokážeme do istej miery tolerovať neznáme veličiny, môže v projekte vzniknúť analýza-paralýza, kedy celý projekt stojí, pretože analytici sa pokúšajú hľadať “absolútne” presné  a podrobné odpovede na otázky, na ktoré zatiaľ ani nie je možné odpovedať.  

Z pohľadu návrhu databázy sú asi najzaujímavejšou stránkou zberu požiadaviek pohľady užívateľov. My sme o užívateľskom pohľade hovorili ako o metóde, pomocou ktorej prezentujeme databázovému užívateľovi určitú množinu dát presne podľa potrieb tejto konkrétnej osoby alebo aplikácie. V tejto fáze vývoja majú ale „pohľady“ užívateľov skôr formu názorov, teda existujúcich alebo navrhovaných zostáv, formulárov, obrazoviek, webových stránok a podobne.

Zber požiadaviek je možné realizovať pomocou celej rady rôznych techník. Medzi najbežnejšie používané patria rozhovory (interview), dotazníky, pozorovanie a revízia dokumentov. Žiadna z týchto ani iných techník sa nedá označiť za najlepšiu a vždy je vhodnejšie pracovať podľa určitej kombinácie niekoľkých postupov, šitých na mieru konkrétnej organizácie, ako sa slepo spoliehať na jednu z týchto metód. Odpoveď na otázku, či je vhodnejšie uskutočniť najprv dotazníkový prieskum, a potom pokračovať rozhovorom s kľúčovými osobami, alebo opačne – začať  rozhovormi, a až podľa ich výsledkov formulovať štruktúru dotazníka, sa tak napríklad veľmi často skrýva v kultúre danej organizácie a v obvyklom spôsobe práce. V nasledujúcej časti si povieme v stručnosti niečo ku každej z uvedených techník, a pozrieme sa na výhody a nevýhody jednotlivých metód.

• Rozhovory

Rozhovory s kľúčovými jednotlivcami, ktorí majú čo-to povedať k očakávaným výsledkom projektu, sú veľmi rozšírenou metódou práce. Jednou z veľmi častých chýb je ale zamerať sa v rozhovore iba na pracovníkov manažmentu. Pokiaľ do rozhovoru nezapojíme taktiež zástupcov budúcich užívateľov, ktorí budú s novou databázou alebo aplikáciou skutočne pracovať, môže projekt skončiť výsledkom, ktorý nie je prakticky použiteľný, pretože manažment celkom presne nerozumie tomu, čo všetko je pre činnosť vlastnej organizácie potrebné.

K výhodám zberu požiadaviek pomocou rozhovoru patrí: 

• Opytujúci môže zistiť odpovede i na otázky, ktoré v rozhovore vôbec nepoložil. Pri diskusii sa často objavia okrajové témy, ktoré sú zdrojom ďalších užitočných informácií.
• Opytujúci sa môže veľa dozvedieť taktiež z „reči tela“ opytovaného. V priamom osobnom rozhovore je oveľa jednoduchšie odhaliť neistotu a pokusy o klamlivé odpovede ako v dotazníku s písomnými odpoveďami.

Rozhovory majú, pravdaže, taktiež svoje nevýhody:

• Zaberajú podstatne viacej času ako iné metódy.
• Neskúsený opytujúci môže respondentovi nechcene „ponúknuť“, aké odpovede od neho očakáva, a to prostredníctvom spôsobu kladenia otázok a reakcií na už získané odpovede. 

• Dotazník

Ďalším obľúbeným postupom pri zbere požiadaviek kladených na projekt je vypracovať dotazník s kľúčovými otázkami. Tento dotazník potom rozošleme všetkým rozhodcom a potenciálnym užívateľom aplikácie a databázy, ktoré budú v rámci projektu vytvorené, a na základe analýzy odpovedí stanovíme konečný rozsah požiadaviek.

Opísaný zber požiadaviek pomocou dotazníka má nasledujúce výhody:

• Za krátku dobu je možné zvládnuť pomerne veľké množstvo okruhov tém. Akonáhle je dotazník zostavený, nie je ťažké ho – v prípade potreby – rozdistribuovať širšiemu okruhu respondentov.
• Každý účastník dostane na zodpovedanie presne rovnaké otázky.

Dotazník má taktiež nevýhody, ako napríklad:

• Dotazníky majú veľmi často pomerne zlú návratnosť. V prípade, že užívateľa nedonútite k odpovedi vhodnou odmenou alebo naopak – hrozbou trestu, môžete považovať za úspech približne 10 percent zodpovedaných dotazníkov.
• Formulovať do dotazníka nestranné otázky je oveľa ťažšie, ako si je možné predstaviť.
• Projektový tím je ochudobnený o neverbálnu odpoveď, ktorú dostane pri osobnom rozhovore.

• Pozorovanie           

Veľmi rozšírenou technikou zberu požiadaviek je taktiež pozorovanie činnosti firmy a osôb, ktoré budú s novou aplikáciou alebo databázou pracovať.

Je možné povedať, že pozorovanie má tieto výhody:

• V prípade, že pri svojom pozorovaní pracovníkov nijako neobťažujete, dostanete obraz o skutočnej povahe pracovných procesov za normálnej, každodennej prevádzky. Je potrebné si uvedomiť, že realita sa môže pomerne dosť líšiť od postupov, ktoré si vo svojich „ideáloch“ predstavuje vedenie firmy, alebo dokonca od postupov formálne predpísaných v dokumentácii. Reálne procesy môžu byť oproti týmto teoretickým postupom upravené – buď tak, aby vôbec fungovali, alebo aby boli efektívnejšie.
• Pri pozorovaní vám neuniknú udalosti a činnosti, ktoré by ľudia v odpovedi na dotazník alebo pri rozhovore buď nenapadlo uviesť, alebo sa ich neodvážili uviesť.     

Nevýhody pozorovania potom môžeme zhrnúť takto:

• Ak ľudia vedia, že ich pozorujete, správajú sa inak, a vy tým nezískate presný obraz o ich pracovných procesoch. Tomuto javu sa často hovorí hawthornský efekt, ktorý bol prvýkrát pozorovaný v 20-tych rokoch 20. storočia v závode Hawthorne spoločnosti Western Electric v americkom Chicagu, kde sa zvýšila výroba nie po zlepšení pracovných podmienok, ale len preto, že sa vedenie firmy začalo o možnosti týchto zlepšení zaujímať.
• Ak nevenujeme pozorovaniu veľké množstvo času, neuvidíme v reálnej situácii výnimky, ktoré môžu podkopávať fungovanie súčasných procesov. Je to asi akoby ste prácne dláždili cestu pre kone, ktoré si ale nájdu cestu na druhú stranu dierou cez plot.
• Cestovanie na rôzne pracoviská môže zvýšiť náklady na projekt.

• Revízia dokumentu

Táto technika znamená vyhľadanie a preštudovanie všetkých dokumentov, ktoré sú k dispozícii pre existujúce jednotky a procesy, ktoré sa budú nového programu a databázy dotýkať.

Výhody zberu požiadaviek pomocou revízie dokumentov sú tieto:

• Revízia dokumentov je väčšinou menej časovo náročná ako iné metódy.
• Dokumenty podávajú často dobrý prehľad systému, ktorý je tu oproti úvodným informáciám, zistených pri rozhovore, lepšie premyslený.
• Obrázky a diagramy sú skutočne cennejšie ako tisíc slov.

Nevýhodami revízie dokumentov sú:

• Dokumenty nemusia správne odrážať skutočnú podobu pracovných postupov. Dokumenty totiž často opisujú, čo by sa malo robiť, a nie, čo sa často robí.
• Dokumenty bývajú často zastarané.

Úlohou etapy (fázy) konceptuálneho návrhu je návrh externého – vonkajšieho prostredia cieľovej aplikácie (aplikácií) a databázy (databáz). Vo viacerých metodológiách sa pre túto etapu skutočne používa pojem externý návrh. Počas tejto etapy vývoja sa navrhne rozloženie zostáv, obrazoviek, formulárov, webových stránok a ďalších nástrojov pre získavanie a prezentáciu dát. Naviac v tejto fáze dokumentujeme vonkajšie toky aplikácie, a to vo forme vývojových diagramov, toku spracovania dát, alebo diagramov prechodu obrazoviek. Týmto projektový tím lepšie pochopí logické toky v systéme.

V tejto etape realizuje databázový špecialista, pridelený do projektového tímu (je ním databázový administrátor alebo dátový modelár), aktualizáciu systémového dátového modelu, ktorý je väčšinou udržovaný vo forme diagramu entín a vzťahov (diagram ER). Do tohto diagramu je potrebné pridať novo objavené alebo zmenené entiny, a zaznamenať taktiež novo doplnené alebo upravené aplikačné pravidlá. Užívateľské pohľady, entiny a aplikačné pravidlá sú podstatné pre úspech ďalšej fázy životného cyklu vývoja, a to logického návrhu databázy.     

Počas fázy logického návrhu sa realizuje množstvo práce na technickom návrhu aplikácie a databázy, vytváranej v rámci projektu. Vo viacerých metodológiách sa táto etapa nazýva interný návrh, pretože sa pri nej navrhujú vnútorné (interné) časti projektu, s ktorými užívateľ nikdy nepríde do kontaktu. Celú prácu, ktorú bude hotová aplikácia zaisťovať, rozdelíme v tejto etape do segmentov (modulov), čo predstavujú ucelené jednotky aplikačných programov, ktoré budú vytvárané a testované spoločne, a pre každú jednotku napíšeme podrobnú špecifikáciu. Táto špecifikácia musí byť natoľko úplná, aby ju bez ďalších doplňujúcich informácií dokázal napísať ľubovoľný programátor so zodpovedajúcimi vedomosťami. Logické toky medzi modulmi dokumentujeme v tejto fáze pomocou diagramov toku dát alebo pomocou starších vývojových diagramov.

Z pohľadu databázy je hlavným ťažiskom práce tejto etapy takzvaná normalizácia. Ide o techniku návrhu tabuliek pre relačné databázy, ktorú vyvinul Dr. E. F. Codd, a ktorá sa ideálne hodí predovšetkým pre transakčne orientované systémy (teda pre systémy, v ktorých prebieha veľké množstvo operácií vkladania, aktualizácie a odstraňovanie dát z relačných tabuliek). Po dokončení normalizácie uskutočníme taktiež aktualizáciu celkového logického dátového modelu systému (pokiaľ existuje), a premietneme doň prípadne nové entiny.

Vo fáze fyzického návrhu musíme logický návrh previesť do podoby skutočného hardvéru a systémového softvéru, pomocou ktorého budeme aplikáciu a databázu implementovať. Pokiaľ sú špecifikácie aplikácií napísané tak dobre, že sa dajú priamo implementovať, nemusíme po procedurálnej stránke robiť takmer nič. Veľká práca nás ale čaká pri špecifikácii hardvéru, na ktorý budeme cieľovú aplikáciu a databázu inštalovať – súčasťou týchto špecifikácií sú taktiež odhady potrebných kapacít procesorov, diskových zariadení a šírky komunikačného pásma siete, v ktorej systém pobeží.

Na strane databázy znamená fyzický návrh implementáciu normalizovaných relácií, navrhnutých v predchádzajúcej fáze logického návrhu do prostredia konkrétneho relačného databázového systému. Konkrétne tak musíme napísať alebo vygenerovať príkazy jazyka DDL pre definíciu potrebných databázových objektov, vrátane klauzúl SQL, ktoré definujú fyzické umiestenie tabuliek a indexov. Uskutočňuje sa tu taktiež predbežná analýza potrebných databázových dopytov, pri ktorých odhadujeme, aké ďalšie indexy budú v databáze pre dosiahnutie rozumného výkonu potrebné. Podstatným výstupom tejto fázy sú príkazy jazyka DDL pre vytvorenie vývojových databázových objektov, s ktorými budú vývojári pracovať pri testovaní aplikačných programov počas následnej konštrukčnej fázy.

V priebehu konštrukčnej fázy musia vývojári aplikácií naprogramovať jednotlivé programové jednotky a preskúšať ich (otestovať). Vyskúšané programové jednotky sa prenášajú do systémového testovacieho prostredia, kde prebieha zostavovanie a testovanie celého aplikačného a databázového systému od začiatku do konca. Prostredia, ktoré sa pri vývoji, testovaní a implementácii aplikačných systémov používajú najčastejšie, sú znázornené na obrázku 6.2. Úplnou kombináciou hardvéru a softvéru je tvorené každé z týchto prostredí, ktoré obsahuje všetky komponenty potrebné k prevádzke aplikačného systému. Po dokončení systémových testov sa systém dostane do prostredia pre zaistenie kvality. Väčšina stredných a veľkých organizácií máva samostatné oddelenie zaisťovania a riadenia kvality, ktoré otestuje celý aplikačný systém, a preukáže, že vyhovuje stanoveným požiadavkám. Niektoré organizácie zapájajú do testovania aj cieľových užívateľov, ktorí kontrolujú, či systém zodpovedá aj ich potrebám. Čím skôr sa totiž odhalia prípadné chyby v počítačovom systéme, tým menej nákladná je ich oprava. Z oddelenia pre zaistenie kvality sa aplikačný systém dostáva do uvádzacieho prostredia. Toto prostredie musí byť čo najpresnejšou kópiou skutočného prevádzkového prostredia. Uskutočňujeme v ňom záťažové testy, ktoré overujú, či sa budú hotová aplikácia a databáza chovať rozumne i pri nasadení do ostrej prevádzky. Často sa tu taktiež uskutočňuje školenie užívateľov, pretože prostredie je veľmi blízke cieľovému prostredie, v ktorom budú skutočne pracovať.

V dobe začatia konštrukčnej fázy má už databázový administrátor väčšinu práce za sebou. Pri prenose jednotlivých častí aplikačného systému z jedného prostredia do druhého sa musia preniesť aj databázové komponenty, ktoré aplikácia pre svoju činnosť potrebuje. Príkazy nevyhnutné pre zavedenie databázových komponentov do vývojového prostredia sa ale –našťastie – dajú zapísať do skriptu, ktorý potom využijeme vo všetkých nasledujúcich prostrediach. Pokiaľ avšak v rámci projektu rozširujeme existujúcu databázu alebo nahrádzame starší systém pre ukladanie dát, sú tieto prenosy zložitejšie, pretože musíme súčasne previesť všetky dáta z pôvodných záznamových štruktúr do nových. Dáta prežijú vždy dlhšie ako systémy. Preto aj s konvertovaním dát medzi starými a novými verziami systému sa budeme musieť stretávať pomerne často – niekedy to znamená jednoduché úpravy, ako je napríklad doplnenie novej tabuľky alebo stĺpca, inokedy však úpravy zložitejšie, ktoré – okrem programovania – zahŕňajú aj ďalšie práce. 

Obrázok 6.2: Hardvérové a softvérové prostredie pri vývoji.

Implementácia, či realizácia systému, znamená inštaláciu nových komponentov aplikačného systému (aplikačných programov, formulárov alebo webových stránok, zostáv, databázových objektov atď.) do živého systému, a uskutočnenie prípadného konvertovania dát. Nasadenie systému potom znamená jeho oživenie, uvedenie do prevádzky, kedy s novou aplikáciou začnú pracovať príslušné skupiny užívateľov. Niekedy je možné pristúpiť k okamžitému spusteniu nového projektu, čo znamená, že všetci užívatelia prechádzajú na novú verziu systému súčasne. Zložitejšie aplikácie alebo aplikácie s veľkým množstvom užívateľov je ale vhodnejšie zavádzať do prevádzky postupne, a tým znížiť riziká spojené s prechodom. Takýmto spôsobom v priebehu určitej doby súbežne pracuje stará aj nová verzia aplikácie, zatiaľ čo užívatelia po skupinách prechádzajú školením, a postupne sú zapájaní do nového systému – skupiny sú často definované podľa fyzického umiestenia pracoviska alebo podľa oddelenia.

• Priebežná podpora

Po implementácii nového aplikačného systému a databázy do ostrého, prevádzkového prostredia, sa často podpora aplikácie dostáva do rúk tímu prevádzkovej podpory. Tento tím musí byť schopný izolovať všetky možné problémy a reagovať na ne, či už ide o problémy s výkonom (rýchlosťou systému), neštandardné alebo neočakávané výsledky, úplné havárie alebo nevyhnutné pripomienky a podnety pre zlepšenie systému. Čo sa týka návrhov na zlepšenie systému, tie je najlepšie rozdeliť do kategórií, zoradiť podľa priorít, a následne ich zaradiť do budúcich projektov. Skutočné chyby v existujúcej aplikácii alebo databáze je ale nutné odstrániť podstatne skôr. Každá oprava chyby sa stáva akýmsi miniatúrnym projektom, v ktorom musíme znovu stúpiť do všetkých fáz životného cyklu. S uskutočnenými zmenami je nutné prinajmenšom aktualizovať taktiež aj dokumentáciu. Ako je možné vidieť aj na obrázku 6.2, ideálnym miestom pre hľadanie chýb a ich opravu je uvádzacie prostredie – chyby tak môžeme opraviť súbežne s vývojom najbližšieho nového rozšírenia (verzie) aplikačného systému, na ktorom pracujú vývojári vo vývojovom prostredí.

V prípade, že neurobíme nijaké zásadné chyby v priebehu návrhu databázy, nie je v tejto etape nutná ani príliš obsiahla databázová podpora. V etape priebežnej podpory nás skôr čakajú nasledujúce úlohy:

• Aplikovanie opráv a záplat v softvéri – najmä pokiaľ sa zistí, že príčinou problému sú chyby v samotnom softvéri relačného databázového systému od výrobcu.
• Vyladenie výkonu, napríklad presun dátových súborov alebo doplnenie indexu – týmito postupmi môžeme vyriešiť problémy spojené s výkonom v databáze.
• Sledovanie obsadeného miesta na disku a – pri náraste databázy – rozšírenie záznamového priestoru.
• Pri opravách niektorých chýb v aplikácii musíme siahnuť k pridaniu nového stĺpca do tabuliek alebo k zmene existujúcich stĺpcov. Hrubé chyby, ktorých oprava vyžaduje v databáze rozsiahle zmeny, by sme pri dostatočnom testovaní mali vylúčiť. Niektoré úpravy v aplikáciách môžu byť však vyvolané napríklad zmenami rôznych zákonov, nariadení, noriem a podobných predpisov, ktoré nie sú pod kontrolou užívateľskej organizácie. I tieto zmeny môžu viesť  k rozsiahlym zmenám v aplikácii a databáze.

Pretože projekty riadené klasickým životným cyklom spotrebujú – podľa častých názorov – príliš veľa času a prostriedkov, boli vyvinuté taktiež netradičné postupy, ktoré  sa v niektorých organizáciách používajú pomerne často. Medzi dva z najčastejších z týchto postupov patrí prototypovanie a rýchly vývoj aplikácií (Rapid Application Development, RAD).

Metóda prototypovania znamená stanovenie požiadaviek užívateľa pomocou rýchleho vývoja aplikácie pri využití množiny návrhových, vývojových a implementačných krokov. Do celého procesu vývoja sú výrazne zapojení cieľoví užívatelia. V extrémnej forme prototypovania je v priebehu bežnej pracovnej doby vedená porada s revíziou najnovšej iterácie danej aplikácie. Revízia ďalšej iterovanej verzie prebieha v nasledujúci pracovný deň.

V niektorých technikách prototypovania sa tieto postupy používajú počas celého vývoja až do ostrej, prevádzkovej verzie aplikácie a databázy. Pri tomto variante sa postupne zvyšuje miera podrobnosti spracovania iterácií, až sa z nej stane plne funkčná aplikácia. V prípade, že zvolíme túto cestu vývoja, prototypovanie nikdy neskončí, a dokonca aj po implementácii a nasadení systému majú ďalšie rozšírenia systému opäť formu prototypovania. Najčastejším „neduhom“ tejto implementačnej techniky je „vyhorenie“ vývojového tímu.

Ďalší variant prototypovania obmedzuje túto metódu len na definíciu požiadaviek. Akonáhle je hotový zoznam požiadaviek, ako aj všetky časti konceptuálneho modelu, s ktorými príde do styku užívateľ (teda užívateľské pohľady), dokončí sa zostatok projektu pomocou klasickej metódy životného cyklu. Firma IBM zaviedla túto metodológiu vo variante tzv. Joint Application Design (JAD), spoločného návrhu aplikácií, ktorý je vhodný najmä v situáciách, kedy sa požiadavky užívateľov dajú klasickými metódami len ťažko zistiť. Najväčším rizikom tohto variantu prototypovania je, že očakávania projektu nie sú stanovené a udržované v spolupráci s obchodnými zadávateľmi. Prototyp je viac-menej “fasádou” systému alebo “očný výter”, rovnako ako vo filme postavíte namiesto celého domu len kulisu vonkajšej fasády bez vnútrajška. Pokiaľ totiž títo ľudia nemajú odborné vedomosti, vôbec nechápu, akú prácu dá vlastný vývoj logiky a štruktúr pre ukladanie dát, ktoré budú tvoriť vnútorné mechanizmy cieľovej aplikácie, a bývajú často sklamaní, keď si uvedomia, že videli niečo, čo na prvý pohľad budí zdanie plne funkčnej aplikácie, ale v skutočnosti to bola len prázdna škrupina. V prípade, že realizujeme metódu prototypovania korektne, môžeme pomocou nej neobyčajne dobre stanoviť požiadavky užívateľov, a veľmi presne opísať taký aplikačný systém, ktorý užívatelia chcú a potrebujú.   

Technika rýchleho vývoja aplikácií (Rapid Application Development, RAD) je proces vývoja softvéru, pri ktorom je možné vybudovať funkčné aplikačné systémy za 60-90 dní. Potrebných kompromisov sa často dosahuje pomocou tzv. Paretovho pravidla 80/20, podľa ktorého je možné 80 % práce zvládnuť za 20 % času (a naopak). Ostatných 20 % práce, ktoré tvorí napríklad komplikované a pracné ošetrenie výnimiek, je možné v záujme rýchleho dodania funkčného systému zo začiatku vynechať. V prípade, že celý proces následne opakujeme nad rovnakou množinou požiadaviek, vybudujeme nakoniec systém, ktorý spĺňa 100 % požiadaviek, a to podobným spôsobom, ako je prototypovanie.

Metóda RAD nie je vhodná pre kontrolu časového plánu alebo rozpočtu projektov, a fakticky je u nej nutné mať takého manažéra projektu, ktorý je dostatočne skúsený a ktorý má riadenie času a nákladov veľmi dobre pod kontrolou. Metóda RAD je užitočná predovšetkým v situáciách, kedy je rýchle nasadenie “nejakého” systému dôležitejšie ako kvalita produktu meraná v súlade so všetkými známymi požiadavkami.