Životný cyklus

Vývoj softwaru nie vždy spadá do kategórie „ideálnych procesov". Každému vyhovujú iné pravidlá, niekomu dokonca žiadne. Ťažko však hovoriť o pravom a univerzálnom spôsobe, pretože rôzne techniky majú svoje výhody, ktoré môžu byť v špecifických prípadoch nevýhodami a opačne. Tak si popíšme nejaké tie základné modely.

Chcem ešte upozorniť na prílohy, ktoré budú od tohto článku uvedené ako URL na zbalený súbor (na konci). Budú sa v nich nachádzať obrázky v 100% kvalite, zdrojové kódy a všetko ostatné, čo sa bude týkať konkrétnej časti.

Model Big Bang

Pomenovanie tohto modelu podľa známej teórie vzniku vesmíru možno nie je najšťastnejšie, keďže prísne pravidla fyziky, matematiky a prírody sú úplným protikladom voči tomu chaotickému riešeniu.

Tento model sa môže zdať zbytočný, ale fakticky existuje. Všetka energia vývoja sa sústredí na programovanie. Neexistuje žiadna špecifikácia ani analýza. Potom sú dve možné riešenia. Buď z celého projektu vnikne (ne)fungujúce niečo alebo to, čo sme si predsavzali. V mnohých publikáciách sa dočítame, že takýto proces tvorby softwaru je takmer dokonalý pre menšie projekty - osobne s ním nemám veľa skúsenosti.

^{_{Obrázok 1 Model Bing Bang}}

Model „Programuj a opravuj"

Asi najčastejší prístup tvorby aplikácii je model „Programuj a opravuj". Jedná sa o podobne jednoduchý proces vývoja programov, ako pri prvom modeli. Obvykle sa začína s určitou predstavou o probléme a tak sa nasadzujú základné pravidlá špecifikácie, programovanie a testovanie konkrétnej časti.

Veľká výhoda tohto modelu spočíva v okamžitom možnom prezentovaní (nejakého) výsledku už v prvých štádiách vývoja. Nevýhodou je mnoho chýb vo výslednom projekte (teda skôr chybičiek) a možný „črepinový efekt", ktorý je známy prevažne betatesterom programov.

Ak sa program vyvíja po takýchto kúskoch, ktoré sú dokonalé odladené jednotlivo a „poskladané" dokopy, celok ešte nemusí fungovať správne. Známy je príklad jedného projektu NASA, keď sa sonda skladala z kúskov tvorených kade tade po svete. Pri „vystrelení" sondy sa však začala správať nekorektne a úplne sa odklonila od kurzu. Vtedy bol problém v desatinom separátore (ak sa dobre pamätám). Predstavme si, že by výpočet kurzu bol tvorený v krajinách s „desatinou čiarkou", pričom anglosaské národy používajú „desatinu bodku"...

Tento model je špecifický aj tým, že veľmi ťažko sa projekt uzatvára. Keďže výsledok na začiatku bol pomerne hmlistý, vývojári nevedia, či dosiahli svoj cieľ, alebo aplikácia ho zbytočne prekročila.

Model vodopádu

Tento spôsob patrí medzi prvé modely, ktoré sa vyučujú pri tvorbe softwaru. Je to učebnicový príklad, ktorý ma mnoho výhod, ale k dokonalosti rovnako ďaleko ako jeho ostatní kolegovia.

Jedná sa o „vrstevnatú" tvorbu, kedy vývoj prebieha v určitých štádiách. Prechádza sa analýzou, potom inými procesmi, samotným kódením, testovaním a výsledným produktom. Z hľadiska prístupu sa to môže javiť dokonale, ale takýmto vývojom jednotlivé frakcia týmu buď pracujú alebo oddychujú.

Ďalším, zásadným problémom, je fakt, že nemôžeme v jednotlivých častiach vývoja vynechať nijakú časť, pretože by to na výsledný projekt mohlo pôsobiť katastrofálne. Tiež už nie je návratu, ak sa chcú udiať nejaké zmeny v špecifikácia a my sme už vo fáze vývoja.

Zaujímavé je, že samotné programovanie sa kladie len ako jeden malinký dielik a najväčšiu časť zaberá analýza problému. Čo sa týka testovania, tento model je ideálny - existuje dokonale vypracovaný plán, dokumentácia, software je už „na stole" - ale ako bolo už spomínané, v prípade nájdenia závažnej chyby už v analýze, znamená, že projekt pôjde do sveta chybný alebo sa začne vývoj od začiatku.

Tu by som chcel preto zdôrazniť nenormálne veľký význam testerov, ktorí okrem „odklikávania" plnia úlohu kontroly špecifikácia apod. Je to akýsi audit, ktorý ale nie je vhodné implementovať na koniec, lebo výsledok by mohol byť deštruktívny...

_{Obrázok 2 Model vodopád}

