Archive for the ‘Dokumentēšana’ Category

Īsa pamācība problēmu ziņošanā


Katrā jokā ir daļa joka. Arī šajā:  Новое телешоу: «Битва IT-экстрасенсов» – IT-шники проникают в головы юзерам и угадывают, что они нажали и почему “ничего не работает”

Retorisks jautājums: ko lai dara IT atbalsts (nereti tas ir sistēmanalītiķis), saņemot šādas sūdzības?

  • nevaru ieiet ministrijā! (nestrādāja ministrijas mājaslapa)
  • nekas nestrādā! (drukāšanas spiedpoga nepieejama)
  • es neko nedarīju, bet neko nevaru padarīt! (lietotājvārda un paroles lauciņus bija sajaucis vietām)

Sūdzībām par IT kļūdām vai nepilnībām ir divi iemesli:

a)      cilvēks vēlas atvest dvēseli – tad var tālāk šo nelasīt un turpināt kaitināt mūs ar saviem „nekas neiet!”. Bez šaubām, arī šada atgriezeniskā saite ir vairāk kā nekas un ir iemesls aizdomāties.

b)      cilvēks vēlas saņemt palīdzību vai risinājumu. Tālākā tekstā daži ieteikumi, kā to sasniegt. Ceru, ka komentāros padalīsieties ar savu pieredzi par to, kādus problēmziņojumus patīk un kādus nepatīk sūtīt/saņemt, lai mums šeit ir kas vairāk par manu subjektīvo viedokli.

  1. Norādīt programmu un versiju.
  2. Soli pa solim aprakstīt veiktās darbības, lietojot tādus nosaukumus, kādi ir programmā. Uzrakstīt, kurā laukā un kādus datus ievadīja un kad ko nospieda.
  3. Kļūdu ziņojumus citēt, nevis tēlaini pārstāstīt un interpretēt. Ideālā gadījumā – pievienot ekrāna attēlu. Šeit arī mans aicinājums visiem, kuri problēmas pieteikumu nodrošina webformā: nodrošināt iespēju pievienot failu ar attēlu! Vēlams, lai papildus kļūdas ziņojumam attēlā ir redzama programmas versija, pārlūkprogrammas adrese (ja ar pārlūkprogrammu darbina), pulksteņlaiks. Personīgus konkrētus datus drīkst aizkrāsot. Ja tie dati ir tādi pavisam personīgi, tos pat vajag aizkrāsot – lai gan IT speciālistus parasti saista ļoti nopietnas konfidencialitātes saistības un arī darba ētika nepieļauj izpaust darba informāciju, tomēr pašā sūtīšanas procesā uz e-pastu vai mazums kas var gadīties.
  4. Norādīt, vai problēma ir atkārtojama. Ja ir informācija, kad problēma pirmo reizi parādījās vai kad tās vēl nebija – norādīt arī to.
  5. Ja ir – sniegt savus ieteikumus vai aprakstīt savu vēlmi, ko sagaida no IT atbalsta. Acīmredzamu kļūdu gadījumā, protams, skaidrs, ka sagaida problēmas novēršanu, taču tādi acīmredzamu kļūdu tīrradņi ir retāki nekā situācijas, kur lietotājam šķiet, ka ir uztaisīts nepareizi. Var gadīties, ka IT cilvēki negribēs uzsākt spēlīti „mēģināsim uzminēt, ko no mums īsti grib”.
  6. Izmantotā pārlūkprogramma (ja ar pārlūkprogrammu darbina).
  7. Norādīt, vai problēma pastāv, ja veic līdzīgas darbības ar citiem datiem (ja, piemēram, nevar saglabāt viena veida dokumentu, vai izdodas saglabāt cita veida dokumentu? Kāda?)
  8. Norādīt, vai problēma pastāv, ja cits lietotājs no šī paša datora pieslēdzas un veic minētās darbības.
  9. Norādīt, vai problēma pastāv, ja pats pieslēdzas no cita datora ar to pašu lietotāja vārdu un paroli.
  10. Norādīt savu kontaktinformāciju  un ļaut noprast, vai precizējoši jautājumi tiek laipni gaidīti :-)

Nevēlams piemērs:

Pēc saglabāšanas saņēmu kļūdu ka it kā neesot pareizi sarēķināts – tas nav taisnība!

Labāks piemērs:

  1. Pieslēdzos sistēmai X, versija 1.2.33.
  2. Izvēlnē „Sākt ievadi” izvēlējos veidot jaunu dokumentu „Dokumenta nosaukums” un ieliku ķeksīti pie „veidošu tiešsaistē”.
  3. Atvērās ievadforma. Laukā A ievadīju 5, B ievadīju 2, C ievadīju 10, D atzīmēju radiopogu „Bez PVN”.
  4. Nospiedu pogu [Saglabāt]. Parādījās kļūdas ziņojums „Laukā C norādītā vērtība neatbilst formulai A*B”.
  5. Problēma ir atkārtojama, kad veicu šīs pašas darbības vēlreiz.
  6. Izmantoju pārlūkprogrammu MS Internet Exprorer 8.0.123. Problēma ir atkārtojama arī ar Mozilla FireFox.
  7. Problēma neatkārtojas, ja uz mana datora sistēma ar to pašu pārlūkprogrammu pieslēdzas cits lietotājs un veic šīs pašas darbības.
  8. Problēma atkārtojas, ja ar savu lietotājvārdu un paroli pieslēdzos no cita datora.
  9. Problēmu konstatēju 14.12.2011. Iepriekšējo reizi šādas darbības veicu 12.12.2011 un problēmas nebija.
  10. Pievienoju ekrāna attēlu.
  11. Lūdzu 1) novērst problēmu, ka parādās ziņojums par C  neatbilstību formulai, lai gan ievadītā vērtība ir korekta un formulai atbilst un 2) atļaut laukā C ievadīt arī formulai neatbilstošas vērtības un par nesakritību parādīt informatīvu brīdinājumu, nevis kļūdas ziņojumu.
  12. Tālrunis saziņai: 67654321, e-pasts aaa@bbb.cc – droši jautājiet, ja nepieciešams.

Paldies!

Par procesu īsumā

Sadarbībā Pasūtītājs – Programmatūras uzturētājs parasti līgumos ir atruna, ka darba gaitā vienosies par noteiktu problēmziņojumu apstrādes un kļūdu un defektu novēršanas procesu, tajā skaitā arī par to, kāda informācija iekļaujama problēmziņojumā. Šāda pieeja izmantota, piemēram:

