Vodič kroz razvoj softvera
Razvoj softvera za firme: faze, provere i predaja
Razvoj softvera za firmu treba da vodi kroz odluke koje možete da proverite: šta se izrađuje, kako izgleda prihvatljiva isporuka, ko odobrava promene i šta preuzimate na kraju. Dogovorite ishod, granice opsega i kriterijume prihvata pre početka, a promene opsega zabeležite pre odluke. Prihvat sprovedite na zadacima stvarnih korisničkih uloga, a predaju uredite spiskom naloga, pristupa, dokumentacije i podrške.
Pre početka dogovorite ishod i način odlučivanja
Ako još odlučujete da li aplikaciju uopšte treba razvijati, prvo pogledajte uporedni prikaz gotovog rešenja, integracije i softvera po meri.
Navedite poslovnu situaciju koju treba promeniti i ko će proveriti promenu. Primer ishoda je mogućnost da rukovodilac obradi zahtev za nabavku u jednom toku rada, uz pregled odluke i razloga odbijanja.
Uz to odredite šta projekat zasad ne obuhvata. Prvi opseg možda pokriva zahtev i odobravanje, ali ne i automatsku porudžbinu dobavljaču ili knjiženje u ERP-u. Ta granica mora da bude razumljiva i poslovnom timu i izvođaču.
Na strani naručioca imenujte osobu koja usklađuje prioritete i zamenu kada nije dostupna. Stručnjaci iz nabavke, finansija ili skladišta i dalje treba da učestvuju u proverama sopstvenih zadataka. Jedna odgovorna osoba ne znači da jedna osoba zna sve detalje.
Svaka faza treba da ostavi nešto što možete da pregledate
Projekat ne mora da sledi jedan univerzalni redosled. Pojedine aktivnosti mogu da se ponavljaju dok se zahtevi razjašnjavaju. Za praćenje saradnje korisna je sledeća radna tabela.
| Deo posla | Šta naručilac pregleda | Koju odluku treba doneti |
|---|---|---|
| Razrada zahteva | Opis procesa, granice opsega i otvorena pitanja | Da li je opisan pravi problem? |
| Prototip | Tok zadataka i razumljivost ekrana | Može li korisnik da pronađe i završi radnju? |
| Razvoj | Radnu funkciju i pripadajuće provere | Da li odgovara dogovorenim primerima? |
| Prihvat | Rezultate testova i spisak otvorenih nedostataka | Šta mora da bude rešeno pre rada? |
| Uvođenje | Plan prelaza, korisničke pristupe i obuku | Da li su ljudi i sistemi spremni? |
| Predaja | Dokumentaciju, naloge, odgovornosti i podršku | Može li sistem odgovorno da se koristi i održava? |
Prototip pokazuje predloženi način rada. Ne dokazuje da su integracije povezane, podaci preneti ili ovlašćenja sprovedena. Pitajte šta je u demonstraciji stvarno povezano, a šta služi samo prikazu.
Od opšteg zahteva napravite proverljiv primer
Zahtev „rukovodilac odobrava nabavku” ostavlja otvorena pitanja: da li odobrava svaki zahtev, sme li da promeni iznos i šta se dešava kada je odsutan?
Sledeći hipotetički primer koristi izmišljena interna pravila. Firma traži da rukovodilac odobri svaki zahtev, a finansije dodatno potvrde iznose iznad 2.000 EUR. Taj iznos nije zakonski prag ni tržišni standard.
Pre izrade razjasnite:
- da li se prag odnosi na iznos s porezom ili bez njega;
- šta se dešava kada naknadna izmena pređe prag;
- može li podnosilac da odobri sopstveni zahtev;
- ko preuzima odobravanje tokom odsustva;
- šta korisnik vidi nakon odbijanja ili vraćanja na dopunu.
Kriterijum prihvata može da glasi: izmena iznosa nakon potvrde vraća zahtev na potrebnu proveru, a prethodna odluka ostaje vidljiva. Takvu rečenicu možete da pretvorite u testni slučaj i zajedno pregledate rezultat.
Bezbednost i pristupačnost uključite u radne zahteve
Nemojte da ih ostavite kao neodređene stavke na završnom spisku. Navedite osetljive podatke, dozvoljene radnje, očekivani način prijave i postupak uklanjanja pristupa bivšem zaposlenom.
NIST-ov SSDF opisuje bezbednosne prakse koje mogu da se uključe u različite razvojne procese. To je koristan okvir za pitanja dobavljaču, bez obećanja da jedan pregled uklanja sve rizike.
Za interfejs pripremite zadatke koji mogu da se provere, na primer unos i ispravku obrasca tastaturom. W3C-ov vodič za planiranje pristupačnosti uključuje odgovornosti i ranu, ponovljenu evaluaciju. Dogovorite ko takve provere sprovodi i šta se smatra prihvatljivim rezultatom.
Promene tokom razvoja zabeležite pre odluke
Nova ideja nije automatski greška u projektu. Problem nastaje kada se njen učinak na postojeći dogovor ne razmotri.
Za zahtev za promenu dovoljan je jasan zapis: šta se menja, zašto, koje funkcije i podatke zahvata i kakav je predloženi učinak na rok i cenu. Navedite i mogućnost odlaganja ili zamene neke druge stavke.
U primeru nabavke dodatno odobravanje finansija može da promeni obaveštenja, ovlašćenja, prikaz statusa i testove. Dogovor „dodajmo još jednu potvrdu” ne pokazuje taj opseg.
Razlikujte odstupanje od već prihvaćenog kriterijuma i novi zahtev. Način evidentiranja, odgovornosti i obračuna dogovorite zajedno; ovaj članak ne određuje ugovornu klasifikaciju konkretnog slučaja.
Prihvat sprovedite na zadacima stvarnih korisničkih uloga
Pripremite slučajeve koje će proveravati osobe iz poslovanja, uz podršku razvojnog tima. Koristite prikladne testne podatke i ovlašćenja slična budućem radu. Uspeh administratora koji vidi sve nije dokaz da isti postupak radi za zaposlenog s ograničenim pristupom.
Microsoftov kontrolni spisak za uvođenje Dynamics 365 u prihvat uključuje i rubne scenarije, odgovarajuće uloge i proveru migriranih podataka. Istu vrstu pitanja možete da prilagodite sopstvenom projektu.
Za svaki nedostatak zapišite korake za ponavljanje, očekivani i stvarni rezultat i važnost za rad. Odredite ko potvrđuje ispravku. Otvorene stavke pregledajte pre odluke o uvođenju, umesto da bez provere pretpostavite da nijedna ne utiče na korisnike.
Uvođenje u rad planirajte kao zaseban događaj
Dogovorite kada prestaje unos u stari sistem, ko proverava završni prenos i kako korisnici dobijaju pristupe. Ako se radi pilot, navedite ko učestvuje i koja je granica između pilot-podataka i zvaničnog rada.
Potreban je i dogovoren postupak ako uslovi za početak nisu ispunjeni. Povratak na stari način rada može da zahteva usklađivanje novih podataka; ne treba ga svesti na ideju da se samo ponovo uključi prethodna aplikacija.
Na dan početka korisnicima treba da bude jasno kome prijavljuju problem, koje informacije šalju i kako proveravaju da li je prijava preuzeta.
Šta treba da bude jasno pri predaji aplikacije
Pregledajte spisak naloga i pristupa za domen, infrastrukturu, eksterne usluge i kod, prema dogovorenom modelu saradnje. Razjasnite prava na izrađene materijale i korišćene licence. Izrada po meri sama po sebi ne zamenjuje taj dogovor.
Zatražite uputstva za redovne administrativne radnje, poznata ograničenja i opis podrške. Razlikujte ispravku postojećeg ponašanja, bezbednosno ažuriranje, promenu eksterne usluge i razvoj nove funkcije. Navedite ko prati koje događaje i kako se ugovara dodatni rad.
Ako pripremate projekat razvoja softvera po meri, krenite od funkcije koju možete da opišete i prihvatite. Pošaljite Noveru primer procesa i očekivane isporuke kako bi razgovor obuhvatio i predaju, a ne samo početak izrade.
Izvori
- NIST: Secure Software Development Framework (SSDF), SP 800-218 — bezbednosne prakse koje mogu da se uključe u razvojne procese.
- W3C: Planning and Managing Web Accessibility — odgovornosti i rana, ponovljena evaluacija pristupačnosti.
- Microsoft: Prepare for go-live checklist (Dynamics 365) — rubni scenariji, odgovarajuće uloge i provera migriranih podataka pri uvođenju.