Archive for the ‘Programmatūras izstrāde’ Category

Noliktavas strādniekiem – pienu par kaitīgu darbu


Manuprāt, analītiķim līdz darbam pie datu noliktavas ir jāizaug, jānobriest, jānogatavinās OLTP druvā. Datu noliktava – tas ir nopietni. Tie ir lēmumi, tās ir ekspektācijas (mārketinga saukļus gan jau kādu zināt), tas ir izdarīt varen sarežģītu darbu, lai cik gudru grāmatu un visādu blogu :) būtu sarakstīts ar padomiem. Tāpat noliktavas strādnieka dienišķais būt vai nebūt: labot datus noliktavā vai gulties uz ambrazūras cīņā par labākiem avotiem?

 

Programmētāji zina – lai atrastu bagu, ir jāmāk domāt kā bags domā. Tā nu es te pārfrāzējot saku, ka DN analītiķiem pirms DN jāapēd puds sāls avota sistēmās. Jāsaprot, ko, kā un kāpēc dara avotu cilvēki, kādi grābekļi, kāds viņu domu gājiens. Ko tur liegties, pašai kā bumerangs ir situsi OLTP sistēmu izstrādātāju nepadomāšana tālāk par savu pagalmu. Neizdarāmu lietu jau parasti nav. Tikai vairāk laiku un izdomu prasa.

 

Jo vairāk runās, jo lielākā iespēja, ka noliktavas strādniekus sadzirdēs. Pielikšu atrunu, ka, protams, ir uzņēmumi, kur par šo jau tagad tiek nopietni domāts. Šeit rakstītais kompilēts no dažādu analītiķu pieredzes, nozares mītiem un leģendām. Visi piemēri anonimizēti.

 

Ideālajā pasaulē DN vs OLTP problēma ir identificēta un OLTP cilvēki ar DN cilvēkiem sadodas rokās un smaidīdami dodas uz kopīgu mērķi – vēl ideālāku pasauli. Visi zina, kādus datus un kā ņem uz DN, nosacījumi abās pusēs sakrīt, allaž savlaicīgi vienojas par izmaiņām, avota datu labošanas skripti vai nu nav nepieciešami, vai nu sakopj aiz sevis astes priekš DN, kā arī ir daudz jauku testa datu pēc pirmā pieprasījuma vai pat bez prasīšanas. Ļoti ceru, ka akurāt tā, kā pie jums.

 

Ne-ideālā pasaulē datu noliktavu cilvēkiem tik gludi neiet. Kāpēc eksistē arī neideāla paralēlā pasaule? Tāpēc, ka gadās:

 

*) avotiem un DN ir dažādi izstrādātāji (ar visām izrietošām birokrātijām),

 

*) nav cilvēka, kurš ir  ar vienu kāju avotā, ar otru noliktavā (ja būšana ir formāla, jēgas maz, bet parasti beidzas ar to, ka šo cilvēku viena no pusēm sāk arvien vairāk nodarbināt, līdz paņem pie sevis),

 

*) sistēmu izstrādei dažādi budžeti (un tad, kā saprotat, pingpongs),

 

*) avotu cilvēki ir līdz ausīm savos darbos (un, ja godīgi, nealkst rakņāties pa veciem sqliem, jo VIŅIEM viss strādā),

 

*) noliktava ieviesta ķeksīša pēc. Gala lietotāji tāpat turpina savus pirmsplūdu ekseļus, bet sākotnējais izstrādātājs piesedzās ar papīriem,

 

*) DN cilvēki izlutina lietotājus ar to, ka gan jau tiks galā, ko nu taisīt problēmu, kopš pasaulē ir izgudrota update komanda.

 

Daži gadījumi, kuros DN analītiķiem sirms mats klāt:

 

1) ja avots kādā brīdī nomaina lauka nozīmi – senāk rekins.nosutits “jā” bija ‘0’, bet kopš eiro ieviešanas “jā” kļuvis “1”. Dažreiz pat kurioza iemesla dēļ – jaunajam avota analītiķim sajuka, bet tad, kad atklāja, ka jau uztaisīts, tā arī palika.

 

2) ja lauka satura nozīme atšķiras dažādas situācijās. Ja līzinga gadījumā laukā “klients.adrese” ir pircēja adrese, bet kredīta gadījumā – galvotāja adrese. Papildus kādā specifiskā gadījumā, piemēram, ja nokavēti vairāk 3 maksājumi, tajā glabājas adrese, uz kuru sūtīts pirmais atgādinājums, bet ja nokavēti vairāk nekā 3, tad tā, uz kuru sūtīts jaunākais atgādinājums. Avota sistēmā cilvēki saliek ifus, notestē, kaut kādu daļu ieraksta izmaiņu projektējumā (kurš līdz ar citiem 376 maziem dokumentiņiem kaut kur glabājas), kaut ko koda komentāros, nodod un laimīgi aizmirst, avota formās adreses smuki salec pa laukiem. Pēc kāda laika datu noliktavu cilvēki mēģina saprast loģiku.

 

Žanra klasika ir avota sistēmu projektējumos šajā vietā frāze “tiks precizēts vēlāk” vai komentārs “Inokentijs ierakstīs”. Spoiler alert: Inokentijs tālēs zilajās.

 

DN tad rodas kaut kas līdzīgs šiem:

A) paņem uz DN kā “adrese” un ieraksta aprakstā a la “Kredīta gadījumā galvotāja adrese, citos gadījumos tas, kas aprakstīts avota dokumentācijā”. Lauks pārņemts, sirdsapziņa tīra, lai nu lietotāji paši tiek galā.

 

B) tiem, kuriem var atšķirt, izveido DN objektus a la “Līzinga ņēmēja adrese”, “Galvotāja adrese”, “Pārējās adreses”, un tad vai nu transformācijā vai pēcapstrādē, vai pārskatos sadala ar case ifiem.

 

C) DN cilvēki mistiskā veidā panāk, ka avots sakārto datus un ievieš pie sevis dažādus laukus. Vai vismaz iedod precīzus where nosacījumus.

 

D) variācija – DN cilvēki pēc labākās sirdsapziņas uztaisa. Tikmēr avota sistēmā atnāk jauns, strādīgs analītiķis un piekopj. Vienā brīdī kādam lietotājam rodas aizdomas, kāpēc kredītņēmēji tik bieži dzīvo turpat, kur galvotāji, un tad futbola sezonu var uzskatīt par atklātu.

 

3) izmaiņu atšķiršanas mehānisms. Jāpiekrīt, ka avota sistēmai ne vienmēr vajadzīgs. Uztaisa update vai fiziski padzēš. Bet DN pēc tam raķešzinātne jātaisa. Man personīgi tagad simpatizē, ja katrā avota tabulā katrai rindai ir pieejami ierakstīšanas un pēdējās koriģēšanas datumi, savukārt dzēstie ir atzīmēti kā loģiski dzēsti vai vismaz to atslēgas kaut kur uzskaitītas kā fiziski dzēstas.

 

