Sok alkalmazásötlet már kész megoldással indul: „platformra van szükség” vagy „ezt a lépést automatizálni kell”. Az ilyen mondatok irányt mutathatnak, de még nem határoznak meg terméket. Egy érdekes ötlet és egy karbantartható alkalmazás között emberekről, helyzetekről, adatokról, határokról és későbbi működtetésről szóló döntések állnak.
A legfontosabb munka az első képernyő előtt kezdődik. Mi a tényleges probléma, hogyan oldják meg ma, és milyen megfigyelhető eredmény jelezné a javulást? A fenntartható alkalmazás világos célt, következetes adatmodellt és hosszú távon vállalható hatókört kapcsol össze.
Röviden
- Határozza meg a konkrét problémát, a célközönséget és a legkisebb teljes folyamatot.
- Az adatmodellt, az adatvédelmet, a tesztelést és az üzemeltetést kezdettől együtt tervezze.
- Csak akkor adjon ki lépcsőzetesen új verziókat, ha mindegyik teljes, hasznos eredményt nyújt.
Írja le a problémát egy megfigyelhető helyzetben
„Az ingatlankezelés átláthatatlan” túl tág megfogalmazás. Nem derül ki belőle, kit érint, és pontosan mit jelent az átláthatatlanság. Ezzel szemben a „Magántulajdonosok otthonuktól távol nem találják meg megbízhatóan a legutóbb rögzített mérőállást és a hozzá tartozó fényképet” konkrét: megnevezi az érintettet, a helyzetet, az információt és a kívánt eredményt.
A jó problémameghatározás kezdetben független marad a megoldástól. Lehet, hogy elegendő egy jobb meglévő tárhely, egy módosított folyamat vagy egy kis webes felület. Aki rögtön egy konkrét technológiát ír elő, könnyen figyelmen kívül hagyja az egyszerűbb lehetőségeket. A korai elemzés célja nem egy alkalmazás létjogosultságának igazolása, hanem annak megértése, hogy hasznos lenne-e, és ha igen, hol.
Milyen lépéseket tesznek ma az emberek? Milyen eszközöket használnak? Hol váltanak a papír, a táblázatok, az üzenetek és a fényképek között? Mik a kivételek? Fontos, hogy ne csak a kívánt funkciókat kérje. Az emberek korábbi tapasztalataikból írják le a megoldásokat. A megfigyelt nehézségek jobban megmagyarázzák, mit kell tennie a terméknek.
A célcsoport azt is jelenti: tudatosan nem mindenkinek
Valószínűleg még nincs egyértelmű célcsoportja a “magánszemélyeknek és minden méretű cégnek” szóló terméknek. A különböző csoportok eltérő fogalmakkal, kockázatokkal és munkafolyamatokkal rendelkeznek. Egyetlen embernek nincs szüksége szerepkezelésre. Egy csapat nem tud megbízhatóan dolgozni szerepek és közös adatok nélkül.
A hasznos célcsoportleírás ezért tartalmazza a használati környezetet, a tapasztalatot, a gyakoriságot és a korlátokat. Egyedül vagy másokkal dolgozik a felhasználó? Okostelefonon vagy több munkaállomáson? Naponta nyitja meg az alkalmazást, vagy csak egy bizonyos eseménynél? Működnie kell hálózat nélkül? Mely hibák lennének csupán bosszantóak, és melyek járnának súlyos következménnyel?
Ezek a kérdések később szinte mindent érintenek: a navigációt, az adattárolást, a biztonsági modellt, a súgószövegeket és az üzleti modellt. A célcsoport lehatárolása nem pusztán marketingcélú perszónaalkotás. A műszaki specifikáció része.
A legkisebb teljes folyamat megtalálása
Az első termékváltozat legyen kicsi, de ne befejezetlen. Ha például mérőállást szeretne rögzíteni, ki kell választania az ingatlant, meg kell adnia a dátumot és az értéket, szükség esetén fényképet kell csatolnia, majd mentenie, később megtalálnia és javítania kell a bejegyzést. Egyetlen űrlap előzmények és hibajavítás nélkül kevesebb munkát jelentene, de nem adna teljes értéket.
A legkisebb teljes folyamatnak van eleje, közepe és vége, és a legfontosabb eltérésekre is kitér. Mi történik, ha hiányzik a kameraengedély? Menthető-e a bejegyzés fénykép nélkül? Hogyan néz ki az üres állapot? Mi történik érvénytelen érték vagy megszakítás esetén? Megmarad-e a már beírt adat?
Csak akkor lehet a funkciókat értelmesen szükséges és választható elemekre bontani, ha ez az alapvető folyamat világos. Szükséges az, ami egyáltalán lehetővé teszi az eredményt, vagy megvéd egy elfogadhatatlan hibától. Választható az, ami a kényelmet, a változatokat vagy a későbbi célcsoportokat bővíti. Ezt a felosztást rendszeresen felül kell vizsgálni, mert egy aprónak tűnő lehetőség is új adatokat és állapotokat hozhat létre.
Prototípusok a döntések láthatóvá tételéhez
A prototípus akkor különösen értékes, ha láthatóvá teszi a nyitott kérdéseket. Értik az emberek a használt kifejezéseket? Megtalálják a következő lépést? Hiányzik-e valamilyen információ a döntéshez? Illik-e a folyamat ahhoz a helyzethez, amelyben az okostelefont ténylegesen használják?
A prototípusnak nem kell vizuálisan tökéletesnek lennie. Egy egyszerű, kattintható prototípus valósághű tartalommal gyakran többet mutat egy helyőrzőkkel teli, csiszolt prezentációnál. Valódi nevek, hosszabb szövegek, hiányzó képek és több rekord láthatóvá teszik, hogy az elrendezés és az információs architektúra megállja-e a helyét.
A prototípusoknak kritikus állapotokat is tartalmazniuk kell: nincs adat, betöltési vagy mentési hibák, megtagadott engedély, offline használat, nagyon nagy betűtípus és visszafordíthatatlan műveletek. Aki csak az ideális folyamatot mutatja be, az nem a terméket, hanem egy történetet tesztel.
Az emberi kezelőfelületre vonatkozó irányelveiben az Apple a hierarchiát, a következetességet és a különböző kijelzőkhöz való alkalmazkodást hangsúlyozza. Ezeket az elveket nem lehet dekorációként hozzáadni a végén. Már a prototípus szerkezetét is befolyásolják: mi a tartalom, mi a művelet, mely információ marad előtérben, és melyik interakció ismerős az adott platformon?
Az adatmodell hosszú távú termékdöntés
A felületek jelentősen változhatnak, a tárolt adatok jelentése azonban gyakran évekig megmarad. Ezért érdemes korán tisztázni, hogy milyen entitások léteznek a termékben, és hogyan kapcsolódnak egymáshoz. A „szoba” mindig egy egység része? Egy dokumentum több folyamathoz is hozzárendelhető? Mi történik a feladatokkal, ha egy objektumot archiválnak? Pontosan tárolja a rendszer a pénzösszegeket és a mért értékeket?
A következetes adatmodell megakadályozza, hogy ugyanazt az információt több helyen egymásnak ellentmondóan tartsák karban. Az Android Developers többek között egyértelmű adatforrást és világos felelősségi határokat javasol az alkalmazásarchitektúrában. Ezek a műszaki alapelvek egy fontos termékszabályt támogatnak: amikor egy információ megváltozik, egyértelműnek kell lennie, melyik megjelenítése marad az irányadó.
A migráció is ehhez a döntéshez tartozik. Amint valós adatok léteznek, egy új verzió nem nevezhet át vagy törölhet tetszőlegesen mezőket. A terméknek szabályokra van szüksége ahhoz, hogy a régebbi állapotok új struktúrába kerüljenek. Egy jó kezdeti modell nem próbál minden jövőbeli fejleményt megjósolni, de elválasztja a stabil szakterületi fogalmakat a felület rövid életű logikájától.
Az adatvédelem azzal a kérdéssel kezdődik, hogy milyen adatokra van szükség
Az adatvédelem költségessé válik, ha csak a megvalósítás után vizsgálják. Addigra az engedélyek, külső szolgáltatások és adatmodellek már összekapcsolódnak. A korai adatvédelmi mérlegelés viszont egyszerűsítheti a termék hatókörét.
Az alkalmazásnak szüksége van fiókra? Teljes névjegyet kell importálni, vagy elegendő egy manuálisan rögzített személy? Tartósan szükséges a helyhozzáférés, csak egyetlen művelethez, vagy egyáltalán nem? El kell hagynia egy dokumentumnak az eszközt? Minden olyan adat, amelyet nem gyűjtünk be, csökkenti a támadási felületet, a hibalehetőségeket, a biztonsági munkát és a későbbi törlési folyamatokat.
Az Android az engedélykérések minimalizálását javasolja, és lehetőség szerint olyan funkciókat, amelyek szükségtelen hozzáférés nélkül is működnek. Ha engedély kell, azt a konkrét művelet összefüggésében érdemes kérni. Az elutasított engedély nem teheti automatikusan használhatatlanná az egész alkalmazást, ha létezik észszerű alternatíva.
Az adatvédelem a teljes életciklusra kiterjed: mentés, megjelenítés, megosztás, exportálás, biztonsági mentés és törlés. A helyi tárolás biztonsági mentési stratégiát igényel. A felhőalapú adatokhoz fiókvédelem, hozzáférési szabályok és érthető törlési folyamat szükséges. Külső szolgáltatók igénybevételekor egyértelműnek kell lennie, hogy milyen információkat kapnak és miért.
A karbantarthatóság világos határokból és felelősségekből fakad
A karbantartható kódbázis világos feladatokkal rendelkező modulokat tartalmaz. Az interfész koordinálja az interakciókat, a tartományi logika szabályokat valósít meg, az adatréteg pedig kezeli a forrásokat és a perzisztenciát. Ha a hálózati hozzáférést, a prezentációt és az üzleti szabályokat ugyanazokba az összetevőkbe keverik, a változtatások és a tesztek nehezebbé válnak.
A műszaki szétválasztás önmagában nem elég. A terméknek felelősségi határokra is szüksége van. Ki határozza meg a fogalmakat? A termék melyik része az irányadó egy adathalmaz esetében? Mit ígér a termék, ha egy külső szolgáltatás meghibásodik? Van kézi alternatíva? Mi az, amit kifejezetten nem támogat?
Minden függőségnek felismerhető célja kell legyen. Egy könyvtár felgyorsíthatja a fejlesztést, de frissítéseket és biztonsági felügyeletet igényel. Egy felhőszolgáltatás összetett munkát végezhet, de költségeket és hibapontot jelent. A házon belüli rendszer biztosítja az irányítást, de állandó gondozást igényel. A karbantarthatóság e kötelezettségek tudatos megválasztását jelenti.
A dokumentáció akkor támogatja ezt az egyértelműséget, ha megmagyarázza a döntéseket. Az egyes fájlok hosszú listája gyorsan elavul. Értékesebbek a rendszerhatárok, az adatfolyamok, a migrációs szabályok és a nem magától értetődő döntések rövid indoklásai. Az új csapattagoknak és a jövőbeli önmagunknak is érteniük kell, miért éppen így készült egy összetevő.
A tesztek kockázatokat és valós felhasználói folyamatokat követnek
Az automatizált tesztek nagy száma önmagában nem igazolja a termék minőségét. Az számít, hogy lefedik-e a lényeges kockázatokat. Az egységtesztek szakterületi szabályokhoz és számításokhoz alkalmasak. Az integrációs tesztek az adatbázis, a szolgáltatások és a migrációk együttműködését ellenőrzik. A végpontok közötti tesztek a központi felhasználói folyamatokat védhetik. A kézi tesztelés továbbra is fontos a nyelv, a vizuális hierarchia, a fókusz működése és a nehezen automatizálható helyzetek vizsgálatához.
A teszteknek valósághű adatokkal kell működniük: hosszú nevek, üres listák, régebbi rekordok, szokatlan decimális értékek, több melléklet és megszakadt kapcsolatok. A különböző képernyőméretek és a nagyobb betűméret mutatják, hogy egy elrendezés valóban alkalmazkodó-e. A képernyőolvasók és a billentyűzetek láthatóvá teszik azokat a szemantikai hiányosságokat, amelyeket a képernyőkép nem mutat.
A W3C WAI azt javasolja, hogy az akadálymentesítést korán és rendszeresen értékeljék, és megfelelő módon vonjanak be fogyatékossággal élő embereket. Ez jó általános minőségi elv: nem elég a kész verziót ellenőrzőlista alapján vizsgálni; akkor kell visszajelzést kérni, amikor a döntések még módosíthatók.
Különösen a kockázatos műveletekhez van szükség célzott ellenőrzésekre. A törlés, a helyreállítás, a vásárlási állapot, az exportálás és az engedélyek alaposabb tesztelést érdemelnek, mint egy pusztán dekoratív beállítás. A hatás és a valószínűség szerinti rangsorolás hasznosabb, mint mindenhol azonos mennyiségű tesztelést követelni.
A szakaszos kiadás nem jelenti azt, hogy befejezetlen terméket kell kiadni
Az első verziónak nem kell minden hosszú távú tervet tartalmaznia. A megígért alapvető útvonalaknak azonban teljesnek, érthetőnek és megbízhatónak kell lenniük. A „lépésről lépésre” a hatókör fejlődését írja le; nem szolgálhat kifogásként a hiányos hibakezelésre vagy a tisztázatlan adatfelelősségre.
Megjelenés előtt a terméknek ellenőrizhető kritériumokra van szüksége: támogatott eszközökre és verziókra, tesztelt alapfolyamatokra, érthető termékhatárokra, helyes bolti és jogi szövegekre, elérhető támogatásra, biztonsági mentési vagy törlési viselkedésre, valamint tervre a kritikus hibákra. Egy ellenőrzött tesztcsoport a széles körű kötelezettségvállalás előtt valós használatot igazolhat.
A közzététel után a visszajelzések nem válnak automatikusan ütemterv-bejegyzésekké. A visszajelzések bizonyítékot szolgáltatnak a valós helyzetekről. Több kérés ugyanarra a funkcióra mutathat mintát – vagy rámutathat egy meglévő folyamatra, amelyet senki sem talál. A termékcsoportoknak meg kell érteniük a problémát, a gyakoriságot, a célcsoportot és a kockázatot, mielőtt megoldást választanak.
Egy későbbi verzió új képességekkel bővülhet. Nem szabad azonban eltakarnia a termék magját, és tiszteletben kell tartania a meglévő adatokat. A migráció, a visszamenőleges kompatibilitás és a frissített magyarázatok a funkció részét képezik, nem utólagos takarítási feladatok.
A közös szál a konkrét eredmény
Az első megfigyeléstől a napi működtetésig egy kérdés tartja irányban a munkát: javítja-e ez a döntés a célközönség konkrét eredményét? Egy szép prototípus, modern architektúra vagy hosszú funkciólista keveset ér, ha a rossz problémát optimalizálja.
A karbantartható alkalmazás valós problémát, behatárolt közönséget, teljes alapfolyamatokat, következetes adatmodellt, érthető adatáramlást és ellenőrizhető felelősséget kapcsol össze. Ez az alap határozza meg, hogy a termék a későbbi verziókban is következetesen továbbfejlődhet-e.
Források és további olvasnivalók
- Android Developers: Útmutató az alkalmazásarchitektúrához – adatmodellek, egyetlen hiteles adatforrás, tesztelhetőség és felelősségi határok.
- Android Fejlesztők: Adatréteg – az adatréteg felelősségei és határai.
- Android Fejlesztők: Minimalizálja az engedélykéréseket – adatminimalizálás és kontextus szerinti engedélyek.
- Apple Human Interface Guidelines – hierarchia, következetesség, elrendezés és platformnak megfelelő interakciók.
- W3C WAI: Webes akadálymentesítés tervezése és kezelése – az akadálymentesítés és az értékelés korai és folyamatos bevonása.