Špirálový model

V mnohých dokonale riadených projektoch je vodopádový model ideálnym riešením. Tam, kde nie je, sa začali vytvárali rôzne alternatívy a medzi nimi vznikla aj tzv. „špirála" (alebo organizácia ACM - Association for Computing Mechinery - ho pomenovala ako A Spiral Model of Software Development and Enhancement). Tento model vznikol niekedy v polovici osemdesiatych rokov a ukázal sa, že je veľmi efektívny.

Všímajme si rôzne paralely medzi systémami, ktoré sme už spomínali. Na začiatku sa vytvoria základné definície, pošlú sa zákazníkovi, ten pošle pripomienky a po ich spracovaní a vyhodnotení sa prechádza na ďalší stupeň vývoja.

_{Obrázok 3 Model špirály}

Takýto model ma aspoň nejakú z predchádzajúcich vlastností modelov. Odbúrava sa aj zapojenie testerov do záverečnej fázy, nachádza sa istá forma analýzy a výhody modulu „Opravuj a programuj".

Medzi vývojármi sa teší pomerne veľkej obľube, ale nie u všetkých. Taktiež tu existuje množstvo nevýhod, okrem iného aj fakt, že jednotlivé „zákruty" (cháp cykly) vývoja sa neskôr môžu ukázať ako zbytočné. Tak vyšlo úsilie týmu na týchto častiach nazmar (nehovoriac o finančných dopadoch). A ak je takéto zistenie problému väčšieho charakteru, môže spôsobiť krach celého projektu podobne, ako pri vodopáde (s tým, že tu sa na to príde pomerne skoro - tu vidno, že nielen dobré vlastnosti si špirála so sebou nabalila od ostatných, ale aj ich nedostatky).

Evolučný vývojový model

Jedná sa o akýsi hybridný model vývoja. V prvom štádiu sa vrstevnatou metódou zisťuje analýza celého projektu a až potom sa s drobnými obmenami prechádza na špirálový model.

Teda najprv vytvoríme analýzu (podobne ako sme urobili my). Potom sa navrhujú časti systému - teda architektúra návrhu. Problém sa rozloží do jednotlivých malých „podproblémov" (napríklad moduly, komponenty) a tie sa začnú vyvíjať špirálou, pozostávajúc z cyklu:

1. Podrobný návrh
2. Plán a rozpočet
3. Zostavenie
4. Integrácia
5. Testovanie
6. Nasadenie

Môžeme naraziť na problém aktuálnosti špecifikácie, keďže prebehla na začiatku. V prípade zmien si ale musíme uvedomiť, že nemeníme molocha, ale jednotlivé komponenty a ak sa na toto nezabudne pri analýze, z tohto problému sa stáva triviálna záležitosť.

Inštalácia MySQL

Aby sme mohli vytvárať databázovú aplikáciu, budeme potrebovať databázu, čo nie je nič iné, ako aplikácia. Niektorí možno budú mať problémy s inštaláciu a tak si ju krok po kroku popíšeme. Zatiaľ nám bude stačiť staručká verzia MySQL, ktorú si môžete zadarmo downloadnúť odtiaľ:

/download/user/mysql-3.23.54-win.zip

Po rozbalení a následnom spustení súboru setup.exe nás privíta obrazovka s oknom, ktoré len potvrdíme enterom:

_{Obrázok 4 Inštalácia MySQL 1}

A analogicky odklikáme zvyšné okná, ako ukazuje obrázok:

_{Obrázok 5 Inštalácia MySQL 2}

Teraz musíme zabezpečiť spúšťanie služby v systéme. Nájdeme si program WinMySQLAdmin.exe v ceste c:MySQLbin:

_{Obrázok 6 Spúšťanie MySQL ako službu a proces}

Kde sa nám zobrazí okno, ktorého údaje vyplníme ľubovoľne. Napríklad login aj heslo zadáme root a potvrdíme tlačidlom OK:

_{Obrázok 7 Nastavovanie údajov MySQL}

Teraz sa služba bude spúšťať po každom štarte OS a znamením je ikonka „semaforu" v tray:

_{Obrázok 8 MySQL po štarte OS}

O úspešnosti inštalácie sa presvedčíme spustením programu MySQL.exe, v ceste ako sa nachádza WinMySQLAdmin.exe:

_{Obrázok 9 Spustenie konzoly MySQL}

Príloha k článku

 

Neprehliadnite:

• Akcie, letáky a zľavy
• Pôžičky a úvery pre všetkých
• Turistický sprievodca Budapešťou
• Turistický sprievodca Košicami
• Turistický sprievodca Londýnom
• Turistický sprievodca Prahou
• Turistický sprievodca Viedňou
• Turistický sprievodca Slovenskom

Pozrite si tiež:

«  Webhosting Inet.sk: Three Happy

Mediahost.sk  »