4) avotu sistēmu datubāzes pusdokumentētas, pusaizmirstas īpatnības. Ir jauki, ja ir smuki, godīgi lauciņi un tabulas a la “darijums” ar klasificētu pazīmi, kredīts vai līzings. Vai atsevišķas tabulas “kredits”, “lizings”. Nav tik jauki, kad ir tabula “na_kustiba” ar laukiem paz1, paz2, paz3, paz4. Lien nu ārā no ādas, lai uzzinātu, ka kredīts ir tad, ja paz1=Z un paz3=9, bet līzings ja paz2=Y, paz3=4Q un nav aizpildīts paz4. Nu, ideju, cerams, sapratāt. Šis raksturīgs vecām sistēmām. Diemžēl gadās arī jaunākām, kuru izstrādātāji sapinušies meistarībā.

 

Šeit tomēr lūdzu paturēt prātā: mēs visi esam tikai cilvēki. Zinu reālu gadījumu, kur jaunpieņemtai augstas klases PLSQL programmētājai projekta cilvēki palūdza rakstīt vienkāršāku kodu. Jo viņa pabeigs darbu un aizies uz citu projektu, bet palicējiem būs jāsadzīvo ar tiem dinamiskajiem masīviem un citām grūti lasāmām konstrukcijām. Šī atziņa mani izmācīja, piemēram, likt nenorādīta datuma lookupam aizbāzni nevis … else ‘25000101’, bet kaut ko no sērijas … else to_char(to_date(’01-JAN-2500′,’DD-MON-YYYY),’YYYYMMDD’), jo otrajā gadījumā manuprāt ātrāk skaidrs, ka tas ir no aizbāžņa datuma izveidots identifikators.

 

Daži no jautājumiem, kurus labā pasaulē risina arhitekti un kvalitātes pārvaldnieki, bet, ja tas tā nav, tad DN analītiķiem galvas kūp:

 

1) Avota sistēmā dati, teiksim statusi (iesniegts, apstiprināts…) pēc idiem pielasās no dažādiem klasifikatoriem atkarībā no dokumenta tipa (ar nebūtiskām (?) niansēm – piemēram, kādam “apstiprināts” varētu saukties “pieņemts”. Bet var būt papildnianses, ka citam savukārt “apstiprināts” nozīmē pēc biznesa to pašu, ko vēl citam “iesniegts”)) – vai DN salikt vienā statusu dimensijas tabulā ar papildatribūtiem, vai pārņemt kā katram savu?

 

2) Ko darīt, ja avotā ir kļūdains risinājums, kurš netraucē avota sistēmai (lietotāji pieraduši vai nelieto to lauku)? Vai ja avota funkcionalitāte atšķiras no avota projektējuma? Kas tas ir? Bugs? Fīča? Todo? (šajā vietā atgādināšu, ka Inokentijs ir prom, bet Maija Saprātiņa, kurai to gabalu piešķīra, ir noslogota ar cita bloka iešanu produkcijā).

 

3) Ko darīt, ja, taisot ko citu, atrod kļūdu sen jau strādājošā DN gabalā? Teiksim, rakņājoties pa ETL, pamana, ka, pārņemot no rēķina preču aprakstus, sasien preces numuru ar apraksta numuru, rezultātā pirmajai precei ir piesaistīti visu rēķina preču pirmie apraksti, otrajai precei – visu preču otrie u.t.t. Kokteilis. Bet vai celt paniku, ja neviens nav sūdzējies? Ej nu zini, cik vietās un pārskatos šis jau iegājis un kā tur nokopts. Kurš metīs ar akmeni, ja DN analītiķis noklusēs, sak, pašam vēl nāksies labot, bet pietiek savā darāmā. Variācija – to taisīja Pēcis, negribas kašķēties. Apakšvariācija: par to atrašanu testētājiem algu maksā, lai viņi ziņo. Apakšapakšvariācija: negribas traucēt, jo varbūt kaut kādu nezināmu iemeslu dēļ tāda bija prasība.

 

4) Kurā vietā taisīt NVL, TRIM u.tml.? Avota datu atlases selektā? Transformācijas gabalā? Pēcapstrādē? Pirms iekļaušanas pārskatā? Vai tos likt visiem laukiem kā standartapstrādi pat tad, ja it kā nevajag?

 

5) Vai dublēt avota biznesa constraintus, teiksim, ka ievadē atļauti ‘1’, ‘2’, ‘3’, vai ņemt neanalizējot. Ir projekti, kuros taisa, lai transformācija izkrīt, ja ir ārpus diapazona. Ir, kur tādus samet speciālā tabulā izskatīšanai. Ir, kur pārņem un neliekas ne zinis. Ir tādi, kur notiek datu kvalitātes kontroles, piemēram, reizi nedēļā laiž kontrolselektu, vai DN nav parādījušies dati ārpus ‘1’, ‘2’, ‘3’. Bet – šādi kontrolselekti ir jāizdomā, jāievieš, jāuztur (!!!!!!!). Un jāzina, kā rīkoties, ja atradīsies ieraksti ar citām vērtībām. Kā saka viens mans draugs, pieredzējis analītiķis, – “nevajag meklēt kļūdu, ja nav zināms, ko ar to iesākt”.

 

Kā ietaupīt uz sirmo matu krāsošanu?

Datu noliktavu darba sludinājumos goda vietā ir KOMUNIKABILITĀTE un analītiskās prasmes. Pamatoti. Lai gan ceru, ka pārskatāmā nākotnē arvien vairāk uzņēmumos tiks šīs lietas sakārtotas, lai DN cilvēku komunikabilitātei (lasiet: ja pats mācēs sarunāt, tad (un tikai tad) dabūs korektus avota datus) tomēr nebūtu izšķirošā nozīme, bet avota sistēmu cilvēkiem informācijas sniegšana priekš DN projekta cilvēkiem būs parasts, plānots un kontrolēts darba uzdevums.

 

Tur, kur vēl ir ceļā uz to, manuprāt DN cilvēkiem ir vērts pārzināt,  saprast avota sistēmas datu struktūras un funkcionalitāti. Jo realitāte mēdz būt tāda, ka dokumentācija vairāk nebūs, nekā būs, izstrādātājiem nebūs ne laika, ne vēlēšanās iedziļināties, savukārt iespēja tikt pie pilnīgākās dokumentācijas pasaulē – avota IS izejas koda ir 1) reti kad iespējams luksuss, 2) ne jau vienmēr to kodu DN cilvēks prot brīvi lasīt.

 

Mana pieeja – ja iespējams, atrast veidu, kā padarbināt avota sistēmu, redzēt un pastrādāt, kā dati rodas, kā notiek viss process. Piemēram, ja uz datu noliktavu pārņemami izrakstīto rēķinu dati, tad kā tie rodas, kāds ir to dzīves cikls. Pie reizes jēdzieni kļūs saprotamāki. Ideāli, ja ir pieeja visai dokumentācijai, t.sk. vēsturiskajai. Lasot, kā laikā gaitā sistēmas evolucionējušas, var labāk saprast fonu, problēmas, vājās vietas. Ja ir iespēja ar SQL pie avota bāzes tikt – ņamma!

 

Papildu tai fantastiskajai brīvības sajūtai (kura DN cilvēkam ir, ja māk un tiek klāt rakstīt visādus biznesa selektus avota IS) būs arī priekšstats par DN testēšanu, jo viens no veidiem ir, ka lietotāji atver vienu dokumentu vai sarakstu abās sistēmās un salīdzina. Man ir pieredze, kā lietotājiem patika dokumenti, kurā detaļās, ar attēliem un bultiņām aprakstīts, kuri lauciņi no avota sistēmas formām un sarakstiem atbilst kuriem datu noliktavā. Piemēram, nosaukumi atšķiras (objektīvu iemeslu dēļ, jo var gadīties, ka sen jau jaunas veidlapas, bet vecajā sistēmā nemaina un visi pieraduši, ka laukā “adrese” ir personas kods), taču jaunajos projektos, t.sk. DN lieto jaunos nosaukumus.

 

Nobeigumā vispārināts ieteikums: pirms nosodīt (ja vispār ko tādu darīt), pacensties izprast domu gājienu. Ir bijis, ka sarunu sāc ar “kurš idiots ko tādu izdomāja”, bet pabeidz jau ar “kāds interesants un attapīgs risinājums”! :)

 

Advertisements

PL SQL developer sertifikācijas atmiņu stāsts


Programmēšanas eksāmenos velns ir detaļās (vs lomu sertifikācijās velns ir jēdzienos). Lai iegūtu Oracle PL/SQL Developer Certified Associate sertifikātu, nokārtoju divus eksāmenus –

  • Oracle Database: SQL Fundamentals I
  • Program with PL/SQL.

Abi ir darba ikdienas sastāvdaļa, jo lielos valsts mēroga projektos sistēmanalītiķis nereti ir cilvēks – orķestris, kam tabulu, vaicājumu, apdeitu, skatu, procedūru un trigeru diriģēšana ir ikdiena – Informix, Oracle, MS SQL, Sybase… It kā jau SQL arī Āfrikā ir SQL, tomēr apaudzēts ar fīčām un nav viegli tā uzreiz atcerēties, kurā DBVS varchar2 noteikti jānorāda minimālais garums, kurā pēc noklusēšanas ir 1 un kurā tāda varchar2 vispār nav.

Tātad, lai dokumentāli apliecinātu zināšanas, raitā tempā jādemonstrē kompilatora prasme. ~1.5 min uz jautājumu – jāizlasa, jāsaprot, parasti satur 4 atbilžu variantus, kas katra ir citāda funkciju virkne. Līdz ar to dot slēdzienu par vienu virkni ir ~20 sekundes laika. Jo ātrāk mācēsi noskanēt virkni uz tipiskām kļūdu ķeramvietām, jo vairāk laika paliks pētīt aizdomīgi pareizās:

  • Vai strādās select lower(replace(trim(‘son’ from cust_last_name),’An’,’O’)) from customers?
  • Kas notiek, kad izpilda select initcap(cust_first_name||’’||upper(substr(cust_city,-length(cust_city),2))) from customers?
  • Vai to_number(to_number(prod_price,’$99,999.99’)*.25,’$99,999.00’) atgriezīs $6,509.75?
  • Vai select lpad(substr(cust_name,instr.(cust_name,’’)),length(cust_name)-instr(cust_name,’’),’*’) from customers where instr.(cust_name,’’,-1,2)<>0 atlasīs tikai tādus klientus, kuriem ir 3 vārdi?
  • Vai no sysdate var atņemt pī?

Un tā tālāk. Nācās atsvaidzināt teoriju. Iesaku Ginta Plivnas blogu – izcili mācību materiāli!!!, lasīju, uzslēdzu smadzenes uz mazkompilatora režīmu (nost ar zinātniskās bakstīšanas metodi “hmm, nez, šitāds kompilēsies?” un “tad jau piečibinās, ja šitas neatgriež”), un izvirzīju mērķi uzreiz uzrakstīt pareizi, zīmēju Venna diagrammas uz papīra.

Tehniskie izaicinājumi