Valsts vides dienesta informācijas sistēmas izstrāde un ieviešana

VSAA Likumdošanas izmaiņu realizēšana SAIS

Robežapsardzības informācijas sistēmas „RAIS 2009” izveidošana. Kvalitātes nodrošināšanas plāns

Viens no detalizēta apraksta piemēriem – par procesu, ne paša problēmziņojuma saturu (tas tur nav definēts), ir , piemēram, Valsts ieņēmumu dienesta rīcībā esošās izmaiņu pārvaldības sistēmas apraksts – tur var gūt priekšstatu par to, ka problēmas ziņojums ir “objekts”, kurš tiek pakļauts nopietnai apstrādei. IT nozarē problēmziņojumu apstrāde notiek projekta kvalitātes pārvaldības ietvaros un pašu apstrādes procesu mēdz saukt par problēmziņojumu un izmaiņu pieprasījumu pārvaldību. Bieži tiek lietotas abreviatūras PZ (problēmziņojums, problēmas ziņojums, problēmas pieteikums) un IP (izmaiņu pieprasījums). Nopietnos projektos problēmziņojumu apstrādes ietvaros no IT speciālistiem tiek prasīta atbildība par rezultātu, tiek analizēts veiktais darbs, nepabeigto pieteikumu statistika, veikti dažnedažādi citi mērījumi par darba kvalitāti un veikti arī citi pasākumi, lai stimulētu vēlmi reaģēt uz problēmziņojumiem: atrisinot vai pieteicējam korekti izskaidrojot, kāpēc ir tā kā ir.

Gala lietotāji

Ja Pasūtītājs – Izpildītājs līgumu gadījumā vēl ir salīdzinoši viegli iedibināt kārtību, kā noformulēt problēmziņojumus, tad grūtāk ir gadījumā, kad par problēmu ziņo gala lietotājs, ar kuru nav slēgti ne līgumi vai vienošanās par PZ saturu, ne veikta apmācība, kā pareizi pieteikt problēmu. Materiālu ir diezgan maz un maz arī ticams, ka lietotājs pirms problēmas ziņošanas (gadās kā sinonīms “emociju izlikšanas”) meklēs – nu kā tad to pareizi darīt. Tas arī saistīts kā ar konkrētā cilvēka komunikācijas iemaņām un emocionālo inteliģenci, tā ar vispārējo izpratni, ka tas par IT-sensiem taču ir tikai joks.

Akadēmiskajās apmācībās

Par problēmu ziņošanu parasti runā saistībā ar testēšanu un testēšanas gaitas dokumentēšanu, ne reālo lietošanu. Piemēram:

Latvijas Universitāte: “Problēmas apraksts. Katrai problēmai tiek pievienots apraksts, kurš varētu sastāvēt no sekojošiem vienumiem: ievades, gaidāmajiem rezultātiem, faktiskajiem rezultātiem, anomālijām, datuma un laika, procedūras soļa, vides, mēģinājumiem atkārtot, testētājiem, novērotājiem. Katrā ziņā šajā nodalījumā ir jācenšas sniegt pēc iespējas plašāku informāciju, lai spētu problēmu novērst.”

LLU Informācijas Tehnoloģiju fakultātes studentu mācību projekts: “Ja eksistē un ir fiksēta problēma vai kļūda, tā jāapraksta pēc iespējas norādot visu informāciju, kas varētu būt nepieciešama problēmas novērsējam(-iem). Piemēram, apraksta, kāda ir programmas reakcija uz dotajām komandām.”

Ja lasāt kāds akadēmiskās vides pārstāvis – lūdzu, ieguldiet savu artavu arī jūs problēmziņošanas darbaudzināšanā.

IT cilvēkiem

Tomēr – nav ko bārt lietotājus par dīvainiem problēmziņojumu formulējumiem, bet:

  1. Protams, protams, rakstīt programmas bez kļūdām. :-)
  2. Veidot sistēmu tā, lai no esošajiem datiem iespējams diagnosticēt problēmu pat nesagaidot lietotāja pieteiktu ziņojumu.
  3. Nodrošināt iespēju ērti paziņot par radušos problēmu, pasakot priekšā, kāda informācija tiek gaidīta, un ar iespēju pievienot pielikumu. Nokaitināts lietotājs, kuram nav iespējas darīt zināmu savu bezgalīgo un pamatoto sašutumu, atradīs iespēju to paust, ticiet man – bet tas jau būs Delfu vai Tvnet komentāros, tviterī u.tml.
  4. Sūtot lietotāja ziņojumu no programmas, automātiski pievienot tehnisku informāciju, kas palīdzēs diagnosticēt.
  5. Kad ir iespējams, izglītot, ka IT atbalsts ir nevis robotu bars vai melnais caurums, kurā neatgriezeniski sabirst nabaga cilvēku sūri grūti rakstītie teksti, bet ir dzīvi cilvēki, kuri gan grib palīdzēt, gan cer saņemt precīzu, izsmeļošu informāciju.
  6. Portāliem, kurus lieto jaunieši, problēmu ziņošanu organizēt sevišķi pārdomāti un savā ziņā uzņemties viņu problēmziņošanas kultūras veidošanas un audzināšanas lomu.
  7. Aicināt nevis “ziņot par kļūdu” vai “pieteikt problēmu”, bet aicināt “sniegt ieteikumus uzlabošanai”, “izteikt viedokli”, “sazināties ar izstrādātājiem” – kaut kā tā.

No manas pieredzes par problēmu ziņošanu

Atzīšos, esmu aktīva kā nātrijs – ja pamanu kļūdu vai nepilnību – informēju par to, negaidot, ka problēma gan jau uzsūksies. Galu galā – labākajā gadījumā manu ieteikumu ņems vērā, sliktākajā – nu pa galvu taču nesitīs.

