Programmatūras iegāde


Programmatūras iegāde

IT speciālisti zina stāstīt, ka bija laiki, kad klīda nostāsti par veikliem darboņiem, kuri prata pārliecināt pasūtītāju, ka 200 megabaitu disks mēneša laikā nodilst līdz 20 megabaitiem, bet programmatūra „karas” tāpēc, ka biti sprūst šaurajā kabelī. Lai gan šie laiki ir jau (cerams) pagājuši, tomēr izpratne par programmatūras izstrādi nāk tikai par labu savstarpējai pasūtītāja un izstrādātāja sadarbībai. Cik dziļa izpratne nepieciešama – vai pietiek notiekošo saprast vispārīgos vilcienos, vai nepieciešams pamatīgi iedziļināties, tas ir atkarīgs no konkrētā projekta specifikas un ar to saistītās pasūtītāja motivācijas iedziļināties programmatūras izstrādes niansēs. Lai kā būtu progresējušas modernās tehnoloģijas, programmatūras iegādes stūrakmens joprojām ir sadarbība starp cilvēkiem ar visām no tā izrietošajām pozitīvajām un ne tik pozitīvajām sekām.

Kāpēc IT speciālisti mīl piesaukt dažādus standartus?

IT nozare ir salīdzinoši jauna, un tās attīstība bija izkliedēta pa visu pasauli un norisinājās paralēli neskaitāmās vietās, līdz ar to pasaulē uzkrājās milzīgs pieredzes apjoms par to, kādi procesi norisinās izstrādē, kādu informāciju un kur vērts iekļaut un kā izstrādi vadīt. Nozares standarti patiesībā ir šīs pieredzes apkopojums, esence, kurus var iedalīt divās lielās grupās:

  • procesu aprakstošie standarti,
  • gala rezultātu aprakstošie standarti.

Standartus pamatā izmanto, lai:

  1. demonstrētu, ka organizācija strādā pēc pasaulē atzītas un rekomendētas sistēmas un veic nepieciešamās aktivitātes – šajā gadījumā deklarē procesa atbilstību standartam,
  2. apliecinātu, ka organizācijas sagatavotie izstrādātie produkti, t.sk. dokumenti satur noteiktus informācijas vienumus, kuru esamība ir obligāts priekšnosacījums produkta kvalitātei – šajā gadījumā deklarē produkta atbilstību standartam,
  3. pasūtītājam būtu atskaites punkts, pret ko novērtēt saņemtā produkta kvalitāti papildus savām tiešajām prasībām. Piemēram, ir pasūtīts dokuments „Programmatūras prasību specifikācija”. Teorētiski, ja līgumā figurē tikai šāds nododamā dokumenta nosaukums bez jebkādām citām kvalitāti raksturojošām prasībām, kas var liegt izstrādātājam uzrakstīt 2 lapiņas ar tekstu, nosaukt to par „Programmatūras prasību specifikāciju” un iesniegt? Lai izvairītos no šādas situācijas, ir vairāki risinājumi, tostarp: pieprasīt atbilstību standartam, veidot darba grupu kopīgām dokumenta apskatēm izstrādes laikā, var piesaistīt konsultantus no malas, bet noteikti ir jābūt prasībai par rezultāta atbilstību kaut kam, lai būtu uz kā pamata pieprasīt produkta kvalitātes uzlabošanu.

Vērtējot dokumentu atbilstību IT izstrādes standartiem, ir jāsaprot, ka šajā jomā nav jānodrošina mehāniska 1:1 atbilstība. Galvenais, lai standartā rekomendētie vai pieprasītie informācijas vienumi būtu tādā vai citādā veidā atrodami attiecīgajā dokumentā. Citās nozarēs atbilstību standartam izmērīt ir salīdzinoši vienkāršāk, ja, piemēram, ir zināms, ka produkta garumam jābūt 37 centimetri vai kādas vielas daudzumam jābūt starp 3 un 4 procentiem.

IT izstrādē absolūta atbilstība standartam tiek prasīta reti un nereti ir pat kaitīga, jo standarti tomēr cenšas pārklāt pēc iespējas vispārīgāku gadījumu, paredzot visdažādākās situācijas, tāpēc praksē standartus parasti pielāgo konkrētā projekta vajadzībām. Pielāgošana notiek vai nu darba grupā kopā ar pasūtītāju (ieteicamais variants), vai pasūtītājs jau pirms līguma noslēgšanas ir pats veicis gala rezultāta prasību pielāgošanas procesu, vai izstrādes laikā izstrādātājs veic standartu pielāgošanu un nodevumā demonstrē tā atbilstību standartam, sniedzot pamatojumu, kāpēc šis pielāgojums būtu uzskatāms par atbilstošu standartam.

 Bieži novērota problēma ir standartu pārāk burtiska un formāla interpretēšana, nonākot līdz pat tādam absurdam, ka tiek pieprasīta, piemēram, prasību specifikācijas satura rādītāja pilnīga atbilstība standartam, kā rezultātā dokumentā ir sastopami pat desmitā līmeņa virsraksti (kas ir slikta prakse no tehniskās rakstīšanas viedokļa), jo standartā ir iekļauts satura rādītāja piemērs, kurā visas funkcionālās prasības ietilpst vienā nodaļā. Praksē lielai un sarežģītai informācijas sistēmai tas nozīmē papildus strukturēšanu un liekus līmeņus virsrakstos, kas apgrūtina gan strukturēšanu, gan dokumenta uztveršanu, gan papildus tērē speciālistu laiku.

 Programmatūras iegāde – projekts projektā

Standarts 1062-1998 IEEE Recommended Practice for Software Acquisition iesaka programmatūras iegādi organizēt kā projektu, kurš sākas brīdī, kad tiek izskatīta ideja par programmatūras iegādi, un beidzas brīdī, kad programmatūra vairs netiek izmantota. Šī iegāde sastāv no vairākiem etapiem – plānošana, līguma slēgšana un kvalitātes prasību definēšana, sadarbība programmatūras izstrādes laikā, pieņemšana un lietošana, kas katrs savukārt sastāv no procesiem, starprezultātiem un rezultātiem. Tātad sadarbība starp produkta pasūtītāju un produkta piegādātāju ir savstarpēji saistītu procesu kopums, kuru norisē katra no iesaistītajām pusēm piedalās ar dažādu līdzdalības un atbildības pakāpi, un šo sadarbību abpusēji jāprot vadīt un uzturēt.
Projekta gaitā abpusēji jāvienojas gan par dažādām formalitātēm, kvalitātes nodrošināšanas pasākumiem, gan par konkrētiem pienākumiem, piemēram, savstarpēji jāsaskaņo produkta nodošanas/pieņemšanas procedūra, jāvienojas, par programmatūras pieņemšanas kritērijiem, par atklāto kļūdu dokumentēšanu, smaguma klasifikāciju, to ziņošanu izstrādātājam un daudziem citiem sadarbības aspektiem.

Praksē IT izstrādātāji parasti piedāvā saskaņot savus procedūru un nolikumu variantus, vismaz būtiskākos, tomēr ļoti ieteicama ir pasūtītāja izpratne un savs skatījums par to, kuras procedūras ir būtiskākās un kas jāņem vērā, tās saskaņojot.

Sadarbības modeļi programmatūras iegādes projektā

Programmatūras iegādes projekta organizācijā var būt vairāki sadarbības modeļi.

       a) Pasūtītājs pilnībā pārzina izstrādes procesus, brīvi orientējas to organizēšanā, spēj formulēt nepieciešamos nodevumus, prasības to kvalitātei, kā arī novērtēt saņemto rezultātu atbilstību savām vajadzībām (prasībām).

Šāds modelis praksē ir efektīvs un tiek iegūts labs rezultāts. Jo kvalitatīvāk noformulētas prasības un lielāka izpratne izstrādes laikā, jo izstrādātājam vieglāk plānot un koncentrēt savus resursus tieši prasībām atbilstoša produkta izstrādei.

       b) Pasūtītājs sadarbībā ar izstrādātāju kopīgiem spēkiem formulē savas prasības, izstrādā un saskaņo dažādo savstarpējās sadarbības procesu dokumentus (izmaiņu vadības padomes nolikumu, dokumentu konfigurācijas pārvaldības procedūru u.c.).