Ja lieta ir gadiem lietota, tad lielos tramvajos jau aiziešana līdz eksāmena telpai ir 3/4 no uzvaras. Tomēr izgulēties uz lauriem eksāmenos nevar:

  • Pieraksta izvirtības uz LV neierastiem formātiem – sākot ar tiem $1,234.67, turpinot October 25th DD-MON-RR un visbeidzot AM un PM. Nācās mācīties tos $99G99D00, $9,999V99, fxDay, fmDdspth…
  • Ne visas funkcijas no eksāmena tvēruma ikdienā lietoju, tāpēc mācījos (kā, piemēram, coalesce), ko dara, argumentu skaits, obligātie, defaultie, kādi
  • Argumentu vērtības un uzvedība. Piemēram, ja instr norāda negatīvu virknes garumu, tad izkritīs ar kļūdu, nevis uzskatīs par null, 0 vai 1. Atceroties šo, bija viegli ātri izslēgt pa kādam atbilžu variantam
  • Funkciju virknes – vai, kā eksāmenā tādas mīl… nvl2(coalesce(decode(substr(instr(length(…. un variācijas, piemēram, – vai var joinot uz A = length(nvl(substr(coalesce(B,instr(A,1,2)),B),’null’))? uh, kādā tempā  eksāmenā nācās galvā šitos kompilēt :)
  • Tipu konversijas, kur ir, kādas un kur nav pieļaujamas – decode, nvl, nvl2, kā arī ar tiem (to_number(to_date(to_char(… – ārpus eksāmena ar tiem palīdz F1 un gūgle
  • Kas notiek ar NULLiem dažādās funkcijās (paldies, Gint!), vai var taisīt substr no null un vai nullif (1,null) ir tāds pats, kā nullif(null,1)? Ja concat pieliek null, vai viss rezultāts kļūst null?
  • Aliasi kolonnām, joiniem, groupiem, orderiem un havingiem – kur var lietot, kur nevar, kur vajag, kur vienalga
  • Ķer uz līdzīgām funkcijām – klasika ir months_between, days_between, years_between
  • Daudz JOINu ar visa veida pierakstiem (+), OUTER, ķer uz USING un ON atšķirībām, uz aliasu izmantošanas niansēm

Mācību procesa izaicinājumi

  • Internetā atrodami eksāmena jautājumiem līdzīgi piemēri ar nepareizām atbildēm, tāpēc vai nu jāpārbauda visas atbildes, vai svarīgi vismaz čuja līmenī mācēt nojaust, ka tā varētu nebūt pareiza. Es gandrīz visus piemēra jautājumus izspēlēju savā rotaļlaukumā – pētīju gan pareizo, gan nepareizos
  • Sagūglētiem piemēriem nav atbilžu skaidrojuma. Pateikts, ka pareizā ir “B”, bet kāpēc? Variācija: rakstīts, ka pareizas ir vairākas (A,C,D…), lai gan eksāmenā pareizā var būt tikai viena. Nu tad jāsaprot, kur āķis. Forumos var atrast – lūdzu, paskaidrojiet, kāpēc… Bet ir daudz atbilžu no sērijas “kurš tad ir tāds idiots, ka neredz, ka pareizais protams ir B”
  • Drilltests vietām ir pretrunā gan ar mācību materiāliem, gan praksi. Jau minētā varchar2 gadījumā – drillā pareizā atbilde skaitījās, ka tipa definīcijā var nenorādīt garumu, kamēr materiālos un praktiskajā Oracle krita ar kļūdu, ja nenorāda varchar2 garumu
  • Nebija pieejama precīzi tāda vide, par kādu ir eksaminācija. Tajā, kuru es lietoju, piemēram, varēja kolonnu secību alterēt (līdz ar to prasti jāiegaumē, ka eksāmenā uz “vai var esošai tabulai nomainīt kolonnu secību?”, jāatbild “nē”)
  • Drilltests, kuru dod BDA, ir vieglāks nekā reālais eksāmens. Par to parunāju arī ar BDA cilvēkiem, bet viņi jau neko ietekmēt nevar, tāds tas ir un alles. Tāpēc brīdinu – uz drillu vien nepaļaujieties

Sākumā gāja grūti ar kompilēšanu galvā – nepierasti tomēr. Centība rezultējās ar 91% (pietiktu ar 60% – slieksnis pazems, jo eksāmens IR ķēpīgs).

Jautājums uz ribas – lēns selekts, ko nu?


Ir šāda datu bāze (pieraksts nosacītā sintaksē):

Abonents (AbonentsNr int, Vards varchar(20), Uzvards varchar(20)) primary key (AbonentsNr);
Izdevums (IzdevumsNr int, Nosaukums varvhar(255), Tematika varchar(50)) primary key (IzdevumsNr);
Abonements (AbonementsNr int, AbonentsNr int, IzdevumsNr int, DatumsNo date, DatumsLidz date) primary key (AbonementsNr), foreign key (IzdevumsNr) references Izdevums (IzdevumsNr), foreign key (AbonentsNr) references Abonents (AbonentsNr)

Abonents 100 000 ierakstu, Izdevums 100 ierakstu, Abonements 500 000 ierakstu.

Sistēma izpilda SQL pieprasījumu:

SELECT * FROM Abonents WHERE AbonentsNr in (SELECT AbonentsNr From Abonements, Izdevums WHERE Abonements.IzdevumsNr = Izdevums.IzdevumsNr AND Izdevums.Tematika=”Lauksaimniecība”)

Pieprasījums izpildās lēni. Ko nu?

P.S. šis raksts nav tāpēc, ka personīgi man būtu problēmas atrisināt šāda veida uzdevumus. Vienkārši – interesē, kādus risinājumus komentāros piedāvās lasītāji.

Un šeit ir manas solītās pārdomas (pievienotas 13.01.2012) – kāds būtu mans domu gājiens.

1) indeksi (sk. Jāņa komentāru zemāk). Iemesls, kāpēc kā pirmo lieku indeksus, nevis acīmredzami nepieciešamo selekta optimizēšanu, ir šāds: lai uztaisītu vienkāršu indeksu, nevajag ne daudz prāta, ne daudz laika, tāpēc šis ir risinājums – aizbāznis, kurš var atvieglot dzīvi ĀTRI.

2) selekta optimizēšana. Daži no komentāros minētajiem variantiem (Gatis, Kaspars, Jānis) ir tīri ok.

select distinct a.*
from Izdevums i
inner join Abonements ab on ab.IzdevumsNr = i.IzdevumsNr
inner join Abonents a on a.AbonentsNr = ab.AbonentsNr
where Izdevums.Tematika = ”Lauksaimniecība”

Un ātri izdarāmais:

… WHERE AbonentsNr in (SELECT AbonentsNr From … )” vietā rakstīt WHERE EXISTS (SELECT … ). Jo ar EXISTS tiek meklēts pirmais ieraksts, kas atbilst kritērijam, kamēr ar AbonentsNr in … vispirms ir jāatlasa visi ieraksti, kas atbilst tam.

Arī šis Jāņa man patika:

Uztaisi klasifikatoru “Tematika”, un Izdevums.Tematika aizvieto ar Izdevums.TematikaNr, kuru taisi par foreign.key. Rezultātā nemeklē pēc teksta ”Lauksaimniecība”, bet pēc iepriekš atlasīta Tematika.Nr.

Un Jāņa doma par materializēto skatu.

2 ar pusi) tabulas iespējamā pārslodze – varbūt tajā ir neaktuāli dati, kurus vienreiz vajag aizarhivēt prom, un varbūt vajag padomāt par informācijas dalīšanu pa vairākām tabulām, piemēram, līdzko pienācis DatumsLidz, tā ieraksts ar kāda procesa palīdzību tiek automātiski pārnests uz vēsturisko datu tabulu.

2 ar trim ceturtdaļām): pārliecināt klientu, ka viņam patiesībā šāda vaicājuma rezultātu nemaz nevajag :-) :-) :-) (reveranss Gintam)

3) servera jauda – atmiņa, ātrums, kāds ir, ko var uzlabot?

3 ar pusi) pārbaudīt, kāds ir datu pārsūtīšanas ātrums savienojumā + datu attēlošanas uz ekrāna ātrums. Varbūt pats selekts izpildās ātri, taču problēma ir tur, ka tehnika rada sajūtu, ka tas izpildās lēni?

3 ar trim ceturtdaļām) izvietot tabulas uz dažādiem diskiem, tādējādi paātrinot fizisko nolasīšanu. Jā, šāds risinājums vairāk ir apsverams lielākiem datu apjomiem, taču kā variantu pieminu.

 4) datubāzes iespējamā pārslodze – izvērtēt iespēju samazināt datu apjomu vai pieprasījumu apjomu citās tabulās.

4 ar pusi) Ja esošā DBVS, par spīti veiktajiem pasākumiem ir par vāju, domāt par iespēju apstrādāt datus ar jaudīgāku DBVS.