www.latvija.lv – šodien, 16.12.2011 neatradu iespēju nosūtīt problēmziņojumu, bet esmu pirms kāda laika sūtījusi. Iespaids toreiz bija graujoši slikts un to stāstīju studentiem kā ļoti sliktas prakses piemēru: milzīgs teksta ievadlauks, pēc kura aizpildīšanas un mēģinājuma nosūtīt – parādījās kļūdas ziņojums, ka atļauti tikai 250 simboli! Lieki piebilst, cik dusmīga biju par veltīto laiku izsmeļošam aprakstam (vēl trakāk bija vienā citā portālā, kur pēc rūpīga apraksta nosūtīšanas mēģinājuma saņēmu “Neizdevās nosūtīt!” – un forma tika attīrīta bez iespējas atgūt ievadīto tekstu). Toreiz vairākas reizes Latvija.lv rakstīju ieteikumus (katru no tiem tātad bezmaz vai tvitera formātā) – piemēram, palielināt ziņojumā atļauto simbolu skaitu, vismaz papildināt nosaukumu “Problēmas apraksts (līdz 250 simboliem) vai uzlikt ievadlauka ierobežojumu, lai fiziski nevar ierakstīt garāku, šādā gadījumā jauki būtu arī skaitītājs, cik simbolu vēl atlicis – kā tviterī. Šodien neredzu iespēju “Nosūtīt ziņojumu”:

Swedbank internetbanka  – nebija viegli iedomāties, ka iespēja nosūtīt ziņojumu meklējama zem „Noderīga informācija”. Esmu sūtījusi desmitus reižu. Atbild ātri, profesionāli un argumentēti, ar pateicību par izrādīto interesi un norādes uz nepilnībām patiešām tiek ņemtas vērā.

VID EDS demo versija (Identifikators demo, parole demo), no kuras ņemts attēls – produkcijas VID EDS sistēmā ir tieši tāda pati iespēja – atrodama salīdzinoši vienkārši: izvēlne „Sūtīt vēstuli” un var izvēlēties vajadzīgo tēmu. Procesu neesmu izmēģinājusiVID mājaslapā ir arī adrešu saraksts, uz kuru var sūtīt e-pastu, t.sk. par problēmām:

E-csdd.lv: ir labi saskatāma kontaktu sadaļa, iesūtīt pieteikumu var tikai e-pastā. Tiesa, uz manu 21. oktobrī nosūtīto jautājumu uz norādīto palidziba@… tā arī nesaņēmu atbildi, bet tas ir cits stāsts.

Līdzīga pieeja – kontaktu sadaļa ir izmantota arī Rīgas pašvaldības pakalpojumu portālā:

Lattelecom iespēju nosūtīt problēmas ziņojumu arī atrodu salīdzinoši viegli. Neesmu izmēģinājusi:

Kā redzējāt no piemēriem, vairākums aprakstu ievadāmi vai sūtāmi uz e-pastu brīvā tekstā, tātad – cerams, izmantosiet šajā rakstā sniegtos ieteikumus :-)

Starp citu – Rīgas tirdzniecības tehnikuma Helpdesk – viena no retajām vietām, kur atradu, ka problēmziņojumu var pieteikt daļēji strukturētā veidā:

Katram gadījumam piebildīšu, ka nepretendēju uz visaptverošu apskatu vai rūpīgu, metodisku analīzi ar vispārinošiem secinājumiem. Šie ir daži no tiem, ar kuriem man pašai ir bijusi saskare vai kurus izdevās ātri atrast ar Google meklētāju.

Paldies visiem lasītājiem par pacietību un sevišķi liels paldies visiem, kuri komentāros ierakstīsiet savas domas un piedzīvojumus, kā arī dosiet arī norādes uz  konkrētiem piemēriem.

Advertisements

Kvalitatīvas lietotāju dokumentācijas izstrāde


Šajā rakstā aplūkoti kvalitatīvas lietotāja dokumentācijas izstrādes aspekti, aprakstot dokumentācijas tapšanas procesā veicamos uzdevumus un sniedzot praktiskus ieteikumus.

Ievads

Analizējot veiksmīgi un neveiksmīgi iedzīvinātu programmatūru izstrādes pieredzi, redzams, ka galvenokārt tieši no programmatūras gala lietotāju apmierinātības ir atkarīgs, vai konkrētā programmatūra iedzīvosies (ar administratīvām metodēm vien programmatūru uzturēt pie dzīvības iespējams īslaicīgi). Programmatūras izstrādātājs, kurš parasti ir ieinteresēts produkta veiksmīgā iedzīvināšanā, pārsvarā komunicējas ar pasūtītāja pārstāvjiem un dažādu iemeslu dēļ nereti vispār nestrādā ar gala lietotājiem. Kā komunikācija ar tiem kalpo:

1)      pati programmatūra,

2)      lietotāja dokumentācija

un sekmīga rezultāta sasniegšanai tām abām jābūt kvalitatīvi izstrādātām. Šajā rakstā aplūkoti lietotāja dokumentācijas izstrādes aspekti, ar lietotāja dokumentāciju saprotot tradicionālo, drukāto dokumentāciju un tādu, kas lietojama analogi drukātai.

Lietotāja dokumentācija

Lietotāja dokumentācija

Lietotāja dokumentācijā esošo informāciju bieži vien izmanto programmatūras palīga veidošanai un mācību materiālu izstrādē. Veicot pasūtītāja darbinieku apmācību darbam ar programmatūru, ieteicams lietotājus iemācīt strādāt arī ar lietotāja dokumentāciju.

Izplatītākie stereotipi un patiesība par dokumentētajiem un dokumentēšanu

Pastāv vesela kaudze ar stereotipiem – ka izstrādāt lietotāja dokumentāciju ir ļoti vienkārši, ka to var darīt jebkurš, kurš prot lietot Word, ka dokumentēšana ir vienmuļa un garlaicīga. Izplatītākie stereotipi un patiesība par dokumentētajiem un dokumentēšanu ir šādi:

Stereotips Patiesība
“Uzrakstīt manuāli – kas var būt vienkāršāk par to” Kvalitatīva lietotāju dokumentācija, kura tiek izstrādāta nevis formālam nodevumam, bet gan reālai lietošanai, ir nopietns, plānojams un rūpīgi vadāms darbs, kurš prasa gan IT, gan psiholoģijas zināšanas, gan atbilstošas rakstura iezīmes.
Dokumentētāja darbā praktiski nekādas zināšanas nevajag, pietiek, ja prot rakstīt Word Dokumentētājam jābūt divdabim: gan labi jāorientējas IT, gan jābūt apveltītam ar izcilu valodas izjūtu un teicamām gramatikas zināšanām (labi, ja ir akadēmiskā izglītība vienā no šīm sfērām, tomēr filologa izglītība negarantē izcilu rezultātu – pārbaudīts praksē). Jāzina par  cilvēka uztveres īpatnībām un jāpārzina kvalitatīvas lietotāja saskarnes principi. Zinošus dokumentētājus bieži vien iesaista kā konsultantus lietotāja saskarnes izstrādē, testēšanā un uzlabošanā.
Par dokumentētāju var kļūt jebkurš Dokumentētājam gan jāspēj veikt rutīnas darbs un pedantiski jāievēro projektā pieņemtie darbu reglamentējošie dokumenti un norunas, gan jāpiemīt iniciatīvai, radošai dzirkstij un fantāzijai, lai spētu lietotājiem saprotami izskaidrot sarežģītas lietas.
Dokumentēšanā var iesaistīt īslaicīgi bez darba esošos darbiniekus Īslaicīgai piesaistei bez iepriekšējas apmācības un pieredzes var piesaistīt uz laiku citus darbiniekus, taču šādā situācijā būtiski palielinās risks, ka dokumentētāji aprakstīs to, ko zina, nevis to, ko vēlas zināt lietotājs. Šādā īslaicīgas piesaistes gadījumā nepieciešama sevišķi profesionāla dokumentācijas procesa vadība, rūpīgi izvēloties konkrētus uzdevumus šiem dokumentētājiem un pārraugot to izpildi.
Dokumentēšana ir vienmuļa un garlaicīga Tā varētu šķist, ja darbu veic steigā un formālam nodevumam. Strādājot motivētā komandā un sakārtotā izstrādes vidē, dokumentēšana ir profesionāli izaicinošs un aizraujošs process, dialogs ar lietotāju un nemitīgi jāizdomā veidi, kā lietotāju iemācīt, kā palīdzēt saprast, kā izskaidrot, kā uzminēt utml.
Laba dokumentācija var izglābt sliktu programmu. Ja programmatūra izstrādāta nekvalitatīvi un ir neērta darbam, dokumentācijā jāsniedz ieteikumi un risinājumi (workarounds), taču vislabākā dokumentācija neizglābs no bojāejas sliktu programmu.

Patiesībā kvalitatīvas lietotāja dokumentācijas izstrādāšana ir nopietns un sarežģīts darbs, kura veikšanai gan jāpārzina konkrētais problēmapgabals, gan jābūt IT speciālistam, gan jāpiemīt labām komunikācijas (sevišķi rakstiskās) spējām. No vienas puses dokumentētājam jāspēj pedantiski veikt rutīnas darbs, no otras puses jāpiemīt radošai dzirkstij, lai spētu lietotājiem saprotami izskaidrot sarežģītas lietas. Zinošs dokumentētājs parasti pārzina labas lietotāja saskarnes principus un var ieteikt uzlabojumus programmatūras lietotāja saskarnei, jo dokumentācijas izstrādes laikā var labi pamanīt nekonsekvences. Iesaistot dokumentēšanā cilvēku no malas, palielinās risks, ka dokumentētājs aprakstīs to, ko pats zina, nevis to, ko nepieciešams zināt lietotājam.

Lietotāja dokumentācijas komplekta saturs

Lietotāja dokumentāciju parasti sastāda triju veidu dokumenti, kuros dažādos griezumos tiek sniegta informācija par programmatūru un tās darbināšanu (divi pirmie dokumenti var būt apvienoti vienā, skaidri nodalot šos pēc būtības atšķirīgos materiālus):

1)    lietotāja instrukcija – programmatūras darbināšanas apraksts, kas ietver pilnu programmatūras aprakstu, paskaidrojot katru tā elementu (tipveida elementus, logus, katra loga visus laukus, visas ieprogrammētās pārbaudes, ziņojumus, utt.).

2)    lietotāja rokasgrāmata – skaidrojums par to, kā ar šīs programmatūras palīdzību izpildīt to vai citu funkciju (t.s. scenāriju), kas ietver programmatūras elementu savstarpējo sadarbību, izsaukšanas secību, funkcionalitātes ierobežojumus u.c.

3)    administratora rokasgrāmata – sistēmas administratoriem paredzēta dokumentācija, saistīta ar dažādu specifisku funkciju veikšanu.

Dokumentācija var sastāvēt no vie­na vai vairākiem dokumentiem atkarībā no izklāstāmās informācijas apjoma un audi­to­rijas vajadzībām. Parasti jaunai programmatūrai sākotnēji izstrādā gan instrukciju, gan rokasgrāmatu, sevišķi, ja auditorijas lielākā daļa ir nepieredzējuši lietotāji. Vairāku gadu prakse rāda, ka pieredzējuši datorlietotāji labprātāk strādā ar rokasgrāmatām (jo lietotājam pēc būtības savā darbā jāveic konkrētas biznesa funkcijas, nevis jāaizpilda atsevišķas formas, nekā ar instrukcijām, tāpēc līdz ar atjauninātu programmatūras versiju parādīšanos ir vērts vākt un analizēt lietotāju ieteikumus par to, vai vērts turpmāk uzturēt abu veidu dokumentus.

Lietotāja dokumentācijas plānošanas etaps

Kvalitatīvas lietotāja dokumentācijas izstrāde ir plānota aktivitāte, projekta komandā laikus plānojot un iesaistot dokumentēšanas speciālistus. Dokumentācijas plānošanas etapā jāveic šādi uzdevumi:

  • ­jādefinē izstrādājamo dokumentu komplekts un jāiden­tificē mērķauditorija, lai noteiktu izklāsta stilu un detalizācijas lī­me­ni,
  • iespēju robežās jāanalizē programmatūras izstrādes vide un paredzamās darbināšanas īpatnības, lai iezīmētu ieteicamāko dokumentēšanas veidu, stilu un paņēmienus,
  • jāņem vērā pasūtītāja izteiktās vēlmes attiecībā uz lietotāja dokumentāciju,
  • jāvienojas par izstrādes standartiem, ņemot vērā līgumā pausto apņemšanos (ja tāda ir),
  • ja dokumentācija jāraksta vairāk nekā vienā valodā, tad papildus šajā rakstā minētajiem pasākumiem jāņem vērā arī laiks tekstu sinhronizācijai, jāplāno, kad un kā to sākt un darīt (man ir pieredze ar dokumentācijas izveidošanu un uzturēšanu trijās valodās – tas bija labs izaicinājums),
  • vai un kā projekta situācija ļauj identificēt dokumentāciju, kā atškirt dokumenta laidienus, kā nodrošināt viennozīmīgu sasaisti ar dokumentēto programmatūru. Varianti ir vairāki: a) nodrošināt, ka ir pieejama tikai aktuālā dokumentācija, tādējādi garantējot aktualitāti b) ielikt dokumentācijā informāciju par aprakstītās programmas versiju. Tomēr, izvēloties pirmo, vienmēr jāpatur prātā, ka sarunā ar pasūtītāju vienmēr jābūt iespējai pārliecināties, ka abi runājat par vienu un to pašu dokumenta laidienu. Ja nav iespējams identifikāciju atkārtot katrā lappusē, der, piemēram, norunāt lappusi, kurā maziem burtiņiem to ierakstīt vai vismaz faila nosaukumā atspoguļot, sliktākajā gadījumā – dokumenta īpašībās (properties),
  • kā arī citi konkrētā projekta situācijā nepieciešamie uzdevumi.

Atkarībā no projektā pielietotas izstrādes metodikas, iedibinātajiem kvalitātes pārvaldības mehānismiem, pastāvošajiem riskiem, iepriekšējas pieredzes u.c. faktoriem projekta izstrādes laikā tiek pieņemts lēmums, kurā brīdī uzsākt dokumentācijas rakstīšanu, un šis brīdis var atšķirties no sākotnēji ieplānotā. Svarīgi atrast īsto brīdi, lai izvairītos no situācijas, kad jāpārstrādā uzrakstīts teksts (labot bieži vien izrādās grūtāk, kā to pašu uzrakstīt no nulles) un lai nenotiktu tā, ka pēdējā brīdī steidzīgi tiek rakstīta dokumentācija, ietaupot uz kvalitātes rēķina. Prakse gan rāda, ka pat pie vislabākās plānošanas dokumentētāju slodze ievērojami palielinās, tuvojoties projekta nobeigumam, tāpēc jau laikus jāparedz, lai kopumā šī noslodze izlīdzinātos un mazinātos risks, ka pēdējā brīdī steidzīgi tiek rakstīta dokumentācija, ziedojot kvalitāti. Šo risku var samazināt, apzinoties dokumentācijas izstrādes procesa svarīgumu un ņemot vērā šajā rakstā sniegtos ieteikumus, tomēr domāju, ka praksē nekad neizdosies pilnībā novērst.

Lietotāja dokumentācijas izstrādes uzsākšana

Pirms dokumentācijas izstrādes uzsākšanas, dokumentētājiem, nepieciešamības gadījumā sadarbībā ar pieaicinātiem ekspertiem, kopīgi jāvienojas par:

  • konkrētiem veicamajiem darbiem (piemēram, nodaļām dokumentā vai programmatūras funkcijām), to secību, sadalījumu, atbildīgajiem un termiņiem,
  • konsekventas un vienveidīgas terminoloģijas (pazīmes lauks, izvēles rūtiņa, …) izmantošanu, norunājot mehānismu, kā darba gaitā ieviest jaunus terminus,
  • organizācijā jau esošu iestrāžu (veidnes, tipveida satura rādītāji u.c.) izmantošanu vai pielāgošanu,
  • dokumentācijas izklāsta stilu un detalizāciju (censties ne dziļāk par 3. līmeņa virsrakstu). Ideja: varētu izgudrot un piemēros izmantot kādu personu ar interesantu vārdu, kura lietotājiem asociētos ar konkrēto programmatūru. Varbūt pasūtītājam ir jau savs tēls, piemēram, Centis Ūbele? Ieteicams pārrunāt arī nepieļaujamos piemērus (ministrs Bin Ladens? Lietotājs Harijs Poters? Pensionārs Lāčplēsis? Kā uz tādiem reaģēs lietotājs?),
  • vienoties, vai lietotāju uzrunā „Jūs”, vai lieto trešo personu, vai neitrālo: „Ja Jūs vēlaties dzēst dokumentu…”, „Ja lietotājs vēlas dzēst dokumentu”, „Ja nepieciešams dzēst dokumentu…”, „Ja jādzēš dokuments…”,
  • vienoties, vai lietot pavēles formu, vai vajadzības „Nospiediet [OK]”, „Jānospiež [OK]”,
  • vienoties, vai lietos tagadnes formu (atveras logs, atvērsies logs, tiks atvērts logs u.c.),
  • katram gadījumam pārrunāt nepieciešamību nodrošināt, lai piemēros vai aprakstos neparādās reālu personu dati, piemēram, pašu dokumentētāju adreses,
  • kur un kā iegūs korektus testa datus, vai dokumentācijā liks ilustratīvus piemērus ar skaidrojumiem, vai pareizi aizpildītus dokumentus kā piemērus,
  • testa datu un fotografējamo programmatūras logu iegūšanas vidi un līdzekļiem (piemēram, vai dokumentācijā pieļaujams fotografēt logus ar reāliem datiem, kur un kā iegūt testa datus u.c.), rīku licencēm,
  • attēlu apstrādi: vai pieļaujami papildus elementi uz attēliem, piemēram, norādes vai izcēlumi. Ja jā, tad kādā stilā? Vai dokumentētājiem ir rīks, kas nodrošina ērtu apstrādi attēliem? No prakses – ir projekti un situācijas, kurās ekrānattēli tiek fotografēti un pēc tam laboti, aizkrāsojot daļu datu vai aizstājot ar atļautām vērtībām,
  • tehniskām izstrādes lietām, piemēram, dokumentācijas izstrādes vides piedāvāto iespēju izmantošanu šķērsatsaucēm, virsrakstu atkārtošanu, ja tabula ir izvietota uz vairākām lapām, failu glabāšanas vietu u.c.,
  • dokumentu konfigurācijas pārvaldību – versionēšanu (1,2,a,b,…), melnrakstu nodalīšanu,
  • nākošo kopīgas sanākšanas (dokumentu apskates) laiku,
  • u.c. konkrētā projekta situācijā piemērotiem jautājumiem, piemēram, darba kārtību vienlaicīgai strādāšanai ar vienu dokumentu, uzrakstīto fragmentu nodošanas kārtību tālākai apstrādei utt.

Formāli šo vienošanos mēdz saukt par lietotāja dokumentācijas izstrādes uzsākšanas apskati, un dažreiz pasūtītājs vēlas saskaņot šīs apskates rezultātus.

Lietotāja dokumentācijas izstrāde

