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ā

Advertisements

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: