Webes alkalmazások tervezési módszerei és eszközei

Alkalmazás tervezése

Egy webes alkalmazás fejlesztése során nagyon sok kérdésre választ kell kapnunk. Néhány ezek közül:

• Pontosan milyen oldalak lesznek?
• Milyen adatok jelenjenek meg az oldalakon?
• Hogyan nézzenek ki ezek az oldalak? (sablon)
• Milyen összefüggésben vannak ezek az oldalak? (oldaltérkép)
• Hogyan azonosítjuk a felhasználókat? (azonosítás, autentikáció)
• Milyen műveleteket és oldalakat érhetnek el az azonosítatlan és azonosított felhasználók? (szerepkörök, autorizálás)
• Melyek az egyes oldalak adatigényei? (modell felépítése, körvonalazása)
• Milyen struktúrában, hogyan tároljuk az adatokat? (adatbázis)
• Milyen eszközök támogatottak? (asztali böngésző, mobil kliensek)

Ezekre a kérdésekre (és még talán egyéb felvetődött kérdésekre) mind válaszolnunk kell AZELŐTT, hogy a konkrét fejlesztésekbe belekezdenénk. Részletes tervezéssel sok későbbi felesleges munkát kiküszöbölhetünk. Ugyanakkor ne áltassuk magunkat: fejlesztés közben vagy akár az alkalmazás (főleg webes alkalmazás) használata közben sok olyan igény felmerülhet, amely az eredeti koncepciónkat megváltoztathatja, felboríthatja.

Nézzük végig módszeresen az egyes tervezési szempontokat:

• követelmények összegyűjtése, követelményanalízis
• szerepkörök, használati esetek, folyamatok meghatározása
• oldalfunkciók
• site struktúra (oldaltérkép)
• architektúra terv
• oldalvázlatok készítése
• adatbázis tervezése
• designtervek készítése.

Követelmények összegyűjtése

Ebben a fázisban a fejlesztő(csapat) felméri, összegyűjti a megrendelő funkcionális és nem funkcionális igényeit, elvárásait, ez alapján meghatározza, vagy közösen meghatározzák az elvárandó funkciókat, definiálják a marketing- és stratégiai célokat.

A további tervezési lépések az összegyűjtött követelményekre épülnek, azok kifejtéseinek, fejlesztési szempontból részletezéseinek tekinthetőek.

A követelmények összegyűjtésének célja az alábbiak meghatározása, figyelembe véve a rendelkezésre álló erőforrásokat.

• a szükséges emberi, szoftveres, hardveres erőforrások,
• elérendő célok, haszon,
• a szükséges idő,
• költségek,
• egyéb szervezeti elvárások,
• a szükséges feladatok, lépések.

Vissza a tartalomjegyzékhez

Funkcionális követelmények

Itt a biztosítandó szolgáltatások ismertetése, rövid leírása következik.

A későbbiekben egy blogrendszer megvalósításán dolgozunk, erre például a következő funkcionális követelményeket fogalmazhatjuk meg:

• Az adminisztrátor WYSIWYG-szerkesztő segítségével tudjon blogbejegyzéseket és oldalakat publikálni.
• A bejegyzéseket különböző kategóriákba lehessen sorolni az adminisztrációs felületen!
• Az adminisztrátor jelölhesse meg azon bejegyzéseket (kiemelt bejegyzések), amelyet fő helyen szeretne elhelyezni a kezdőlapon!
• A blogbejegyzések között lehessen keresni szabadszavas kereső segítségével! A kereső minden oldalon elérhető legyen!
• A bejegyzéseket lehessen kategória szerint szűrni!
• A bejegyzésekhez tartozzon RSS-csatorna!
• A bejegyzésekhez felhasználói regisztráció után lehessen hozzászólni!
• A blog kezdőlapján legyenek elkülönítve a kiemelt és további bejegyzések! A kiemelt bejegyzések hangsúlyosabban jelenjenek meg!
• Minden bejegyzéshez tartozzon egy (egységes méretű) figyelemfelhívó kép!
• Legyen oldalsáv, ahol a menüpontok, és más blokkok (pl. címkefelhő, legutóbbi bejegyzések, utolsó hozzászólások) elérhetőek!
• A kezdőlapon csak a bejegyzések bevezetője legyen olvasható, ha a bejegyzés címére kattintunk, akkor legyen olvasható a teljes bejegyzés!
• Minden oldalon legyen lábléc, amelyben az alábbi információkra mutató linkek kapjanak helyet: Jogi nyilatkozat, Impresszum, Kapcsolat, Oldaltérkép!
• A menüpontokat egyszerűen módosítani/bővíteni lehessen az adminisztrációs felületen!

Vissza a tartalomjegyzékhez

Nem funkcionális követelmények

A jellemzően nem funkcionális követelményeket, azaz megszorítások a szolgáltatásokra (funkciók) érdemes kategorizálni, legalább az alábbi kategóriák szerint:

• Használhatóság: a felhasználó szempontjából vizsgált elvárások. A követelményeket használhatósági tesztekkel tudjuk ellenőrizni.
• Teljesítmény: olyan a teljesítményre (pl.: elvárt válaszidők, párhuzamosan kiszolgált kérések száma) vonatkozó elvárások, melyeket teljesítménytesztekkel, terheléses tesztekkel ellenőrizni tudunk.
• Rendelkezésre állás: több esetben százalékban megadott érték. A 99%-os rendelkezésre állás azt jelenti, hogy a felhasználók az esetek 99%-ban elérik a szolgáltatásokat. Többnyire része a Szolgáltatási Szint Megállapodásnak (SLA: Service Level Agreement ). Jellemzően szolgáltatás-mérési mutató. Mérésének ellenőrzésére egyszerűen alkalmazhatóak a szerver naplóállományai (logok).
• Skálázhatóság: a rendszer növekedéséből fakadóan milyen bővítéseket kell tennünk, például milyen szervereket kell üzembe helyezni. Jellemzően az elvárt teljesítményből határozhatjuk meg.
• Biztonság: adatvédelmi elvárások meghatározása. Webes alkalmazások biztonsági tesztelése nem egyszerű feladat, az alkalmazás normál működésén alapulva megpróbálunk ártalmas tevékenységet véghezvinni, azaz például személyes adatokat próbálunk megszerezni, módosítjuk az oldal tartalmát, esetleg összeomlasztjuk a rendszert.
• Karbantarthatóság: olyan, a megbízó által adott elvárások, melyek az alkalmazás üzemeltetésével, karbantartásával, bővítésével kapcsolatosak.

Természetesen megadhatunk egyéb kategóriákat is, például:

• Vevői megszorítások: a megrendelő által kért – jellemzően nem technológiai – további megszorítások.
• Technológiai elvárások, megszorítások fejlesztői oldalról: olyan technológiai döntések, melyeket már a projekt követelmény-felméréseikor rögzítünk. Ezen megszorítások adódhatnak a rendelkezésre álló erőforrásokból. Jelen jegyzetben arra törekszünk, hogy technológiai döntéseinket a későbbiekben hozzuk meg, azokat indokolva. Ilyen lehet azonban, ha már a projekt elején kijelentjük, hogy például a PHP-t választjuk fejlesztői környezetnek.
• Minőségi elvárások felhasználói oldalról: olyan minőségi elvárások – jellemzően a használhatóságon felül, de sokszor azzal összefüggésben –, melyeket nem a megbízó, nem is a fejlesztő, hanem a majdani felhasználó minőségi, kényelmi stb. szempontjai miatt vezetünk be.

Alkalmazásunkkal szemben támasztott nem funkcionális igények lehetnek például az alábbiak:

• Használhatóság: a látogatók által elért felület legyen jól átlátható, önmagyarázó (egy átlagos látogató felhasználói dokumentáció nélkül is tudja használni).
  Az adminisztrációs felület használata a felhasználói dokumentáció olvasása után legyen egyértelműen használható.
• Teljesítmény: a weboldal képes legyen 100 látogató egyidejű kiszolgálására. Egy oldal megjelenése egy linkre kattintástól mérve ne legyen több 2 mp-nél (átlagos internetkapcsolatot használva).
• Rendelkezésre állás, pl.: a weboldal legyen elérhető egy év 99.5%-ában.
• Skálázhatóság, pl.: a becsült felhasználó-létszám nem igényli skálázható rendszer tervezését az első évben. (Megjegyzés: a továbbiakban a skálázhatósággal a karbantartási időszakban foglalkoznunk kell.)
• Biztonság, pl.: a felhasználók jelszavai ne legyenek visszafejthetőek. A felhasználók és adminisztrátorok által bevitt hibás adatokat a rendszer kezelje le: adjon hibajelzést, de próbálja a bevitt adatokat visszaállítani, hogy csak a hibás adatokat kelljen módosítani. A látogatók által elérhető beviteli mezőkön a rendszer végezzen szűrést ártalmas kódokra.
• Karbantarthatóság, pl.: a weboldal legyen könnyen bővíthető. Egy új oldallal, menüvel, vagy használati esettel való bővítés legyen egyértelmű, és gyorsan végrehajtható.
  A megjelenés legyen elválasztva az adatoktól és a vezérléstől, legyen könnyű a megjelenés módosítása.
• Vevői megszorítások: az alkalmazásnak online elérhetőnek kell lennie 2013. április 15-én.
• Technológiai elvárások fejlesztői oldalról: vállalati környezetünkben Apache web szerver, PHP alkalmazás-szerver és MySQL adatbázis-kezelő rendszer már üzemel. Ezért azt a technológiai döntést hoztuk, hogy alkalmazásunkat is a már létező környezetben valósítjuk meg.
• Minőségi elvárások, felhasználói oldalról: a webalkalmazásunk legyen akadálymentes (az oldalaink legyenek validak, feleljenek meg a WCAG 2.0 szabványnak), az adatbevitel legyen biztonságos, az alkalmazásunk többféle platformról, mobil kliensekről is legyen elérhető, működőképes.

Vissza a tartalomjegyzékhez