Kas ir tehniskā specifikācija programmatūras izstrādē?

Tehniskā specifikācija ir tilts starp uzņēmuma vajadzību un izstrādājamu sistēmu. Uzņēmuma vadītājs parasti domā procesos: klienti, pasūtījumi, darbinieki, termiņi, dokumenti, atskaites. Izstrādātājam šie procesi jāpārvērš datu struktūrās, lietotāju lomās, ekrānos, integrācijās un noteikumos. Specifikācija palīdz abām pusēm runāt vienā valodā.

Labā specifikācijā ir aprakstīts mērķis, lietotāju grupas, galvenie scenāriji, datu objekti, statusi, tiesības, atskaites, paziņojumi un integrācijas. Piemēram, CRM gadījumā jāzina, kas ir klients, kas ir darījums, kādi ir posmi, kurš drīkst mainīt statusu, kā tiek sagatavots piedāvājums un kādi dati jāsūta uz grāmatvedību.

Specifikācija nav obligāti simtiem lapu garš dokuments. Mazākam projektam pietiek ar strukturētu prasību aprakstu, ekrānu skicēm un prioritātēm. Lielākam projektam vajadzīga detalizētāka dokumentācija, jo kļūdas vēlāk maksā dārgāk. Svarīgākais ir nevis dokumenta apjoms, bet skaidrība.

Ieguvums ir precīzāks budžets un mazāk pārpratumu. Ja prasības ir neskaidras, izstrādes laikā rodas daudz “mēs domājām citādi” situāciju. Tas palielina izmaksas un pagarina termiņus. Specifikācija palīdz arī sadalīt projektu posmos: kas ir obligāts pirmajai versijai un ko var atlikt.

Specifikāciju nevajag uztvert kā nemaināmu akmeni. Programmatūras projektos izpratne bieži uzlabojas darba laikā. Tāpēc labā procesā specifikācija ir pietiekami skaidra startam, bet tiek kontrolēti atjaunota, ja rodas pamatotas izmaiņas.

Biežākās kļūdas ir aprakstīt tikai ekrānus, bet ne procesu; nepieminēt izņēmumus; aizmirst lietotāju tiesības; nenoskaidrot datu avotus; nepārbaudīt integrāciju iespējas. Vēl viena kļūda ir prasīt precīzu cenu bez pietiekamas analīzes. Izstrādātājs var nosaukt aptuvenu diapazonu, bet precīzāks piedāvājums prasa prasību izpratni.

Devera specifikāciju veido kā praktisku darba dokumentu. Tajā tiek sasaistītas biznesa vajadzības, tehniskā arhitektūra un ieviešanas posmi. Tas palīdz izvairīties no situācijas, kur sistēma tiek uzbūvēta tehniski pareizi, bet neatrisina īsto uzņēmuma problēmu.

Specifikācijā īpaši svarīgi aprakstīt ne tikai normālo darba plūsmu, bet arī izņēmumus. Kas notiek, ja klients ir dublikāts? Ja maksājums nav saņemts? Ja vadītājs noraida pieteikumu? Ja ārējā API neatbild? Izņēmumi bieži veido lielāko daļu sarežģītības, un to nepieminēšana rada pārpratumus izstrādes laikā. Laba specifikācija arī nosaka prioritātes. Ne visas prasības ir vienlīdz svarīgas. Dažas funkcijas ir obligātas pirmajai versijai, citas var pagaidīt. Šāds sadalījums palīdz kontrolēt budžetu un ātrāk palaist lietojamu sistēmas kodolu. Specifikācijā vēlams iekļaut datu piemērus. Reāls pasūtījums, klienta kartīte, rēķina paraugs vai statusu saraksts palīdz izstrādātājiem saprast nianses daudz labāk nekā abstrakts apraksts. Tas ir īpaši svarīgi integrācijās un migrācijā. Dokumentam jābūt saprotamam arī uzņēmuma pusei. Ja specifikācija ir tikai tehnisku terminu saraksts, vadība nevar pārbaudīt, vai tajā pareizi atspoguļots process. Devera pieejā specifikācijai jāpalīdz pieņemt lēmumus, nevis radīt dokumentu tikai ķeksītim.

Ieviešanas plānā jāiekļauj ne tikai izstrāde, bet arī uzņēmuma iekšējā sagatavošanās. Jānosaka procesa īpašnieks, jāapstiprina datu struktūra, jāizvēlas lietotāji testēšanai un jāvienojas, kā tiks pieņemti lēmumi par izmaiņām. Bez šīs pārvaldības pat tehniski labs risinājums var kļūt sarežģīti ieviešams. Pēc palaišanas jāparedz mērīšana un uzlabojumi. Sistēma jāvērtē pēc tā, vai tā samazina manuālu darbu, kļūdas un neskaidrības, nevis tikai pēc tā, vai funkcijas ir izstrādātas. Lietotāju jautājumi, kavētie procesi un apietie soļi ir vērtīga informācija nākamajām izmaiņām. Devera individuālas programmatūras projektos šādu pieeju izmanto, lai sistēma nebūtu vienreizējs IT projekts, bet ilgtermiņa darba instruments uzņēmumam.

Specifikācijas kvalitāti var pārbaudīt ar vienkāršu jautājumu: vai neatkarīgs izstrādātājs, izlasot dokumentu, saprastu, kādam jābūt pirmajam darba rezultātam? Ja atbilde ir nē, prasības vēl ir pārāk neskaidras. Specifikācijā jābūt pietiekami daudz informācijas, lai varētu plānot datubāzi, lietotāju plūsmas, integrācijas un testēšanu. Uzņēmuma pusei nevajag baidīties, ka specifikācija “sasaldēs” projektu. Tieši otrādi — tā palīdz izmaiņas apspriest konstruktīvi. Ja vēlāk parādās jauna vajadzība, to var salīdzināt ar sākotnējo apjomu, novērtēt ietekmi uz termiņu un izlemt, vai to iekļaut tagad vai nākamajā kārtā.