Jak dělat web?

25. listopadu 2002

•

Asi většina čtenářů Intervalu se již sama pokoušela o vytvoření nějakého jednoduššího nebo složitějšího webového projektu. Pokusím se jednoduše a srozumitelně nastínit, co kompletní vytvoření nějaké webové aplikace obnáší, co musí nutně takové akci předcházet, jak potom probíhá a co nás čeká po zdánlivém dokončení projektu.

Rozhodně můj postup berte pouze jako doporučený, nikoliv jako jednotný návod pro všechny. Je pravděpodobné, že každý projekt bude mít svá specifika, na které bude potřeba v realizaci projektu vzít zřetel. V článku nebudu uvažovat nad tím, zda projekt tvoří jeden člověk nebo více osob. Řada principů je stejná nezávisle na počtu vývojářů.

Aby nedošlo k nějakým nedorozuměním, v následujícím textu budu používat spíše pojmy projekt a informační systém, resp. systém, než webový projekt, web, webová aplikace.

Osnova projektu

Na úvod v jednoduchém přehledu uvedu v několika bodech, z jakých fází se celý projekt skládá. Zjednodušený pohled rozděluje celý vývoj a provoz informačního systému do tří základních fází: analýza, implementace a provoz. Nelze říci, že by jedna část byla důležitější, než jiná, ale na druhou stranu analýza je velmi klíčovou fází. Pokud v ní uděláme zásadní chybu, může to mít za následek zkrachování celého projektu. Pokud je systém dobře navržen a udělá se chyba v implementaci, není tak těžké něco přeprogramovat (ve srovnání s důsledky chyb v analýze systému).

Analýza systému
- definování účelu projektu
- průzkum trhu
- specifikace požadavků
- funkční analýza
- návrh datového modelu
- volba vhodných programových a databázových nástrojů
- časový plán
- financování projektu

Implementace systému
- naprogramování subsystémů
- testování a ladění subsystémů

Provoz systému
- nasazení systému, testovací provoz
- ostrý provoz
- údržba systému, aktualizace, support

Tvorba dokumentace

Ještě než se pustím do popisu konkrétních bodů, dovolím si vyzdvihnout důležitost tvorby dokumentace, a to v libovolné fázi vývoje systému. Tato věc bývá někdy opomíjena a v budoucnosti to může mít katastrofální důsledky. V analytické části dokumentu, který vytvoříme, říkáme projektová studie. Obsahuje všechny informace z analytické části.

Programátor (nebo programátoři), který implementuje jednotlivé části systému vytváří tzv. technickou dokumentaci. Ta obsahuje slovní popis jednotlivých modulů (částí), definovaných funkcí, použítých SQL dotazů a podobně. Vedle toho sem patří i komentáře ve zdrojových kódech. Ty mají několik opodstatnění. Jednak se může stát, že projekt převezme někdo jiný, tj. někdo jiný bude něco ve zdrojových kódech doprogramovávat nebo cokoliv upravovat. Takový nový programátor, kromě vlastní technické dokumentace, zcela jistě ocení přehledné komentáře přímo ve zdrojovém kódu. Komentáře oceníte ale i vy, když se do zdrojového kódu podíváte za půl roku. Mám již za sebou desítky rozsáhlejších programů a mohu z vlastní zkušenosti potvrdit, že komentáře ve zdrojových kódech jsou opravdu velmi cennou pomůckou.

Co se týká provozu systému, je vhodné mít něco jako provozní deník, do kterého se zaznamenávají všechny chyby a zvláštnosti, včetně časového údaje a výpisu chybové hlášky. Pokud pak uživatel hlásí nějakou chybu, tyto údaje vám pomohou v diagnostice problému. Provozní deník samozřejmě najde uplatnění například ve firmě, pro kterou jste udělali informační systém. Pokud půjde o nějaký portál na internetu, pak je potřeba návštěvníky stránek naučit posílat zprávy o chybách takovým způsobem, ze kterého vám bude zřejmé, jaká chyba nastala. Jistě mi dáte za pravdu, že pokud uživatel napíše text e-mailu ve stylu Ahoj, nefunguje to. Diky za napravu, tak z toho asi nepoznáte, kde chyba nastala.

Analýza systému

Analýza systému je první a velmi důležitou fází. Zde se zatím oprostíme od jakýchkoliv implementačních detailů, a soustředíme se čistě na „teoretický“ návrh systému. Pro tuto fázi je typické, že návrhář stráví spoustu času s papírem a tužkou v ruce, spousta náčrtků, schémat, diagramů. Je to také období komunikace. Cílem této fáze je dokonale porozumět zadání, tedy tomu, co chceme dělat. Musíme velmi dobře znát potřeby uživatelů. Na to, jak tyto potřeby zjistit, se blíže podívám v části věnované specifikaci požadavků.

Všechny části analýzy systému musí být zdokumentovány, soubor všech dokumentů tvoří projektovou studii. Podle rozsahu projektu obsahuje dokumentace řádově stránky až desítky stránek.

Účel projektu

Definování účelu projektu není nic jiného, než si sednout a říct si, co vlastně chceme dělat. Zatím nic konkrétního, žádné konkrétní zadání, to bude následovat až v dalších fázích. Tato fáze je tedy relativně krátká, ale je nutná pro průzkum trhu, který hned následuje. Zde si v podstatě uvědomíme jakýsi „typ“ projektu, co chceme dělat. Jakého oboru se týká? Jakou formu by měl mít (diskusní fórum, magazín s denním vycházením článků aj.)?

Průzkum trhu

Máme-li alespoň hrubou představu, co chceme udělat, můžeme vyrazit na průzkum trhu. Bavíme-li se o webových aplikacích, vyrazíme nejspíše na internet a pořádně se porozhlédneme, jak to vypadá s již existujícími projekty stejného nebo podobného zaměření. Pokud po důkladném prozkoumání zjistíme, že nic podobného zatím neexistuje, máme vyhráno a můžeme se pustit do práce. Na druhou stranu, pokud zjistíme, že podobný projekt již existuje (a to bude velmi pravděpodobné), nemusíme to hned vzdávat. Máme možnost se seznámit s konkurenčním projektem, eventuelně zjistit jeho nedostatky, co je tam uděláno třeba hůře, co tam například chybí. Pak se můžeme zamyslet nad tím, v čem by byla přidaná hodnota našeho projektu, v čem by náš projekt byl lepší než ten dosavadní konkurenční. Je jasné, že prosazení projektu bude v tomto případě bude těžší, než v tom předchozím, ale nic není dopředu ztraceno.

Specifikace požadavků

Máme-li za sebou průzkum trhu, už víme, jestli budeme vytvářet nový systém nebo konkurenční systém, můžeme přejít ke specifikaci požadavků. Jedná se v podstatě o konkrétní zadání celého systému. Tato fáze je asi nejtěžší. Je velmi důležité získat přehled o potřebách uživatelů. Pro získání těchto poznatků můžeme využít například různých anket nebo dotazníků. Osobně za nejúčinnější metodu považuji tzv. formovací semináře, které spočívají v setkání návrhářů systému s koncovým uživatelem. Vedení aktivní diskuse, kladení spousty otázek (byť se některé mohou na první pohled zdát nepodstatné!). Kámen úrazu ale spočívá v tom, že uživatel málokdy přesně ví, co chce. Většinou má jen hrubou představu a záleží na vašem talentu, jak se vám podaří vše precizně specifikovat.

Ne vždy ovšem lze formovací seminář zrealizovat. Pokud budeme vytvářet portál na internetu, těžko se nám podaří realizovat setkání s potenciálními uživateli našeho portálu. Pak je dobré si o tom promluvit třeba s kolegy apod. Pokud necháte specifikaci požadavků čistě jen na sobě, může se stát, že buď na něco zapomenete, nebo něco zrealizujete takovým způsobem, že vy tomu budete sice rozumět dobře, ale jiní lidé už nikoli.

Výstupem specifikace požadavků může být jednostránkový dokument, ve kterém bude v několika odstavcích slovně popsáno, co má systém umět. Dovolím si zde uvést specifikaci požadavků z článků o tvorbě fotoalba, který před nedávnem na Interval.cz vyšel:

Příklad: specifikace požadavků (Fotoalbum v PHP, 1. díl)

…album mělo nabízet roztřídění fotografií do jednotlivých kolekcí, chronologicky uspořádaných dle data. Každá kolekce fotografií bude mít svůj název (např. „Dovolená ve Španělsku (2001)“).
Uživatel si bude moci v jednotlivých kolekcích listovat, klikne na název a zobrazí se mu kolekce fotek, kterou bude chtít vidět. Nebudou se načítat naráz všechny fotografie v plné velikosti, ale zobrazí se seznam zmenšených obrázků (takzvaných thumbnailů), a teprve kliknutí na některý z nich zobrazí fotografii v původní velikosti. Protože fotografií z nějaké akce může být velmi mnoho, bude lepší rozdělit každou kolekci na jednotlivé listy (například po 9 fotografiích).
Každá fotografie bude mít svůj popisek a datum pořízení. Dle svého uvážení budete moci jednoduše rozšířit databázi o další údaje, například jakým fotoaparátem byla fotografie pořízena, na jaký film a podobně. Podle popisku bude uživateli umožněno vyhledávání fotografií v albu. Výsledek hledání bude zobrazen v podobě sady náhledů.
Nakonec, když budete chtít album nahrát někomu na CD, budete mít dvě možnosti – buď dáte k dispozici přímo webovou aplikaci v PHP, kterou si daný uživatel zprovozní na svém lokálním www serveru, nebo naprogramujete funkci pro automatické vygenerování off-line verze alba s fotografiemi, kterou pak uložíte na CD. Off-line verze bude vypadat úplně stejně jako výše zmíněná webová aplikace s tím rozdílem, že zde nebude možnost fotografie vyhledávat.

Funkční analýza

Na specifikaci požadavků plynule navazuje funkční analýza. Cílem je zamyslet se nad tím, jak výše zmíněné požadavky zrealizovat pomocí funkcí, které bude systém nabízet. V podstatě se „přeloží“ ona slohová práce do heslovitých bodů. Nejlépe to bude asi vidět na následujícím příkladě. Vezmu požadavky na fotoalbum a provedu jednoduchou funkční analýzu:

Příklad: funkční analýza (Fotoalbum v PHP, 1. díl)

…systém by měl obsahovat následující funkce:
– uspořádání fotografií dle data do jednotlivých kolekcí
– zobrazení vybraných kolekcí fotografií
– jednoduché vyhledávání podle údajů o fotografiích
– založení a nahrání nové kolekce do fotoalba
– přidání nové (zrušení staré) fotografie
– automatické vygenerování off-line verze fotoalba

Návrh datového modelu

Tento článek poskytuje základní přehled, proto nebudu zabíhat do detailů. Návrhu datového modelu odborně říkáme datové modelování. Používají se k tomu různé metodiky a nástroje (někteří z vás budou možná znát například tzv. ER diagramy, nebo relativně nový jazyk UML). Jednoduše řečeno, musíte v této fázi navrhnout databázi (neboli fyzický datový model) na základě požadavků uživatelů, respektive provedené funkční analýzy. Databáze musí být navržena tak, aby po informační stránce pokryla všechny údaje, které potřebujeme evidovat k provozu systému. Je samozřejmé, že návrh databáze musí být optimální, jinými slovy, tabulky musí splňovat tzv. normální formy (co to jsou normální formy a jak tabulky optimálně navrhovat se dočtete v článcích Databáze a SQL a Tvorba tabulek v SQL, které vyšly na Interval.cz v létě 2000).

Příklad: návrh databáze (Fotoalbum v PHP, 1. díl)

Vlastní návrh tabulek lze doplnit informací zpřesňující takzvanou sémantiku (význam) jednotlivých položek.

Tabulka Kolekce
Každá kolekce fotografií bude mít svůj název, rok, datum konání (může zde být od-do), kolik obsahuje celkem fotografií, po kolika fotografiích se mají zobrazovat jednotlivé části kolekce.
create table KOLEKCE (
ID integer not null,
NAZEV varchar(80) not null,
POCET integer,
ROK varchar(4) not null,
DOBA varchar(30),
CAST integer default -1,
ADRESAR varchar(80) not null,
primary key (ID)
);
Pokud položka CAST bude mít hodnotu -1, znamená to, že neurčujete, po kolika fotografiích se má kolekce na jednotlivých stránkách zobrazovat, zobrazí se vždy celá kolekce fotografií na jedné stránce (v opačném případě se kolekce fotografií bude zobrazovat právě po tolika fotografiích, kolik bude určovat hodnota atributu CAST). Atribut ADRESAR určuje adresář, ve kterém budou fotografie dané kolekce uloženy.
Tabulka Fotka
Tabulka FOTKA bude sdružovat záznamy o jednotlivých fotografiích. Jak jsem už nastínil, u každé bude evidován název (popisek), klíčová slova a datum. Dále je potřeba zaznamenat vazbu na příslušnou kolekci a jméno fyzického souboru na disku (jak plné velikosti fotografie, tak i jejího thumbnailu).
create table FOTKA (
ID integer not null,
KOLEKCE_ID integer,
POPIS varchar(80),
DATUM date,
THUMB varchar(80) not null,
PHOTO varchar(80) not null,
primary key (ID),
foreign key (KOLEKCE_ID) references KOLEKCE (ID),
);

Volba programovacího a databázového nástroje

Když víme, co máme programovat, když máme navržený dobrý datový model, je ten správný okamžik, kdy se rozhodnout pro určitý programovací nástroj a databázový systém. Protože by toto téma mělo být samostatně zpracované v článku na Interval.cz, nebudu opět zabíhat do velkých detailů. Je jasné, že při volbě nástrojů budeme ovlivněni nejen tím, co nám dané nástroje nabízí, ale velmi významné bude také finanční hledisko. Velmi důležitým kritériem by měla být hlavně rychlost zpracování a objem zpracovatelných dat (takzvaná časová a prostorová složitost).

Příklad: volba nástrojů (Fotoalbum v PHP, 1. díl)

Vezmu-li příklad fotoalba, který zde v průběhu článku uvádím, zde jsem jako programovací nástroj volil jazyk PHP verze 4.0 a za databázový systém jsem „zvolil“ MySQL.

Časový plán

Připravit dobrý časový plán je poměrně obtížné. Zde je potřeba už mít nějaké zkušenosti a mít dobrý odhad na to, jak dlouho může daná fáze trvat. Také velmi záleží na tom, jak rozsáhlý systém připravujete. Pokud děláte nějaký malý projekt, pak vám analýza systému může zabrat řádově dny až týdny, v případě rozsáhlejších projektů řádově týdny až měsíce. S částí implementační je to velmi podobné. A nakonec doba testovacího provozu a délky supportu je také závislá na rozsahu projektu. Výstupem v této části analýzy by měl být zhruba jednostránkový dokument, který obsahuje konkrétní data (nebo přibližná období, jak dlouho dané fáze budou trvat). Někdy se také používají jako jednotky člověkodny.

Příklad: časový plán (Fotoalbum v PHP, 1. díl)

Fotoalbum nebyl nijak náročný systém, reálný časový plán by mohl vypadat takto:

– formulace zadání, specifikace požadavků, funkční analýza … 5 člověkodní
– datový model … 5 člověkodní
– naprogramování aplikací … 15 člověkodní
– ladění, testování, nasazení do provozu … 10 dní

Financování projektu

Výstupem je přehled veškerých financí, které se do projektu vloží. Měla by zde být obsažena i případná návratnost investic. Samozřejmě může jít o projekt, který je „zadarmo“, pak tato část analýzy systému bude vypuštěna. Pokud uvažujete o sponzorech vašeho projektu, je potřeba mít k dispozici zpracovaný rozpočet. Je velmi pravděpodobné, že právě část „financování projektu“ ve vaší projektové studii bude první částí, která bude sponzory zajímat. Pokud řešení finančních otázek není, tak jako u mě, vaši silnou stránkou, je vhodné si přizvat na pomoc nějakého odborníka – ekonoma.

Implementace systému

Dílčí části naprogramování systému lze rozdělit mezi více programátorů. Pak je potřeba, aby byla jedna osoba, která bude všechny zdrojové kódy nějakým způsobem shromažďovat a „slaďovat“ dohromady. Je několik možností, jak systém postupně vytvářet. Nejvíce se mi vyplatil systém tzv. modulárního přístupu. Naprogramuje se jádro systému (např. základní funkce pro přístup k databázi, pro autentizaci uživatele apod.) a na toto jádro se pak postupně „nabalují“ jednotlivé části systému. Každá část zde funguje jako samostatný modul, který je přidán do systému po té, jakmile je naprogramován a otestován. Pozor! Pokud vám zavedení nového modulu do systému vyvolá úpravy v jiných, již zaběhnutých modulech, pak máte něco špatně. A s největší pravděpodobností bude chyba v návrhu datového modelu.

Naprogramování subsystémů

O tom, jak máte něco programovat, nemá smysl psát, každý programátor má svůj styl. Pokud ale programujete ve větším počtu lidí, je potřeba dohodnout nějaké základní konvence (např. již zmíněné používání komentářů). Důležitá je tvorba dokumentace, o které jsem více mluvil na začátku tohoto článku. Součástí každé aplikace by měla být stručná (případně i podrobná) nápověda.

V závislosti na rozsahu systému se lze setkat i s návody pro programátory. Možná namítnete, k čemu je to dobré, ale pokud při vývoji aplikací mají všichni používat nějaké standardy, šablony, určitý typ značkování a podobně, není nic jednoduššího, než zhotovit dokumentaci pro vývojáře a každý programátor si ji prostě nastuduje.

Testování a ladění subsystémů

Hotovou část systému je nejlepší dát k otestování jiné osobě než té, která danou část programovala. Zvýší se tím pravděpodobnost odhalení případných chyb. Dále je vhodné si vytvořit databázi imaginárních dat a zkusit otestovat, jak se bude systém chovat při předpokládaném množství dat (mluvím zde například o stovkách tisíc záznamů). Testování chování aplikace při takovém velkém množství dat lze chápat jako určitý druh zátěžových zkoušek. Ty je vždy dobré provádět, o jejich provedení by měl být vyhotoven protokol.

Pokud zátěžové zkoušky v nějakém sledovaném kritériu dopadnou špatně, pak to znamená, že jsme kdekoliv v průběhu vývoje systému mohli udělat chybu. Nebo jsme jen špatně vybrali programovací nástroj či databázový systém.

Provoz systému

Testovací a ostrý provoz

Pokud si někdo myslí, že naprogramováním celého systému a uvedením do provozu jeho práce končí, je na omylu. Alespoň v době testovacího provozu je potřeba počítat s tím, že uživatelé budou zasílat hlášení různých drobných chyb a závad. Pokud se jedná o webovou aplikaci, je vhodné (ne-li přímo nutné), aby na stránkách byl jednoznačně uvedený e-mail nebo telefonní kontakt, kam mohou uživatelé směrovat svoje dotazy.

Support

Jako vývojáři informačního systému musíte zajistit uživateli nějaký support. Sem patří, kromě reakce na průběžné chyby a závady, také například otázka zálohování dat a zabezpečení dat. Vše závisí na domluvě s koncovým zákazníkem. Pokud se jedná o web, pak je na vás, jak často budete zálohovat a jaké bezpečnostní politiky si nastavíte, aby váš systém fungoval a byl spolehlivý.

Tímto článkem jsem se snažil dát základní přehled, co všechno obnáší tvorba projektu. Některé části jsem podložil i praktickou ukázkou z článku Fotoalbum v PHP, 1. díl. Další praktické poznámky ke tvorbě informačních systémů můžete najít v článku Jak na vlastní katalog stránek v PHP? – začínáme.