Izrada web aplikacija za poslovanje: što pripremiti prije ponude

Krenite od jednog posla koji treba završiti

Primjerice, zahtjev „trebamo portal za klijente" ostavlja mnogo otvorenih pitanja. Predaje li klijent zahtjev ili potvrđuje narudžbu? Vidi li status koji mijenja zaposlenik ili podatak preuzet iz ERP-a? Smije li naknadno mijenjati ono što je poslao?

Ovaj vodič pomaže pripremiti takve odgovore prije razgovora o tehnologiji i cijeni. Za pregled vrsta sustava koje projekt može obuhvatiti pogledajte izradu web aplikacija po mjeri.

Odaberite radni tok koji možete opisati od početnog događaja do provjerenog završetka. Dobar početak nije „nadzorna ploča", nego „voditelj treba vidjeti koji servisni zahtjevi čekaju raspored i dodijeliti ih tehničaru".

Razgovarajte s osobom koja taj posao danas obavlja. Zatražite da pokaže posljednji stvarni primjer, uz uklanjanje osobnih ili povjerljivih podataka. Tako možete otkriti dokumente, provjere i iznimke kojih se nitko ne sjeti na općem sastanku.

Zapišite što je danas potrebno napraviti ručno i što korisnik na kraju smatra završenim. „Zahtjev je poslan" i „zahtjev je prihvaćen u sustavu za raspored" mogu biti dva različita stanja. Tu razliku treba vidjeti i korisnik.

Primjer radnog toka za pripremu opsega

Sljedeći je primjer hipotetski. Tvrtka za održavanje opreme želi urediti prijavu servisnih posjeta; nije riječ o prikazu stvarnog projekta ili rezultata.

Ova tablica ne bira programski jezik. Ona otkriva odluke koje bi inače ostale skrivene iza nekoliko nacrtanih ekrana.

Odredite tko smije vidjeti i mijenjati pojedini zapis

Nazivi „klijent", „zaposlenik" i „administrator" nisu potpuna specifikacija ovlasti. Dva klijenta mogu imati istu ulogu, a ipak ne smiju vidjeti zahtjeve jedan drugoga. Tehničaru može trebati pristup samo dodijeljenim posjetima.

Za svaki važan zapis navedite tko ga može pregledati, stvoriti, izmijeniti, potvrditi i izvesti. Posebno razjasnite pristup između poslovnica ili različitih tvrtki u istom sustavu.

OWASP-ove smjernice za autorizaciju preporučuju provjeru dopuštenja pri svakom zahtjevu. Zato skriven gumb sam po sebi nije dovoljan kriterij zaštite pristupa.

U hipotetskom servisnom portalu provjera može glasiti: klijent A ne može otvoriti zahtjev klijenta B ni kada izravno upiše njegovu adresu. Takav je primjer određeniji od zahtjeva „sustav treba biti siguran", a ne predstavlja jamstvo potpune sigurnosti.

Razjasnite odakle podaci dolaze i što znači da su ažurni

Ako aplikacija koristi postojeći ERP, CRM ili drugi sustav, popišite potrebne podatke i radnje. Za prikaz statusa možda je dovoljan pristup za čitanje. Za predaju narudžbe potreban je i podržan način upisa, uz provjeru je li prijenos uspio.

Navedite koji sustav potvrđuje konačan podatak. Ako se adresa kupca može mijenjati na dva mjesta, treba dogovoriti što se događa kada se vrijednosti razlikuju. Također odredite kako korisnik prepoznaje zastarjeli prikaz.

Prije procjene povezivanja prikupite:

• naziv i verziju postojećeg sustava, ako su poznati;
• kontakt osobe koja može odobriti pristup;
• dostupnu dokumentaciju i mogućnost testiranja;
• potrebne radnje, smjer prijenosa i očekivanu učestalost;
• primjer pogreške i osobu koja je rješava.

Ako dobavljač sustava još nije potvrdio pristup, označite ga kao otvorenu pretpostavku. Razvoj web aplikacija ne uklanja ograničenja vanjskog sustava samo zato što je povezivanje navedeno u opisu projekta.

Razlikujte prilagodbu mobitelu od rada bez interneta

Za svaki važan zadatak navedite uređaj, preglednik i uvjete korištenja. Pregled statusa na mobitelu nije isti zahtjev kao unos nalaza u skladištu s nepouzdanom vezom.

U MDN-ovu vodiču za progresivne web aplikacije objašnjeno je da napredne mogućnosti preglednika zahtijevaju provjeru podrške i odgovarajuće zamjensko ponašanje. Zato kameru, obavijesti i rad bez mreže treba provjeriti za stvarne uređaje korisnika.

Za offline rad definirajte konkretno ponašanje. Može li korisnik samo pregledati ranije učitane podatke ili smije stvarati nove zapise? Kada se zapis šalje i kako se prikazuje da još čeka prijenos? Što ako je isti podatak u međuvremenu promijenio netko drugi?

Ako su takve mogućnosti središnji dio posla, usporedite ih s potrebama opisanim u vodiču za izradu mobilnih aplikacija. Odluku vežite uz zadatak i uređaje, a ne samo želju da se aplikacija može instalirati.

Napišite kriterij po kojem ćete prihvatiti funkciju

Kriterij prihvata opisuje vidljiv rezultat u određenim uvjetima. Uključite očekivani tijek i nekoliko važnih situacija u kojima nešto nedostaje ili ne uspije.

Za servisni portal to može biti:

1. Klijent šalje ispravan zahtjev i dobiva broj pod kojim ga može pronaći.
2. Ako nedostaje obvezan podatak, obrazac pokazuje što treba ispraviti i čuva ostali unos.
3. Ako slanje nije potvrđeno, aplikacija jasno prikazuje neizvjesni status i dopušten sljedeći korak.
4. Klijent vidi samo zahtjeve povezane sa svojom organizacijom.
5. Korisnik može ispuniti i ispraviti obrazac tipkovnicom.

Ovo su predloženi zahtjevi za primjer, a ne tvrdnja da postojeće rješenje već tako radi. Dogovorite i tko ih provjerava, s kojim podacima i na kojim uređajima.

Odvojite prvu verziju od kasnijih mogućnosti

Prva verzija treba imati jasan završetak odabranog posla. Ako klijent može prijaviti kvar, ali nitko ne može preuzeti zahtjev, tok još nije zaokružen.

Za svaku funkciju označite ulazi li u početni opseg, ostaje za kasnije ili zahtijeva dodatnu provjeru. Primjerice, osnovni raspored može biti početni opseg, automatska optimizacija ruta kasnija mogućnost, a povezivanje s nepoznatim ERP-om predmet provjere.

Time ne zaključavate budući razvoj. Omogućujete da ponuda jasno pokaže što se sada procjenjuje i koje nepoznanice mogu utjecati na odluku.

Što poslati za procjenu web aplikacije

Pripremite kratak opis problema, jedan radni tok, tablicu ovlasti, sustave koji sudjeluju i nekoliko kriterija prihvata. Dodajte očekivani broj korisnika, uređaje, razlog za rok te osobu koja može odgovoriti na pitanja o procesu.

Nije nužno unaprijed znati 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 pretvoriti u web aplikaciju, pošaljite Noveru njegov kratak opis, zajedno s jednim primjerom ulaza i očekivanog rezultata. To je konkretna početna točka za razgovor o opsegu.

Izvori

• OWASP: Authorization Cheat Sheet — smjernice za provjeru dopuštenja pri svakom zahtjevu.
• MDN: What is a progressive web app — napredne mogućnosti preglednika, provjera podrške i zamjensko ponašanje.