Par iesūtītajiem komentāriem – sirsnīgs paldies visiem, kuri atsaucāties. Godīgi – mani sajūsmināja doma, ka par tabulas primāro atslēgu miera vējos tiek pieļauta iespēja, ka tā varētu būt telefona numurs :-). Un arī otrādi – ka lauku AbonentsNr int primarykey – var izlasīt kā telefona numuru ne brīdi nenošauboties :-) Mācība priekš manis: citreiz piemēros saukt par Id, nevis Nr. Izlasīju un pasmaidīju, ka dažreiz sistēmanalītiķis не читатель, sistēmanalītiķis писатель. Viens otrs komentārs atgādināja pasaki man savu problēmu  un es pateikšu, kāpēc tā nav atrisināma.

Lielākā daļa komentāru bija par paša selekta optimizēšanu vien, nepiesaucot iespējamos ārējos apstākļus. Ja šis būtu eksāmens, es teiktu – draugi, izkāpsim ārpus kastītes! Bet šis nebija eksāmens. Ceru, ka arī jums bija interesanti. Oficiālāku literatūru par dažādām optimizēšanām gūglējiet paši – papilnam.

Ī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.

Kā sadzīvot ar programmētājiem?


Iedvesmu smēlos 28.09.2011 Analītiķu vakariņās, kur cunftes māsas un brāļi dalījās pieredzē.

Dažādi avoti dažādi uzskata, vai sistēmanalītiķis izaug no programmētāja, vai programmētājs no sistēmanalītiķa. Nepiekrītu ne vienam, ne otram, jo tas asociējas, it kā viens no šiem būtu nākamais attīstības līmenis otram. Ja nu tomēr kāds ļoti grib kastas, speciāli viņam mēģināšu šādu līdzību: reiz lasīju medicīnas raksta komentāros: ārsts bez medmāsas neiztiks, bet laba medmāsa iztiks bez ārsta. Tā sistēmanalītiķis bez programmētāja neiztiks, bet labs programmētājs bez sistēmanalītiķa iztiks.

Liriska atkāpe: klausoties vienu no runātājiem, sapratu, ka, lai gan kritikas objekts bija specifikācija, tomēr nepārprotami tika kritizēts analītiķis kā sugasvārds, viss darba process ar viņu – acīmredzot kaut kas neiet tik gludi kā gribētos. Nenocietos un pajautāju – kura būtu  programmētāja izvēle no divām galējībām “slikts dokuments + analītiķis, kurš spēj atbildēt uz jautājumiem” vs “labs dokuments + analītiķis, kurš nespēj to komentēt”? Pēc īsa pārdomu brīža (kā man šķita, īstermiņa kārdinājums – ja patiešām (!) būtu labs dokuments, da nu to analītiķi :-), visu taču bez viņa varētu uztaisīt – pret darbu ilgtermiņā: ko tad, kad sāksies izmaiņas?), uzvarēja draudzība un salīdzinājums ar zivi un makšķeri, kur labāk makšķere: cilvēks, kurš spēj konsultēt un atbildēt.

Morāle: vispār jau “mēs abi” viens otram esam vajadzīgi un ir jauki, kad izdodas gūt baudu no procesa. Lai mums izdodas!

1. Projektējuma un/vai darba uzdevuma kvalitāte. Saņemamies, analītiķi!

Vakariņās daudz kritikas, man par lielu pārsteigumu, izskanēja faktiski par elementārām lietām, par kurām šķita, ka tām jau nu vajadzēja būt izmirušām līdz ar dinozauriem – par projektējuma un/vai darba uzdevuma tehniskās rakstīšanas kultūru: nedefinēta, pat pretrunīga terminoloģija, neizmērāmi jēdzieni, slikta vai neviendabīga prasību detalizācija, trūkst atsauču, prasību pārprotamība (jā, jā, ir gadījies. Arī viens no vakariņu analītiķiem pasmaidīja, ka pirms atvaļinājuma uzrakstījis prasību, atgriezies, izlasījis un reakcija – kurš <pašcenzēts> šo <pašcenzēts> rakstījis?).

Kritika arī par saturu pēc būtības – nav aprakstīti visi algoritma zari, kādas kontroles nepieciešamas, nav saprotams, kur kļūda, kur brīdinājums, kādā stāvoklī jāatgriežas programmai pēc darbības izpildes, kādas noklusētās vērtības liekamas, kāda funkcija kam seko, kas klasifikatoros, kas un kā lasāms no datubāzes, kas parametrizējams, kas šujams kodā. Labi, neizlikšos svētāka par Pāvestu, it kā es allaž rakstītu tikai perfektus projektējumus, bet nu goda vārds par šo pārmetumu daudzumu nobrīnījos.

Intuīcija saka, ka mazāk šādu kļūdu ir tiem analītiķiem, kuri iepriekšējā dzīvē paši ir bijuši programmētāji. Tas nav obligāti, taču kaut kā vajadzētu atrast veidu pabūt programmētāja ādā. Man palīdz tas, ka šo to pati programmēju. Ja tas ir manis pašas projektēts, tad cenšos iztēloties, kā būtu, ja cits iedotu šo darba uzdevumu – kāda informācija man būtu vajadzīga.

2. Aprunāties par to, kā programmētājs vēlētos strādāt. Parasti sistēmanalītiķiem ir manevra iespējas pielāgoties. Kāds programmētājs vēlas pilnu kopskatu uz sistēmu un izpratni, kāda tajā ir loma katrai funkcija, cits izdara (pārkodē) sev uzdoto gabalu, atdod un staigā laimīgs. Jāsaprot starp rindiņām, jo reti kurš tā tiešā tekstā teiks, ka pārējais viņam neinteresē. Patiesībā svarīgāk ir nevis neizdarīt to, ko negrib, bet censties izdarīt to, ko grib.

Praksē zinu, kurš precīzi un klusu izpildīs to, ko esmu uzrakstījusi (arī ja esmu kļūdījusies – i aci nepamirkšķinās. Atzīšos – tas disciplinē :-) ). Zinu, kurš šaubīgā vietā pārjautās pirms izpildes. Zinu, kurš nāks un izklāstīs savas domas, bet kurš teiks, ka viņam viss vienalga, un kurš – ka var uzprogrammēt jebkādas analītiķa vēlmes, lai tikai dodu uzdevumu. Zinu, kuru ļoti kaitina, ja kaut kas nav uzreiz saprotams, un kurš ir mieramika, zinu, kurš strādās kamēr uztaisīs un kurš strādās līdz 16:59. Attiecīgi savu manevru iespēju robežās ar katru no viņiem rēķinos, pielāgojos. Patiesībā jau šie atšķirīgie stili ir ļoti interesanti un ne par vienu no viņiem neteikšu, ka būtu sliktāks vai labāks par pārējiem.

3. Ļaut programmētājam koncentrēties uz viņa darbu – neapgrūtināt ar lietām, kurām JĀBŪT atrisinātām analīzes līmenī. Programmēšanas pasaule ir interesanta un daudzpusīga: tehnoloģijas un standarti, koda izstrādes vadlīnijas, nosaukumu konvencijas, debugi un exceptioni, branči un integritāte, atkārtojamizmantojamība un mantošanas, iebūvētas un jaunveidojamas metodes, masīvi un cikli, vārdu sakot, lietas, kurās cilvēkam no malas var būt līdzīgas sajūtas kā skatoties zvaigznēs un mēģinot saprast, cik tālu tās ir. Programmētājam pietiek ko noņemties ar to visu, un lai vēl turētu rociņu analītiķim?

4. Konsultēties ar programmētājiem – cik viegli vai sarežģīti ir šāds variants, kā konkrētajā situācijā labāk rīkoties, kāda konceptuāli būtu prātīgāka rīcība. Tas dažreiz nav viegli, sevišķi tad, kad šķiet, ka pati gudra. Gadās, ka tas, ko analītiķis iecerējis “lai vieglāk uzprogrammēt” un jau sasolījis klientam, izrādās, ka programmētājam dēļ tā jāveido speciāla apstrāde.

5. Uz programmētāju jautājumiem atbildēt ASAP. Jo jautājums parasti nozīmē, ka virpa vai nu ir izslēgta, vai nu kaut kur ir risks palikt pagaidu vai nepabeigtam risinājumam.

6. Vienoties, varbūt var paskatīties rezultātu vēl pavisam darba variantā, kaut lietotāja saskarni.

7. Kad iespējams, censties savus ieteikumus apkopot, jo ir kaitinoši ik pa laikam atgriezties pie jauniem sīkumiem. Atvainoties programmētājam vai vismaz vainīgi pasmaidīt, ja tā gadās. Tomēr – ja nu ir tā sanācis, labāk lai gadās nokaitināt programmētāju, nevis kaut ko neizdarīt tāpēc, ka “ai, neērti bija prasīt”.

8. Pārbaudīt, pirms dot kāda sūdzību programmētājam kā darba uzdevumu viņa kļūdas labošanai. Ai, mēdz gadīties, ka kļūdas cēlonis ir pavisam cits… kaut vai DB dati, kas sabojāti un varbūt pat paša analītiķa neuzmanības dēļ. Protams, jāskatās, kas projektam tobrīd ir izdevīgāk un kāda veida sūdzība tā ir – var vienoties, ka programmētājs pats veiks problēmas cēloņa izpēti, taču tai būtu jābūt norunai, nevis praksei.

Īsumā tas arī viss. Aiz kadra paliek profesionālās lietas – to apgūšanai ir akadēmiskā skola. Mans blogs vairāk velk uz dzīves skolas pusi.

Visbeidzot, draudzēties vai ievērot distanci? Profesionāļi var gan tā, gan tā – esmu pārliecinājusies, ka tam nav izšķirošas nozīmes. Nu, jā, tā personīgi patīkamāk ir koleģiāli draudzēties. Un noder šad tad pievaldīt mēli :-). Nu, vismaz censties.

P.S. Kamēr neesmu uzrakstījusi analītiķa lietošanas pamācību, tikai viens ieteikums programmētājiem: pašam nelabot pa kluso analītiķa kļūdas vai it kā kļūdas. Vai nu aprunāties, vai taisīt kā likts.

Sistēmanalītiķa sadarbība ar projekta vadītāju


Pildu iekšējo apņemšanos uzrakstīt savas domas par kārtējās, šoreiz 27.04.2011 Analītiķu vakariņās skatīto tēmu. Par pamatu paņēmu Vladimira Ivanova prezentāciju un tajā izvirzītos apskatāmos jautājumus.

Viss šeit tālāk paustais ir manas kā ilggadējas sistēmanalītiķes absolūti personīgās un vēl absolūtāk subjektīvās domas.

Sākšu ar pārfrāzētu stāstu iz dzīves, kuras oriģināls skan šādi: Ārstu kongress. Uzstājas aizrobežu bērnu ārsts. Pieceļas kājās Latvijas ārste un jautā – sakiet, bet kā jūs cīnāties ar mātēm? Aizrobežu ārsts izbrīnīts pārjautā – cīnāmies? Mēs necīnāmies! Mēs ar viņām sadarbojamies!

Tātad. Sistēmanalītiķim jautā: kā tu cīnies ar projekta vadītāju? – cīnos? Es necīnos! Es ar viņu sadarbojos! Vai – Projekta vadītājam jautā: kā tu cīnies ar sistēmanalītiķiem? -cīnos? Es ar viņiem sadarbojos! Tas pats ir spēkā – programmētājam par testētāju, sistēmanalītiķim par dokumentētāju utt. Mēs sadarbojamies pat tad, ja no malas kādam savureiz šķiet, ka cīnāmies

1. Ko projektu vadītājs sagaida no sistēmanalītiķa IT projektā. Kādi ir analītiķa pienākumi, atbildība?

Visvienkāršākais, protams, būtu to pajautāt konkrētajam vadītājam, ja nu viņš gadījumā sagaida kafijas pienešanu :-) Bet, ja nopietni – es domāju, ka sagaida šīs lietas:

1)  Profesionalitāti (šo tālāk uzskatīšu kā pašsaprotamu un vairs neiztirzāšu – programmatūras izstrādes procesa izpratne, prasību analīze, modelēšana, SQL, projektēšana, spēja un vēlme rakstīt dokumentus, kvalitātes pasākumu ievērošana un uzlabošana, korekta attieksme pret klientu, laba un konstruktīva komunikācija ar pārējiem komandas locekļiem u.tml.);

2)  Sistēmisku, ilgspējīgu pieeju, atbildību par rezultātu un domāšanu ne tikai par to, kā tagad atrisināt problēmu, bet ar skatu nākotnē – kā tas ietekmēs citas sistēmas, kas notiks, kad DB ierakstu skaits pieaugs, cik tas ir adekvātiem resursiem realizējams konkrētajā situācijā, vai neradīs nepedagoģisku precedentu vai tieši otrādi – varbūt radīs labu precedentu u.t.t. (zināmā mērā iekļaujas profesionalitātē, tomēr izdalīju atsevišķi, esmu redzējusi (diemžēl, jaunībā pieredzes trūkuma dēļ arī pašai ir gadījusies) viendienīšu domāšanu ar visām no tā izrietošajām sekām);

3)  Patstāvību darba uzdevumu izpildē (nevis rafinētu slaistīšanos cerībā, ka neviens nepamanīs, ka vecais darbs jau beidzies un jauns nav uzdots). Viena no mana priekšnieka frāzēm, kas joprojām silda sirdi – par tevi man sirds mierīga, jo zinu, ka tu strādā, nav jāpārprasa, vai tev ir ko darīt un nav jāskatās uz nagiem (kā šad tad ir gadījies ar vienu otru);