Latvijā praksē visbiežāk izmantotais modelis. Pasūtītāja darbinieki paši organizē un vada programmatūras iegādi. Lai to paveiktu, tiek gan meklēti darbinieki ar atbilstošām iemaņām, gan apmeklētas dažādas apmācības, gan tiek studēta literatūra par IT projektu izstrādi.

        c) Pasūtītājs piesaista konsultantu, kurš kopā ar pasūtītāju sagatavo nodevumu sarakstu, kvalitātes prasības katram nodevumam un dažādu procesu dokumentāciju vai vismaz tās kvalitātes kritērijus. Sadarbību ar izstrādātāju pamatā veic pasūtītājs pats, nepieciešamības gadījumā piesaistot konsultantus.

Arī šis risinājums tiek diezgan bieži praktizēts, sevišķi valsts iestādēs un organizācijās, kuru pamatbizness ir stipri atšķirīgs no IT. Konsultanta slēdziens par nodevuma kvalitāti gan atvieglo pasūtītāja darbu, gan kalpo par kāda pieņemta lēmuma pamatojumu.

        d) Pasūtītājs programmatūras iegādi uztic zinošam „būvuzņēmējam”, deleģē tam sevis pārstāvēšanu sadarbībā ar izstrādātāju un pats piesaistās tikai finansēšanā un gala produkta lietošanā.

Dārgs un riskants risinājums, kura laikā tāpat jāsadarbojas ar „būvuzņēmēju” un jānodrošina, lai prasības vienādi saprot gan „būvuzņēmējs”, gan izstrādātājs. Praksē izrādās, ka arī šajā gadījumā pasūtītājam tomēr ir nepieciešama izpratne par programmatūras izstrādes un iegādes procesiem un nenotiek tā, ka kāds no malas atnāk un izdara pilnīgi visu.

Kur var iegūt zināšanas par programmatūras iegādi?

Diemžēl kompānijām, kuru vārds tirgū vēl nav nostabilizējies, mēdz būt arī interese par to, kādas ir pasūtītāju vājās vietas un kā tās var izmantot savā labā. Lai no tā pasargātos, ieteicams programmatūras iegādē iesaistīt zinošus speciālistus, pilnīgai drošībai – apvienojumā ar izstrādātāju, nozarē labu reputāciju iemantojušu stabilu kompāniju.

Veidi, kā iegūt programmatūras iegādes projektu pārvaldībai nepieciešamās zināšanas, ir vairāki, sākot no akadēmiskām studiju programmām, turpinot ar apmācību kursiem, konferencēm un profesionālajiem semināriem. IT izstrādes kompāniju mājas lapās nereti ir atrodami līdzīgu apmācību piedāvājumi, jo kam gan, ja ne pašām izstrādātāju kompānijām ir vislabāk zināma nozares virtuve, kā arī ir vērā ņemama pieredze gan par to, kā vajadzētu rīkoties, gan par to, kā nevajadzētu. Zināmākā no kompānijām ar līdzīgu apmācību ilggadēju piedāvājumu bija Rīgas Informācijas tehnoloģijas institūts.

Pasūtītāja darbinieki noteikti jāapmāca izstrādāto procesu konceptuālo risinājumu lietošanā, pielāgošanā un ieviešanā organizācijā. Iespējams izmantot dažādas savstarpēji saskaņotas apmācību formas – mācību materiālus, atsevišķu pasūtītāja darbinieku – tālāko konsultantu sagatavošanu, visu iesaistīto darbinieku apmācīšanu, seminārus u.c.

Pirms apmācībām jānoskaidro pasūtītāja priekšzināšanas, jo pilnīgi iespējams, ka daudzi no nozares terminiem var būt pasūtītājam nezināmi vai maz zināmi, piemēram, dokumenta dzīves cikls, izmaiņu pieprasījums, problēmziņojuma dzīves cikls, apskate, akcepttestēšana un citi. Svarīgi, lai apmācībās un izstrādātājos mācību materiālos katram no tiem būtu skaidrojums pasūtītājam uztveramā līmenī.

P.S. Raksts tapis 2005.gadā, bet vērtēju, ka joprojām aktuāls

Advertisements

2 responses to this post.

  1. Posted by Ģirts on 07/03/2011 at 18:25

    Pārāk gari un pārāk sausi.

    Like

    Atbildēt

Mans viedoklis:

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: