Vodič kroz razvoj softvera
Razvoj softvera za tvrtke: faze, provjere i predaja
Razvoj softvera za tvrtku vodi kroz odluke koje možete provjeriti: što se izrađuje, kako izgleda prihvatljiva isporuka, tko odobrava promjene i što preuzimate na kraju. Dogovorite ishod, granice opsega i kriterije prihvata prije početka, a promjene opsega zabilježite prije odluke. Prihvat provedite na zadacima stvarnih korisničkih uloga, a predaju uredite popisom računa, pristupa, dokumentacije i podrške.
Prije početka dogovorite ishod i način odlučivanja
Ako još odlučujete treba li aplikaciju uopće razvijati, prvo pogledajte usporedbu gotovog rješenja, integracije i softvera po mjeri.
Navedite poslovnu situaciju koja se treba promijeniti i tko će provjeriti promjenu. Primjer ishoda jest mogućnost da voditelj obradi zahtjev za nabavu u jednom radnom toku, uz pregled odluke i razloga odbijanja.
Uz to odredite što projekt zasad ne obuhvaća. Možda prvi opseg pokriva zahtjev i odobravanje, ali ne i automatsku narudžbu dobavljaču ili knjiženje u ERP-u. Ta granica mora biti razumljiva i poslovnom timu i izvođaču.
S naručiteljeve strane imenujte osobu koja usklađuje prioritete te zamjenu kada nije dostupna. Stručnjaci iz nabave, financija ili skladišta i dalje trebaju sudjelovati u provjerama vlastitih zadataka. Jedna odgovorna osoba ne znači da jedna osoba zna sve detalje.
Svaka faza treba ostaviti nešto što možete pregledati
Projekt ne mora slijediti jedan univerzalni redoslijed. Pojedine se aktivnosti mogu ponavljati dok se zahtjevi razjašnjavaju. Za praćenje suradnje korisna je sljedeća radna tablica.
| Dio rada | Što naručitelj pregledava | Koju odluku treba donijeti |
|---|---|---|
| Razrada zahtjeva | Opis procesa, granice opsega i otvorena pitanja | Je li opisan pravi problem? |
| Prototip | Tijek zadataka i razumljivost ekrana | Može li korisnik pronaći i završiti radnju? |
| Razvoj | Radnu funkciju i pripadajuće provjere | Odgovara li dogovorenim primjerima? |
| Prihvat | Rezultate testova i popis otvorenih nedostataka | Što mora biti riješeno prije rada? |
| Uvođenje | Plan prijelaza, korisničke pristupe i obuku | Jesu li ljudi i sustavi spremni? |
| Predaja | Dokumentaciju, račune, odgovornosti i podršku | Može li se sustav odgovorno koristiti i održavati? |
Prototip pokazuje predloženi način rada. Ne dokazuje da su integracije povezane, podaci preneseni ili ovlasti provedene. Pitajte što je u demonstraciji stvarno povezano, a što služi samo prikazu.
Od općeg zahtjeva napravite provjerljiv primjer
Zahtjev „voditelj odobrava nabavu” ostavlja otvorena pitanja: odobrava li svaki zahtjev, smije li promijeniti iznos i što se događa kada je odsutan?
Sljedeći hipotetski primjer koristi izmišljena interna pravila. Tvrtka traži da voditelj odobri svaki zahtjev, a financije dodatno potvrde iznose iznad 2.000 EUR. Taj iznos nije zakonski prag ni tržišni standard.
Prije izrade razjasnite:
- odnosi li se prag na iznos s porezom ili bez njega;
- što se događa kada naknadna izmjena prijeđe prag;
- može li podnositelj odobriti vlastiti zahtjev;
- tko preuzima odobravanje tijekom odsutnosti;
- što korisnik vidi nakon odbijanja ili vraćanja na dopunu.
Kriterij prihvata može glasiti: izmjena iznosa nakon potvrde vraća zahtjev na potrebnu provjeru, a prijašnja odluka ostaje vidljiva. Takvu rečenicu možete pretvoriti u testni slučaj i zajednički pregledati rezultat.
Sigurnost i pristupačnost uključite u radne zahtjeve
Nemojte ih ostaviti kao neodređene stavke na završnom popisu. Navedite osjetljive podatke, dopuštene radnje, očekivani način prijave i postupak uklanjanja pristupa bivšem zaposleniku.
NIST-ov SSDF opisuje sigurnosne prakse koje se mogu uključiti u različite razvojne procese. To je koristan okvir za pitanja dobavljaču, bez obećanja da jedan pregled uklanja sve rizike.
Za sučelje pripremite zadatke koji se mogu provjeriti, primjerice unos i ispravak obrasca tipkovnicom. W3C-ov vodič za planiranje pristupačnosti uključuje odgovornosti i ranu, ponovljenu evaluaciju. Dogovorite tko takve provjere provodi i što se smatra prihvatljivim rezultatom.
Promjene tijekom razvoja zabilježite prije odluke
Nova ideja nije automatski pogreška u projektu. Problem nastaje kada se njezin učinak na postojeći dogovor ne razmotri.
Za zahtjev za promjenom dovoljan je jasan zapis: što se mijenja, zašto, koje funkcije i podatke zahvaća te kakav je predloženi učinak na rok i cijenu. Navedite i mogućnost odgode ili zamjene neke druge stavke.
U primjeru nabave dodatno odobravanje financija može promijeniti obavijesti, ovlasti, prikaz statusa i testove. Dogovor „dodajmo još jednu potvrdu” ne pokazuje taj opseg.
Razlikujte odstupanje od već prihvaćenog kriterija i novi zahtjev. Način evidentiranja, odgovornosti i obračuna dogovorite u suradnji; ovaj članak ne određuje ugovornu klasifikaciju konkretnog slučaja.
Prihvat provedite na zadacima stvarnih korisničkih uloga
Pripremite slučajeve koje će provjeravati osobe iz poslovanja, uz podršku razvojnog tima. Koristite prikladne testne podatke i ovlasti slične budućem radu. Uspjeh administratora koji vidi sve nije dokaz da isti postupak radi za zaposlenika s ograničenim pristupom.
Microsoftov kontrolni popis za uvođenje Dynamics 365 u prihvat uključuje i rubne scenarije, odgovarajuće uloge te provjeru migriranih podataka. Istu vrstu pitanja možete prilagoditi vlastitom projektu.
Za svaki nedostatak zapišite korake ponavljanja, očekivani i stvarni rezultat te važnost za rad. Odredite tko potvrđuje ispravak. Otvorene stavke pregledajte prije odluke o uvođenju, umjesto da neprovjereno pretpostavite kako nijedna ne utječe na korisnike.
Uvođenje u rad planirajte kao zaseban događaj
Dogovorite kada prestaje unos u stari sustav, tko provjerava završni prijenos i kako korisnici dobivaju pristupe. Ako se radi pilot, navedite tko sudjeluje i koja je granica između pilot-podataka i službenog rada.
Potreban je i dogovoren postupak ako uvjeti za početak nisu zadovoljeni. Povratak na stari način rada može zahtijevati usklađivanje novih podataka; ne treba ga svesti na ideju da se samo ponovno uključi prethodna aplikacija.
Na dan početka korisnicima treba biti jasno kome prijavljuju problem, koje informacije šalju i kako provjeravaju je li prijava preuzeta.
Što treba biti jasno pri predaji aplikacije
Pregledajte popis računa i pristupa za domenu, infrastrukturu, vanjske usluge i kod, prema dogovorenom modelu suradnje. Razjasnite prava na izrađene materijale i korištene licence. Izrada po mjeri sama po sebi ne zamjenjuje taj dogovor.
Zatražite upute za redovne administrativne radnje, poznata ograničenja i opis podrške. Razlikujte ispravak postojećeg ponašanja, sigurnosno ažuriranje, promjenu vanjske usluge i razvoj nove funkcije. Navedite tko prati koje događaje i kako se ugovara dodatni rad.
Ako pripremate projekt razvoja softvera po mjeri, krenite od funkcije koju možete opisati i prihvatiti. Pošaljite Noveru primjer 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 — sigurnosne prakse koje se mogu uključiti 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 provjera migriranih podataka pri uvođenju.