Dokumentācijas izstrādes laikā, pat tad, ja projektā pieejamas aktuālas un detalizētas prasību specifikācijas un projektējumi, nepietiek ar kopēt-ielīmēt no šiem dokumentiem, jo tie ir rakstīti citai auditorijai un citā griezumā. Dokumentētājs ņem vajadzīgo informāciju, pārveido to atbilstoši lietotāja dokumentācijas mērķauditorijai un papildus informāciju gūst:

  • darbinot un pētot programmatūru, praktiski izspēlējot aprakstāmos scenārijus un modelējot piemērus,
  • iztaujājot sistēmanalītiķus un testētājus gan par funkcionalitāti, gan par lietotājam ieteicamo rīcību problēmu un kļūdu gadījumos,
  • caurskatot izmaiņu pieprasījumus un testēšanas pierakstus,
  • iespējams, pat caurskatot programmatūras kodu (piemēram, lai atrastu kļūdu ziņojumu veidus vai precīzu kāda ziņojuma tekstu),
  • iepazīstoties ar pasūtītāja darba specifiku, normatīvajiem aktiem un veidojot saturīgus piemērus, kuri pēc būtības atbilst lietotāju reāli veicamajam darbam, un nepieciešamības gadījumā tiekoties ar pasūtītāja darbiniekiem,
  • u.c. konkrētā projekta situācijā piemērotos veidos.

Līdztekus jau minētajam par stilu, detalizācijas pakāpi un terminu vienveidību jāapzinās, ka lasītājiem – lietotājiem ir jāgūst vajadzīgā informācija un tajā pašā laikā tos nedrīkst pārslogot ar informācijas gūzmu, tāpēc papildus jau minētajam par stilu, detalizācijas pakāpi un terminu vienveidību jāņem vērā arī rakstiskās komunikācijas īpatnības, tostarp:

  • noformējuma viendabīgums, līdzvērtīga līmeņa sadaļās atspoguļota līdzvērtīga detalizācija,
  • noformējuma psiholoģiskie aspekti (piemēram, veids, kādā piesaistīt lietotāja uzmanību sevišķi svarīgai informācijai, krāsu lietošana),
  • lasīšanas ērtums (piemēram, acis nepārslogojošs attēlu un teksta izvietojums un proporcijas),
  • lietošanas ērtums (piemēram, apjomīgu dokumentu sadalīšana, kompaktā un ērti izdrukājamā formā pasniegta informācija, kas lietotājam varētu noderēt ikdienā),
  • jaunu laidienu lietošanas ērtums (piemēram, varbūt lietotājam varētu būt ērti izdrukāt tikai mainītās sadaļas un aizstāt tās savā iepriekšējā izdrukā).
Lietotāja dokumentācija

Lietotāja dokumentācija

Būtiskāko faktoru kopums

Kvalitatīvu lietotāja dokumentāciju nodrošina šādu būtiskāko faktoru kopums:

  • sakārtoti programmatūras izstrādes procesi projektā (organizācijā), piemēram, izmaiņu pārvaldība, dokumentācijas izstrādes vadlīnijas u.c.,
  • kvalificēts dokumentēšanas procesa vadītājs – pieredzējis eksperts ar skaidru vīziju par lietotāja dokumentāciju un tās mērķiem, spēju motivēt darbam dokumentētājus,
  • akurāts galvenais atbildīgais par dokumentu (iespējams apvienot ar dokumentēšanas procesa vadīšanu), kurš uzņemas dokumenta tehnisko salikšanu un rediģēšanu,
  • motivēta dokumentētāju komanda, kurā, ieteicams, vismaz puse ir ar iepriekšēju pieredzi dokumentēšanā,
  • dokumentācijas testēšana, ko veic profesionāli testētāji saskaņā ar savām darba instrukcijām, metodiskajiem materiāliem u.c. materiāliem, kas pielāgoti tieši lietotāja dokumentācijas testēšanai (par šo plānoju sagatavot atsevišķu rakstu),
  • dokumentācijas regulāras apskates, kurās piedalās gan tās izstrādātāji, gan pieaicināti citi organizācijā esošie eksperti (skats no malas),
  • dokumentācijas izstrādes vides (piemēram, Word) iespēju pielietošana (piemēram, automātiskas šķērsatsauces),
  • sadarbība ar pasūtītāju, gūstot praktiski pielietojamu darba scenāriju un piemēru idejas, kā arī rosinot pasūtītāju izteikt savas vēlmes,
  • vienošanās ar pasūtītāju par dokumentācijā iekļaujamajām organizatoriskajām lietām (piemēram, vai likt atsauces uz MK noteikumiem, vai likt ieteikumu lietotājam, pie kā griezties, lai iegūtu lietotāja vārdu un paroli, vai atstāt to citām instrukcijām – jārēķinās, ka šāda organizatoriska rakstura informācija var mainīties un programmas dokumentāciju būs grūti uzturēt).

Lietotāja dokumentācija tenderos un ikdienā

Interesanti papētīt tenderos izteiktās prasības pret lietotāja dokumentāciju (iespējams, par šo tēmu sagatavošu atsevišķu rakstu). Lielākoties pausta uzticība standartiem (sevišķi Latvijas, prasot izstrādāt atbilstoši tam) un, acīmredzot, paļaušanās uz izstrādātāja profesionalitāti un godaprātu, jo prasības reti kur tiek minētas detalizēti, parasti tādas ir tenderos, kuru izsludinātājiem ir negatīva pieredze programmatūras ieviešanā, un pie iepriekšējās sistēmas trūkumiem norādīts, ka nav pietiekami kvalitatīvi izstrādāta lietotāja dokumentācija.

Vairākos tenderos, kuros aprakstīta iepriekšējā sistēma, pie tās trūkumiem minēts, ka nav pietiekami detalizēti vai kvalitatīvi izstrādāta lietotāja instrukcija – jo lietotāja dokumentācijas kvalitāti tās saņēmējs var novērtēt tikai pēc reālas darbošanās ar programmatūru. Ja sadarbība ir veiksmīga, tad iespējams lūgt papildināt vai pārstrukturēt dokumentāciju, taču visdrošāk ir veikt preventīvos pasākumus – gan iekļaut tenderī detalizētas prasības, gan izstrādes laikā darīt zināmas savas vēlmes lietotāja dokumentācijai. Izstrādātājam vienmēr ir vieglāk strādāt, zinot spēles noteikumus, un lielāka varbūtība, ka rezultāts tiešām atbildīs gaidītajam.

Būtībā, šajā rakstā sniegtos ieteikumus un akcentus var pielietot ne tikai programmatūras lietotāja dokumentācijas izstrādē. Par anekdoti kļuvis ne viens vien citāts no pavirši tulkotām vai izstrādātām sadzīves tehnikas lietošanas instrukcijām. Pat lasot lietotāja dokumentāciju cilvēka dzīvības funkciju saglabāšanai kritiskos brīžos (kurai teorētiski vajadzētu būt pārdomātai līdz pēdējam vārdam un izstrādātai pēc vislabākās prakses) – pirmās palīdzības sniegšanas instrukciju, diemžēl, atradu ne vienu vien klasisku kļūdu, ko bieži ievēroju arī programmatūras lietotāja dokumentācijā, piemēram, aprakstīta rīcība (saindēšanās gadījumā izraisīt vemšanu), minēti izņēmumi (nedrīkst izraisīt vemšanu, ja ir saindēšanās ar skābēm, sārmiem u.c.), taču nav paskaidrots, kā rīkoties šajos izņēmuma gadījumos. Šādi iespējami pārpratumi ir jāparedz  jau dokumentācijas izstrādes laikā. Ja tas nav izdarīts, tad tie noteikti ir jāievēro un  jānovērš dokumentācijas rediģēšanas laikā.

Jāatceras, ka, ja programmatūra izstrādāta nekvalitatīvi un ir neērta darbam, tad lietotāja dokumentācijā gan ir jāsniedz ieteikumi un risinājumi (workarounds), taču pat visperfektākā dokumentācija neglābs no izgāšanās sliktu programmatūru.

Nobeigumā – daži kuriozi no rediģēšanai iesniegtām lietotāju rokasgrāmatām (pārējie atrodami šeit: https://sistemanalize.wordpress.com/2011/03/09/joki-it/):

  • aprakstot darbu ar mirušo personu reģistru, kā piemērs bija sniegts aizpildīts reģistrs ar tobrīd valdībā esošajiem ministriem,
  • “ja uzspiedīsiet uz ēkas, tad parādīsies un aktivizēsies šīs ēkas īpašnieki”,
  • “pagaidiet, kamēr logā parādīsies personas”,
  • “tiks dzēsti visi parādnieki, kuru kadastrālā vērtība pārsniedz 10 latus”,
  • “nospiežot tiks likvidēti visi lietotāji”.

Dokumentācijas izstrādei rekomendējamie standarti

LVS 66:1996 Informācijas tehnoloģija. Programmatūras lietotāja dokumentācija ir labs teorētiskais uzziņu materiāls par ieteicamo dokumentācijas struktūru un vispārīgo saturu. Maz konkrētu ieteikumu, taču to sniegšana nav standarta pienākums. Standarts ir viegli pielāgojams un izprotams, sevišķi, ja paralēli ir iespēja skatīt konkrētu dokumentācijas piemēru, kas izstrādāts pēc šī standarta, vai konsultēties ar zinātāju.

ISO/IEC 12119 Information technology – Software packages – Quality requirements and testing īsi un ļoti vispārīgi raksturo dokumentācijā iekļaujamo obligāto minimumu, lai dokumentāciju vispār varētu uzskatīt par kvalitatīvu.

IEEE/EIA J-STD-016  Standard for Information Technology. Software Life Cycle Processes. Software Development) detalizēts un ļoti apjomīgs, veidots visiem dzīves gadījumiem, un ar to iepazīties ir vērts ikvienam lietotāja dokumentācijas izstrādes vadītājam. Reālajā dzīvē šo standartu parasti pielāgo, kas praktiski izpaužas kā izvēlēta vajadzīgā prasību apakškopa dokumentācijai.

ISO/IEC 15910:2004 – ISO/IEC 12207 -dokumentēšanas procesa izvērsums. Lietotāja dokumentācijas izstrāde ir process ar dzīves ciklu, kuram ieejas dati, procesa plāna izstrāde un tajā iekļaujamās informācijas tipi, mērķauditorijas noteikšana, procesa veikšanai nepieciešamo resursu aprēķināšana, procesa laikā veicamās aktivitātes, izejas dati – rezultāti. Ļoti vispārīgi apraksta prasības noformējumam, neiedziļinoties detaļās  Pielikums ar dokumentācijas izstrādes darbietilpības novērtējumu vairākos griezumos un paņēmienos
Nosaka, ka dokumentam vismaz vienreiz jāveic lietojamības testēšana, definējot prasības, plānojot testus, apstrādājot rezultātus.

ISO/IEC FDIS 18019:2004 – Vadlīnijas liet. dok. izstrādei – lietotāju vajadzību noteikšana, iekļaujamā informācija un tās pasniegšana. Iekļauti pārbaudes punkti procesa, lietojamības testu un satura plānošanai, teksta noformējumam, ir kontroljautājumu saraksti procesa plānošanai, auditorijas analīzei, noformējumam, testēšanas etapam (izceļot apskates, lietojamības testus, sistēmas testus), saturam, navigācijai, noformējumam. Ņemot par pamatu standartā esošos kontroljautājumu sarakstus un papildinot tos, var sagatavot labu pamatu dokumentācijas testēšanai

IEEE Std 1063-2001 (atkārtoti apstiprināts 2007) – aprakstīts lietotāja dokumentācijas struktūra un saturs, komponentes (titullapa, satura rādītājs, attēlu saraksts, alfabētiskais rādītājs u.c.) un ieteicamās satura vienības tajos. Pozitīvi, ka daudzas rekomendācijas ir aprakstītas izmērāmā veidā, piemēram, ieteicami ne vairāk kā 4 līmeņu virsraksti, elektroniski vajadzīgo informāciju vēlams atrast ar ne vairāk kā 3 klikšķiem, satura rādītāju veido, ja dokumentam ir vairāk kā 8 lapas, attēlus numurē, ja to ir vairāk kā 5 u.c. (uz šī standarta iepriekšējās versijas bāzes ir izstrādāts LVS66-96)

Raksts bāzēts uz manas oriģinālās publikācijas žurnālā “Datorpasaule” 2003.gadā

Programmatūras dokumentēšana


Programmatūras dokumentēšana

Programmatūras izstrādes projekta rezultātu „trīs vaļi” ir:

  • dažādi izstrādes laikā tapuši dokumenti,
  • programmatūras kods (kas patiesībā ir pilnīgākā dokumentācija, kāda vien programmatūrai var būt),
  • pati darbināmā programmatūra (izpildkods).

Katrā izstrādes procesā kā tiešs vai netiešs rezultāts rodas dokuments vai vismaz pieraksts. Dokumentus var iedalīt divās grupās pēc to piederības:

  • iekšējie dokumenti, par kuriem pasūtītājs parasti zina, ka tādi mēdz būt, tomēr konkrētā projektā neiedziļinās to saturā un esamībā (ja pasūtītājs vēlas skatīt vai iegūt savā īpašumā šos dokumentus, tad par to jāvienojas ar izstrādātāju),
  • nododamie dokumenti, kuru izstrādes fakts ir fiksēts līgumā un kurš ir viens no taustāmajiem programmatūras izstrādes nodevumiem ar noteiktām kvalitātes prasībām.

Iedalot dokumentus pēc to satura, var iegūt, piemēram, šādas grupas:

  • procesu izpildi aprakstošā dokumentācija (piemēram, akcepttestēšanas procedūra vai konfigurācijas pārvaldības vadlīnijas),
  • starprezultātu dokumentācija kādā procesā (piemēram, programmatūras pirmsnodošanas testēšanas pārskats),
  • gala produktu aprakstošā dokumentācija (piemēram, programmatūras projektējuma apraksts),
  • gala produkta sastāvdaļa (lietotāja dokumentācija).

 Programmatūras izstrādes laikā radītajiem dokumentiem visbiežāk tiek lietotas šādas galvenās prasības to kvalitātei:

  1. atbilstība standartam,
  2. atbilstība dokumenta izstrādes laikā abpusēji saskaņotām un rakstiski noformulētām pasūtītāja vēlmēm un norunām.

Kā papildus nodrošinājums var būt prasība izstrādātājam procesa organizēšanā nodrošināt atbilstību kādam procesu reglamentējošajam standartam (šādā gadījumā noteikti jāvienojas par veidu, kā tieši izstrādātājs lai pierāda šo atbilstību). Piemēram, lietotāja dokumentācijas gala rezultātam – dokumentam iespējams prasīt atbilstību standartam 1063:2001 IEEE Standard for Software User Documentation, bet pašam lietotāja dokumentācijas izstrādes procesam – atbilstību standartam 15910:1999 Information Technology – Software user documentation process. Šajā standartā cita starpā ir aprakstīta darbietilpības aprēķināšana dokumentācijas izstrādei, kuru, kombinējot ar praksē uzkrātajām zināšanām un statistiku konkrētā organizācijā, var izmantot arī citu dokumentu izstrādes darbietilpības prognozēšanai.

Īsumā par dokumentēšanu

Iespējams, ka ir dzirdēti jēdziens – programmatūras dzīves cikls, kas – vienkāršojot -raksturo, kādā attīstības stadijā atrodas programmatūra (izstrādē, testēšanā, ekspluatācijā) u.c. Līdzīgi dzīves cikla jēdzienu pielieto arī citur, runājot par, piemēram, problēmziņojuma dzīves ciklu vai dokumenta dzīves ciklu. Patiesībā tas ir diezgan vienkārši – jāvienojas par dokumenta iespējamajiem statusiem, piemēram, „melnraksts”, „tīrraksts”, „spēkā esošs”, „arhivēts”, un dokumentam vienmēr jābūt atbilstoši piešķirtam kādam no šiem statusiem.

Grūtākais parasti ir izveidot šo statusu sarakstu. Salīdzinoši vieglāk ir vienoties par kārtību, kādā šie statusi tiks piešķirti, un vienoties par veidu, kā tiks uzturēta informācija par dokumentiem un to statusiem. Praksē to var organizēt gan ar dārgiem konfigurācijas pārvaldības rīkiem, gan ar organizatoriskām norunām un pieejas tiesību pārvaldību, izmantojot vispārpieejamus un vienkāršus rīkus. Manā darba pieredzē ir veiksmīgi piemēri arī ar dokumentu glabāšanu direktorijās ar norunātu lietošanu kārtību.

Par svarīgāko līdzekli dokumenta kvalitātes nodrošināšanai var uzskatīt dokumenta apskates, kuru laikā parasti izmanto kontroljautājumu sarakstus un dokumentam izvirzīto prasību sarakstu (ja tas nav iekļauts kontroljautājumu sarakstā). Piemēram, programmatūras prasību specifikācijas apskates laikā apskates dalībnieki pārbauda apskatāmā dokumenta atbilstību prasību specifikācijas kontroljautājumu sarakstam, piemēram, “vai specifikācijā visām prasībām ir norādīti ieejas dati? Jā/nē/nav aktuāli” u.tml. Balstoties uz iegūtajiem rezultātiem, apskates dalībnieki pieņem slēdzienu, vai dokuments ir gatavs nodošanai, vai ir atdodams izstrādātājam pilnveidošanai.

Nododot jaunu dokumenta versiju, svarīgi lasītājam nodrošināt iespēju saprast, kas saturā ir mainījies salīdzinājumā ar iepriekšējo versiju. To var nodrošināt vairākos veidos, piemēram, pievienot lapu ar izmaiņu aprakstu attiecībā pret iepriekšējo versiju, skatīt izmaiņas ar izstrādes vides līdzekļiem, piemēram, Track changes vai Compare u.c. – svarīgi savā starpā vienoties par šo veidu. Mūsdienīgas dokumentu izstrādes vides piedāvā izvēles iespēju no vienkāršas rakstāmmašīnas līmeņa programmatūras līdz jaudīgai publicēšanas sistēmai, no kuras ar pāris peles klikšķiem iespējams iegūt PDF, DHTML u.c. formātu dokumentus atkarībā no projekta vajadzībām. Protams, ir konkrēti apsvērumi vienas vai otras vides (Microsoft Word, Adobe FrameMaker u.c.) izvēlei, kuri ir jāskata kontekstā ar pasūtītāja un izstrādātāja vajadzībām un iespējām. Viens ieteikums gan ir pavisam drošs – dokumenta satura pirmavots jāuztur vienā un tikai vienā vidē. Es reiz pārliecināju projekta vadītāju nosūtīt dokumentētājus uz FrameMaker apmācībām, un process būtiski uzlabojās, jo pirms tam dokumentētāji sūtīja Word dokumentus vienīgajam FrameMaker zinātājam, lai viņš pārveido uz to.

Kopumā pieredze programmatūras izstrādē ļauj secināt, ka dokumentu sagatavošana un to kvalitātes novērtēšana joprojām ir aktuāla problēma visās nozarēs, kuras saskaras ar programmatūras iegādi. Kvalitātes prasības bieži vien var interpretēt dažādi un gala rezultāts ir atkarīgs gan no izstrādātāju un novērtētāju profesionalitātes, gan pareizi organizētas savstarpējās sadarbības.

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

%d bloggers like this: