Raksta lasīšanai nepieciešamais tehnisko zināšanu līmenis: ⭐⭐⭐⭐⭐ (vidējs) - raksts prasa izpratni par projekta izstrādes dzīves ciklu

Noslēdzoties ieviešanas fāzei, kad izstrādātā sistēma tiek izvietota un ir lietojama klienta vidē, tā ieiet dzīves cikla nākamajā, uzturēšanas, fāzē.
Uzturēšanas fāze ir garākā no fāzēm, jo tā ilgst no brīža, kad sistēma nonāk pie lietotājiem, līdz brīdim, kad to pārtrauc izmantot (tā tiek nomainīta ar jaunāku programmatūras versiju vai arī biznesa procesam šī programmatūra vairs nav nepieciešama), un ir uzskatāms, ka tās dzīves cikls ir noslēdzies.

Uzturēšana sevī ietver trīs galvenos blokus:

1. Kļūdu un potenciālu problēmsituāciju novēršana;
2. Izmaiņu pieprasījumu apstrāde, vienojoties par to izmaksām un ieviešanas termiņiem;
3. Turpmākas sistēmas attīstības darbu plānošana, kas var tikt formēti un izstrādāti kā atsevišķs projekts.

Uzturēšana ir sistēmas pārvaldības process, kura ietvaros tā tiek "pieskatīta" gadījumos, kad rodas apstākļi, kuri izstrādes fāzē netika paredzēti vai kurus nebija iespējams paredzēt, piemēram, būtiskas strukturālas izmaiņas trešo pušu risinājumos, iepriekš neidentificēts datu ievades veids, atšķirīgas datu apstrādes metodes no sākotnēji plānotajām u.c. Uzturēšanā tiek iekļauts arī Pasūtītāja un gala lietotāja atbalsts un konsultācijas, dažādu Izmaiņu pieprasījumu identificēšana un ieviešana, kā arī sistēmas turpmākas attīstības plānošana.

Plānojot sistēmas turpmāku attīstību, ir svarīgi veikt objektīvu tās atlikušā ekspluatācijas resursa novērtējumu - cik ilgi vēl ir lietderīgi izmantot konkrētos risinājumus? Tādējādi nepieciešamu izmaiņu gadījumā būs iespējams pieņemt pamatotus lēmumus par izmaiņu veikšanu esošā risinājuma ietvaros, to atjauninot, vai arī plānojot daļēju vai pilnīgu risinājuma nomaiņu.

Kāpēc ir vajadzīga uzturēšana

Lai izstrādātā programmatūra darbotos ar maksimālu veiktspējas līmeni ilgā termiņā un tiktu nodrošināta tās pieejamības nepārtrauktība, pēc tās ieviešanas sistēmai nepieciešama pastāvīga uzturēšana.

Programmatūras uzturēšanas fāzē izstrādātāji regulāri:

• ievieš dažādus sistēmas atjauninājumus;
• izstrādā un uzliek drošības ielāpus, novēršot potenciālas ievainojamības;
• monitorē un optimizē veiktspēju;
• labo konstatētas kļūdas programmatūras darbībā;
• sadarbībā ar Pasūtītāju identificē Izmaiņu pieprasījumus jeb funkcionalitātes, kas jāievieš, vērtē to darbietilpību un vienojas ar Pasūtītāju par to izstādi. Izmaiņu pieprasījumu ieviešana parasti ir papildu maksas pakalpojums.

Īslaicīgs programmatūras atbalsta periods pēc risinājuma ieviešanas bieži tiek iekļauts Projekta izstrādes līgumā. Šī perioda laikā Pasūtītājam jāpieņem lēmums, vai turpmāk sistēmu uzturēt pašam, slēgt tālāku līgumu ar tās Izstrādātāju vai vienoties ar citu pakalpojuma sniedzēju, kas nodrošinās programmatūras turpmāku uzturēšanu.

Kas ir SLA

Pasūtītājam vienojoties ar Izstrādātāju par programmatūras uzturēšanu, tiek slēgts uzturēšanas līgums, kura būtiska sastāvdaļa ir Vienošanās par Pakalpojuma servisa līmeni jeb SLA (Service Level Agreement).

SLA ir dokuments, kas definē sniegtā pakalpojuma līmeni un tā kvalitātes kritērijus. Tajā apkopoti rādītāji, pienākumi un Pasūtītāja ekspektācijas, kā arī sankcijas gadījumā, ja netiek sasniegts saskaņotais pakalpojuma līmenis.
Minimizējot interpretācijas iespējas, līgumā tiek atrunāta abpusēja rīcība atbalsta nepieciešamības gadījumā, pakalpojuma kvalitātes kritēriji, pakalpojuma pieejamība un abu pušu pienākumi. SLA tiek atrunāta pakalpojuma sniedzēja atbildība un arī apstākļi, kuros tā neiestājas.

SLA var uztvert kā sadarbības rokasgrāmatu.

Kas ietilpst

Šī rokasgrāmata definē sadarbības terminoloģiju, kā arī katras Puses konkrētu sagaidāmo rīcību un rīcības ātrumu, iestājoties pieteikuma gadījumam.

1. Pakalpojumu sniegšanas veidi, kas var tikt iekļauti uzturēšanas līgumā:
   • Lietotāju atbalsts - ietver konsultāciju pakalpojumus, kopējās tikšanās, ja Pasūtītājam radušās neskaidrības par risinājumu darbību vai funkcionalitāti, izmantošanu, uzturēšanu u.c.
   • Kļūdu labošana - ietver programmatūras darbības traucējumu diagnosticēšanas un labošanas pakalpojumus, kuri tiek veikti tās nepareizas darbības un darbspēju atteikumu gadījumā.
   • Sistēmu un tīklu monitorings, risinājuma darbības nepārtrauktības nodrošināšana atrunātā apmērā (piemēram, 99.95% pieejamība 365 dienu laikā). Programmatūras modernizācija un jauninājumi.
   • Izmaiņu ieviešana - nepieciešamo papildinājumu, pielāgojumu un uzlabojumu identificēšana, darbietilpības vērtēšana, saskaņošana ar Pasūtītāju par to izmaksām un ieviešanas termiņu, izstrāde.
2. Pieteikumu reģistrācijas un apstrādes kārtība (kurš, kādos kanālos, kāda ir minimālā obligāti norādāmā informācija, kāda ir apstrādes plūsma u.c.), kas var tikt pielāgota atbilstoši Pasūtītāja vajadzībām vai programmatūras specifikai.
3. Pieteikumu prioritātes līmeņi.
   Prioritāte tiek noteikta, balstoties uz potenciālās problēmas ietekmi uz biznesa procesu “veselību”. Prioritāšu līmeņi un to nozīme tiek detalizēti atrunāti arī līgumā. Prioritāšu noteikšanas piemērs redzams tabulā:

   Pieteikuma kategorija	Pieteikuma raksturojums	Prioritātes līmenis
   Avārija	Nav iespējams veikt kādu būtisku sistēmas funkciju vai to nav iespējams izmantot vispār. Tiek radīti finansiāli zaudējumi Pasūtītājam vai tā partneriem.	Augstākais
   Nozīmīga	Sistēmu iespējams lietot ierobežotā veidā, un nav zināms problēmas apiešanas risinājums.	Augsts
   Mazāk nozīmīga	Sistēmu iespējams lietot ierobežotā veidā, un ir zināms problēmas apiešanas risinājums.	Vidējs
   Nebūtiska	Konstatētas neērtības vai grūtības sistēmas lietošanā, bet nav ietekmētas kritiskās funkcionalitātes.	Zems
   Izmaiņu pieprasījums	Papildinājumu, pielāgojumu un uzlabojumu novērtēšanas un izstrādes pieprasījums.	Zems
   Konsultācija	Pasūtītāja neskaidrība par programmatūras darbību vai funkcionalitāti, izmantošanu, uzturēšanu u.c. Problēmu pieteikumi, par kuriem konsultācijas laikā Puses vienojas, ka problēma faktiski nepastāv.	Zems

4. Reakcijas laiks atbilstoši pieteikuma prioritātei.
   Reakcijas laiks nosaka termiņu, kurā Izstrādātājs pieņem pieteikumu izskatīšanai un uzsāk tā izpildi, informējot Pasūtītāju par potenciālo risinājuma piegādes laiku. Risinājuma piegādes laiks ir brīdis, kad piegādāts risinājums pieteiktajai problēmai.
   Atslēga ir vienoties par tādiem SLA noteikumiem, kas abām Pusēm šķiet godīgi un ir objektīvi izpildāmi. Piemēram:
   • Puses var vienoties, ka augtākās prioritātes pieteikuma reakcijas laiks ir N h no pieteikuma reģistrēšanas brīža, savukārt zemākās - 4xN h.
   • Var tikt atrunāts pieteikumu pieņemšanas un apstrādes laiks (piemēram, darba dienas no 9:00 līdz 18:00).
   • Kā arī var tikt iekļauta vienošanās, ka Izstrādātājs avāriju gadījumā ir gatavs reaģēt arī ārpus darba laika, bet šim laikam tiks piemērota dubulta stundas likme.
5. Garantētais darba apjoms mēnesī.
   Puses var vienoties par Garantēto stundu skaitu mēnesī: Izstrādātājs garantē šo stundu pieejamību, savukārt Pasūtītājs - pasūtījumu nodrošināšanu atbilstošajā apmērā.
   Šādā gadījumā līgumā tiek ietvertas atrunas par to, kādā kārtībā un ar kādu reakcijas laiku tiek apstrādāti pieteikumi, kas pārsniedz garantēto stundu apjomu, kā arī kas notiek gadījumos, kad Pasūtītājs nevar mēnesī nodrošināt darbus šo stundu apjomā.
6. KPI un metrikas saistību izpildes kvalitātes mērīšanai (reakcijas laiks, garantētā laika nodrošināšana u.c.), Pušu atbildības par saistību neizpildi.