Vodič za izradu web aplikacija
Izrada web aplikacija za poslovanje: šta pripremiti pre ponude
Izrada web aplikacija počinje opisom posla koji korisnik treba da obavi. Za korisnu procenu pripremite glavni tok rada, korisničke uloge, izvore podataka i način provere rezultata. Spisak ekrana može da pomogne u razgovoru, ali tek pravila i izuzeci pokazuju šta aplikacija zaista mora da radi.
Krenite od jednog posla koji treba da se završi
Na primer, zahtev „treba nam portal za klijente" ostavlja mnogo otvorenih pitanja. Da li klijent predaje zahtev ili potvrđuje porudžbinu? Da li vidi status koji menja zaposleni ili podatak preuzet iz ERP-a? Sme li naknadno da menja ono što je poslao?
Ovaj vodič pomaže da pripremite takve odgovore pre razgovora o tehnologiji i ceni. Za pregled vrsta sistema koje projekat može da obuhvati pogledajte izradu web aplikacija po meri.
Izaberite tok rada koji možete da opišete od početnog događaja do proverenog završetka. Dobar početak nije „kontrolna tabla", nego „rukovodilac treba da vidi koji servisni zahtevi čekaju raspored i da ih dodeli tehničaru".
Razgovarajte s osobom koja taj posao danas obavlja. Zatražite da pokaže poslednji stvarni primer, uz uklanjanje ličnih ili poverljivih podataka. Tako možete da otkrijete dokumente, provere i izuzetke kojih se niko ne seti na opštem sastanku.
Zapišite šta je danas potrebno uraditi ručno i šta korisnik na kraju smatra završenim. „Zahtev je poslat" i „zahtev je prihvaćen u sistemu za raspored" mogu da budu dva različita stanja. Tu razliku treba da vidi i korisnik.
Primer toka rada za pripremu opsega
Sledeći primer je hipotetički. Firma za održavanje opreme želi da uredi prijavu servisnih poseta; nije reč o prikazu stvarnog projekta ili rezultata.
| Korak | Ko radi | Šta treba odlučiti pre izrade |
|---|---|---|
| Prijava kvara | Klijent | Koji su podaci obavezni i može li da priloži fotografiju? |
| Provera zahteva | Dispečer | Kako označava nepotpun zahtev i traži dopunu? |
| Raspored poseta | Dispečer | Dodeljuje li jednu osobu ili više tehničara? |
| Evidencija rada | Tehničar | Šta potvrđuje završetak i ko sme da ispravi unos? |
| Pregled statusa | Klijent | Koja stanja vidi i treba li da dobije obaveštenje? |
Ova tabela ne bira programski jezik. Ona otkriva odluke koje bi inače ostale skrivene iza nekoliko nacrtanih ekrana.
Odredite ko sme da vidi i menja pojedini zapis
Nazivi „klijent", „zaposleni" i „administrator" nisu potpuna specifikacija ovlašćenja. Dva klijenta mogu da imaju istu ulogu, a ipak ne smeju da vide zahteve jedan drugog. Tehničaru može da treba pristup samo dodeljenim posetama.
Za svaki važan zapis navedite ko može da ga pregleda, stvori, izmeni, potvrdi i izveze. Posebno razjasnite pristup između poslovnica ili različitih firmi u istom sistemu.
OWASP-ove smernice za autorizaciju preporučuju proveru dozvola pri svakom zahtevu. Zato skriveno dugme samo po sebi nije dovoljan kriterijum zaštite pristupa.
U hipotetičkom servisnom portalu provera može da glasi: klijent A ne može da otvori zahtev klijenta B ni kada direktno unese njegovu adresu. Takav primer je određeniji od zahteva „sistem treba da bude bezbedan", a ne predstavlja garanciju potpune bezbednosti.
Razjasnite odakle podaci dolaze i šta znači da su ažurni
Ako aplikacija koristi postojeći ERP, CRM ili drugi sistem, popišite potrebne podatke i radnje. Za prikaz statusa možda je dovoljan pristup za čitanje. Za predaju porudžbine potreban je i podržan način upisa, uz proveru da li je prenos uspeo.
Navedite koji sistem potvrđuje konačan podatak. Ako adresa kupca može da se menja na dva mesta, treba dogovoriti šta se dešava kada se vrednosti razlikuju. Takođe odredite kako korisnik prepoznaje zastareo prikaz.
Pre procene povezivanja prikupite:
- naziv i verziju postojećeg sistema, ako su poznati;
- kontakt osobe koja može da odobri pristup;
- dostupnu dokumentaciju i mogućnost testiranja;
- potrebne radnje, smer prenosa i očekivanu učestalost;
- primer greške i osobu koja je rešava.
Ako dobavljač sistema još nije potvrdio pristup, označite ga kao otvorenu pretpostavku. Razvoj web aplikacija ne uklanja ograničenja eksternog sistema samo zato što je povezivanje navedeno u opisu projekta.
Razlikujte prilagođavanje telefonu od rada bez interneta
Za svaki važan zadatak navedite uređaj, pregledač i uslove korišćenja. Pregled statusa na telefonu nije isti zahtev kao unos nalaza u skladištu s nepouzdanom vezom.
U MDN-ovom vodiču za progresivne web aplikacije objašnjeno je da napredne mogućnosti pregledača zahtevaju proveru podrške i odgovarajuće rezervno ponašanje. Zato kameru, obaveštenja i rad bez mreže treba proveriti na stvarnim uređajima korisnika.
Za rad bez interneta definišite konkretno ponašanje. Može li korisnik samo da pregleda ranije učitane podatke ili sme da stvara nove zapise? Kada se zapis šalje i kako se prikazuje da još čeka prenos? Šta ako je isti podatak u međuvremenu promenio neko drugi?
Ako su takve mogućnosti centralni deo posla, uporedite ih s potrebama opisanim u vodiču za izradu mobilnih aplikacija. Odluku vežite za zadatak i uređaje, a ne samo za želju da aplikacija može da se instalira.
Napišite kriterijum po kom ćete prihvatiti funkciju
Kriterijum prihvatanja opisuje vidljiv rezultat u određenim uslovima. Uključite očekivani tok i nekoliko važnih situacija u kojima nešto nedostaje ili ne uspe.
Za servisni portal to može da bude:
- Klijent šalje ispravan zahtev i dobija broj pod kojim može da ga pronađe.
- Ako nedostaje obavezan podatak, obrazac pokazuje šta treba ispraviti i čuva ostatak unosa.
- Ako slanje nije potvrđeno, aplikacija jasno prikazuje neizvestan status i dozvoljen sledeći korak.
- Klijent vidi samo zahteve povezane sa svojom organizacijom.
- Korisnik može da ispuni i ispravi obrazac tastaturom.
Ovo su predloženi zahtevi za primer, a ne tvrdnja da postojeće rešenje već tako radi. Dogovorite i ko ih proverava, s kojim podacima i na kojim uređajima.
Odvojite prvu verziju od kasnijih mogućnosti
Prva verzija treba da ima jasan završetak izabranog posla. Ako klijent može da prijavi kvar, ali niko ne može da preuzme zahtev, tok još nije zaokružen.
Za svaku funkciju označite da li ulazi u početni opseg, ostaje za kasnije ili zahteva dodatnu proveru. Na primer, osnovni raspored može da bude početni opseg, automatska optimizacija ruta kasnija mogućnost, a povezivanje s nepoznatim ERP-om predmet provere.
Time ne zaključavate budući razvoj. Omogućavate da ponuda jasno pokaže šta se sada procenjuje i koje nepoznanice mogu da utiču na odluku.
Šta poslati za procenu web aplikacije
Pripremite kratak opis problema, jedan tok rada, tabelu ovlašćenja, sisteme koji učestvuju i nekoliko kriterijuma prihvatanja. Dodajte očekivani broj korisnika, uređaje, razlog za rok i osobu koja može da odgovori na pitanja o procesu.
Nije neophodno da unapred znate sve odgovore. Označena nepoznanica korisnija je od pretpostavke koju različiti izvođači protumače svaki na svoj način.
Ako imate proces koji želite da pretvorite u web aplikaciju, pošaljite Noveru njegov kratak opis, zajedno s jednim primerom ulaza i očekivanog rezultata. To je konkretna početna tačka za razgovor o opsegu.
Izvori
- OWASP: Authorization Cheat Sheet — smernice za proveru dozvola pri svakom zahtevu.
- MDN: What is a progressive web app — napredne mogućnosti pregledača, provera podrške i rezervno ponašanje.