4)  Iekļaušanos norunātajos termiņos un savlaicīgu izrunāšanu par iespējamām nobīdēm, to cēloņiem un iespējamiem risinājumiem. Līdzko ir aizķeršanās – nekavējoties jāiet un jārisina, jājautā, jāprecizē. Protams, ar mēra izjūtu (labāk apkopot jautājumus, nevis ik pēc 5 minūtēm skriet jautāt kārtējo lietu). Ja šis tiek ievērots, vadītājs nepārmet ne pačalošanu tviterī, ne ziņu palasīšanu pīppauzēs;

5)  Spēju uzdot jautājumus, nepaļaujoties uz pieņēmumiemai, bet es toreiz domāju, ka ar to domāts tas!”. Prasmi un vēlēšanos domāt, runāt un rakstīt izmērāmos jēdzienos. Nevis „datu operatoram nebūs ilgi jāgaida uz transakciju pabeigšanu”, bet ja izpildās nosacījumi x, tad 95% no transakcijām jāapstrādā laikā, kas mazāks par 1 sekundi. Nekādu „jāstrādā ātri un labi” vai „jāizpilda visas lietotāja prasības”;

6)  Pacietību. Gan apdomājot, gan meklējot materiālus, gan atkal un atkal skaidrojot un pamatojot savu domu, gan runājot ar dažādas kvalifikācijas klientiem, gan apmācot jaunos komandas locekļus (personīgi man ļoti noder diezgan ilgais pasniedzējas darba rūdījums);

7)  Interesi par jaunumiem tehnoloģijās – vismaz jēdzienu izpratnes līmenī. Analītiķus parasti tās tik ļoti neskar kā programmētājus, tomēr ir labi saprotoši māt ar galvu, kad par tām tiek runāts;

8)  Analītiķa pienākumi un atbildība? Atkal pieminēšu anekdoti. Tātad, stjuarte vadā pasažierus ekskursijā pa lidmašīnu – re, pirmajā stāvā baseins, otrajā sporta zāle, trešajā mākslīgā pludmale, ceturtajā restorāni, piektajā golfa laukums, sestajā sēdvietas. Ekskursijas noslēgumā – а теперь попробуем с этой фигней взлететь! Lūk, tas arī ir analītiķa pienākums – taisot golfa laukumu piektajā stāvā, nodrošināt arī, lai būtu iespējams ne tikai kopumā с этой фигней взлететь, bet arī lidot ilgi  un laimīgi.

9)  Visbeidzot, pats galvenais – izveidot noturīgu analītiķa brendu jeb zīmolu. Ja Vita teica, ka risinājums ir pārbaudīts un strādā OK, tātad – ar mierīgu sirdi varam to dot klientam. Nevis – nu, analītiķis it kā domā, ka ok, bet nu nez, kā būs, varbūt jāpalūdz, lai Jānis arī apskatās, ka tik nav kaut kas savārīts.

2. Analītiķa iesaistīšanās citos projekta posmos

Visos. Analītiķis ir tas, kurš bāž un bāzīs degunu visos posmos, kuru citi lamās visos posmos un kurš mēģinās stoiskā mierā to visu izturēt, labot, ko var labot, un mēģināt iemārketēt par fīčām vai vismaz sadzīvot ar to, ko vairs nevar labot vai kā labošana kopumā neatmaksāsies.

Koncepcija, prasību specificēšana, analīze – analītiķis pašsaprotami.

Programmēšana – savu iespēju robežās, dažreiz pat virs tām, analītiķis tur līdīs, sevišķi, ja programmētāju komanda, teiksim tā, nav pilnībā patstāvīga. Analītiķis parasti ir tas, kurš sacer vai vismaz pārlasa lietotājam rādāmo ziņojumu tekstus un ir tikai normāli, ja programmētājs prasa – iedod man tekstu šādai situācijai (ja tas jau nav PPA ielikts). Ir reizes, kad programmētājs piedāvā citu risinājumu, sak, mums jau ir uztaisīts šāds, vai varam lietot to? Ir reizes, kad ir vienalga, kā konkrēto vietu realizēt, tad analītiķis var teikt – uztaisiet, kā jums šajā gadījumā vieglāk. Bieži notiek apspriešanās – klau, vai šajā vietā ir iespējams šo logu uztaisīt tā, šo pogu tā un pēc šī taustiņa nospiešanas šitā? Programmētājs nereti atbild: VISS ir iespējams, saki, kā vajag, viss būs. Noklusējot, ka šīs pogas uztaisīšanai tā, vajadzīgas 2 nedēļas, bet šitā – 1 diena :-) .

Jāpiešaujas pie katra programmētāja, un domās tiek uzturēta tāda lieta kā programmētāja koeficients. Piemēram, ja Jānis pasaka, ka viņš to uztaisīt 3 dienās, reāli gan jau aizies visas sešas, tātad Jāņa koeficients ir 2. Ja Ieva saka, ka viņai tas prasīs divas dienas, parasti aiziet trīs, tātad Ievas koeficients 1,5. Šie koeficienti paši par sevi nav ne labi, ne slikti, svarīgi, ka tādi vispār ir, ar tiem vienkārši klusiņām jārēķinās. Par šādu koeficientu esamību viņi parasti nezina, tieši tāpat, kā sistēmanalītiķi ne vienmēr zina, kāds ir viņu koeficients projekta vadītāja acīs :-) Ideālajā pasaulē koeficients ir 0,8-1. Mazāk gan nevajag, liels risks kvalitātes zudumam.

 3. Ko projektu vadītājs nesagaida no sistēmanalītiķa, bet kur analītiķi mīl ielīst?

Pirmais, kas nāk prātā – klientiem uz savu galvu sasolīt zelta kalnus. Pēc tam ir neērta situācija un jādomā, ko darīt. Vai mēģināt izpildīt gandrīz neiespējamo (t.i. neadekvāti resursietilpīgo), vai analītiķis pats atsauks savu solījumu un kādā veidā, vai to darīs projekta vadītājs… un jūs jau zināt, kādas izjūtas pārņem, ja kādam ņem kaut ko nost, kas ir apsolīts.

Otrs, ko vadītājs negaida no analītiķa – dot vērtīgus norādījumus un neapšaubāmi zelta vērtas pamācības citiem, kā darīt viņu darbu, sevišķi vēl, ja runa ir par citiem projektiem. Tad gadās, ka tie projektu vadītāji mēdz vairāk vai mazāk uzkrītoši apjautāties, vai tiešām konkrēto analītiķi pietiekami nenodarbina, ka viņam atliek laiks bāzt degunu citu lietās?

4. Kāda loma projektā analītiķim ir teorijā un kāda tā ir praksē

Teorijā, manuprāt, analītiķim ir mazāka loma nekā praksē.

Ideālajā pasaulē analītiķis nodod ideālu projektējumu un aidā tālēs zilajās, pārējo paveic ideāli programmētāji, testētāji, dokumentētāji.

Reālajā pasaulē analītiķis ir visur – piedalās sapulcēs, sēž blakus programmētājam, stāsta testētājam, kas tajā vietā domāts, dokumentētājam norāda, ka šeit ir с точностью до наоборот, un sagatavo LASIMANI nodevumam.

Ja man liktu izvēlēties vienu galējībām – vai nu analītiķa ir tik daudz, ka bail konservu bundžu vaļā vērt, vai viņa pārējos posmos nav nemaz, es izvēlētos pirmo.

 5. Cik projekta vadītājam jāzina par biznesu, jāiedziļinās problēmās

Esmu piedzīvojusi un pārdzīvojusi dažādus vadītājus. Sākot ar tādiem, kuri reizi divās nedēļās paprasa progresa % (ja godīgi, nemaz nebija slikts variants :-) ), beidzot ar tādiem, kuri pāri visam kabinetam sauc – „nē, tajā vietā pogai jābūt pelēkai!”, laikā, kad klusiņām runāju ar programmētāju.

No projekta vadītāja sagaidu ne tik daudz biznesa zināšanas (tam ir biznesa zinātāji un sistēmanalītiķi), kā gribētos kopskatījumu uz sistēmu (protams, ja vien tas projektā nav manis pašas pienākums). Viņš mierīgi var nezināt detaļas, bet būtu labi, ja zinātu atbildi uz jautājumu – klau, vai mums sistēmā ir precedents šādam konceptuālam risinājumam? Atkal ne detaļās, bet lielos vilcienos. Nu, piemēram, vai šāda veida datu apmaiņu kādā vietā risinām caur DB sinonīmiem vai noteikts, ka jālieto tikai webservisi? Protams, ja uz šo jautājumu projektā var atbildēt cits vai tas ir kaut kur labi dokumentēts, vai kā citādi atrodams, tad projekta vadītājs to drīkst nezināt – atbildētājs tikpat labi var būt kā galvenais programmētājs, tā arhitekts, tā cits analītiķis.

Galvenais, lai ir nodrošināts kāds, kas to zina.

Vai projekta vadītājam jāvar aizvietot analītiķi?

. Gan projekta vadītājam, gan analītiķim jāvar aizvietot vienam otru, bet! – uz neilgu laiku, ne ilgāku par nedēļu, maksimums divām, ja tās savlaicīgi plānotas. Aizvietošana praksē gan nereti izpaužas tā, ka analītiķis administratīvi pieskata projekta vadītāja uzsāktās lietas un klientam pasaka vai nu to, ko pats analītiķis droši zina, vai vienojas par laiku, kad klients saņems atbildi vēlāk [kad būs atpakaļ projekta vadītājs], savukārt, kad projekta vadītājs aizvieto analītiķi, tas izpaužas tā: iespēju robežās pārplāno darbus uz laiku, kad analītiķis atgriezīsies, pieskata jau esošo darbu izpildi un informē interesentus par laiku, kad analītiķis būs atpakaļ. Dziļāku aizvietošanu darba ikdienā nesaskatu par obligātu, jo ne velti ir lomas – projekta vadītājs un ir analītiķis. Tad jau ir jārunā par riska menedžēšanu gadījumam, ja kāds no tiem izstājas.

Galu galā, ja tie būtu viens un tas pats, tad vai nu uzreiz būtu divi vienā, vai divi vadītāji, vai divi analītiķi.

6. Projekta vadītājs/analītiķis –kādi plusi, mīnusi

 Atkarīgs no projekta lieluma, galu galā ir projekti, kur visu izdara viens cilvēks. Ja projekts ir tik mazs, ka abas šīs lomas var sekmīgi apvienot – uz priekšu! Runājot par lielāku projektu – tādi paši plusi un mīnusi kā pats sev ķirurgs. Kājas pirkstu sev saoperēt var, bet ir vietas, kur tomēr jāuztic darbs citam, lai cik labi pats to prastu un izprastu. Līdz ar ko es teiktu, ka lielā projektā labāka kombinācija (ja vispār jākombinē!) būtu projekta vadītājs–galvenais arhitekts, nevis projekta vadītājs–analītiķis.

 7. Ieteikumi analītiķiem, kā veidot attiecības ar projektu vadītāju.

Papildus šiem – ieteikums viens: veidot attiecības, nevis gaidīt, ka tās izveidosies pašas, чудом. Pašsaprotami – strādāt no sirds. Un vērot, kā projekta vadītājs strādā, vai viņam pieņemamas ir strikti lietišķas attiecības, vai koleģiāla draudzība. Šeit universālas receptes nav, tik vien kā mans ieteikums – analītiķim censties pielāgoties vadītaja stilam. Gan tāpēc, ka pastāv subordinācija, gan tāpēc, ka projekta vadītājam tīri cilvēciski darbu nasta ir vēl smagāka. Jā, protams, analītiķim tā arī ir milzīga, tomēr, cik esmu piedzīvojusi labus projekta vadītājus, esmu redzējusi, cik daudz viņi strādā un kāds ir atbildības līmenis, un ļoti cienu viņu darbu.

Sliktais piemērs, kā nevajag darīt – epizode iz dzīves. Reiz, sensenos laikos… gadījās tā, ka biju dikti laicīgi pieteikusi atvaļinājumu, tad nomainījās projekta vadītājs un es kaut kā automātiski pieņēmu, ka viņš taču zina, ka tūlīt iešu atvaļinājumā. Bet viņš daudzo darbu pārņemšanas laikā to nebija ievērojis, un radās neveikla situācija – bija ieplānojis man darbus un rēķinājies ar mani, bet es – žvirkt! atvaļinājumā… (nevarēju pārcelt). No tā mācījos šādas kļūdas neatkārtot – man vajadzēja nevis pieņemt, bet laicīgi aprunāties. Jā, formāli man bija taisnība, bija iepriekšējā vadītāja saskaņots savlaicīgs iesniegums personāla pārvaldē. Bet cilvēciski man pilnīgi noteikti nebija taisnība.

Un vispār, ja tiks izpildīts 1.punktā minētais, tad 99,9%, ka attiecības ar projekta vadītāju būs labas :-) !

P.S. Kas attiecas uz pašu Vladimira prezentāciju – no manas puses visdziļākā cieņa un prieks par to, ka cilvēks, kura CV varētu aizņemt sīkā fontā kādas trīs lappuses, stāstu par sevi sāka ar to, ka ir divi burvīgi bērni!

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: