1.1. Konspekts Īss pārskats par kursu Izmantoti materiāli no ... - Fizmati
22.01.2015 • Views
Share Embed Flag

1.1. Konspekts Īss pārskats par kursu Izmantoti materiāli no ... - Fizmati

1.1. Konspekts Īss pārskats par kursu Izmantoti materiāli no ... - Fizmati

1.1. Konspekts Īss pārskats par kursu Izmantoti materiāli no ... - Fizmati

SHOW MORE
SHOW LESS
ePAPER READ
DOWNLOAD ePAPER
fizmati.lv

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

START NOW

<strong>1.1.</strong> <strong>Konspekts</strong><br />

Īss pārskats <strong>par</strong> <strong>kursu</strong><br />

<strong>Izmantoti</strong> materiāli <strong>no</strong> Project Management For Informatio Systems, James Cadle &<br />

Donald Yeates, 3rd edition, 2001<br />

Sistēma ir jāmaina ik pa 5 gadiem. Nāk jauna tehnika, programmēšanas valodas un<br />

iespējas.<br />

Programmatūras izstrādes metodoloģijas<br />

Ūdenskrituma modelis<br />

Ūdenskrituma modeļa vēsture aizsākas agrajos 70s gados. Šī modeļa pirmā<br />

<strong>par</strong>ādīšanas ir 1970 W Royce publikācija, kurā tika <strong>par</strong>ādīta iespēja formalizēt<br />

izstrādes procesus. Ūdenskrituma modelī sistēmas izstrāde ir sadalīta vairākās secīgās<br />

aktivitātēs vai fāzēs, kuras katras aktivitātes rezultāts tiek izmantots <strong>par</strong> ieejas<br />

informāciju nākamajai aktivitātei. Mūsdienās <strong>par</strong> ūdenskrituma modeli sauc jebkuru<br />

izstrādes metodoloģiju ar secīgām aktivitātēm neatkarībā <strong>no</strong> fāžu skaita un specifikas.<br />

Šim modelim ir virkne pozitīvu īpašību. Katras aktivitātes beigās tiek pielietota<br />

saražoto produktu verifikācija un validācija, kas palīdz sasniegt zināmu kvalitāti.<br />

Gadījumos, kad pasūtītāja prasības ir labi zināmas un saprotamas, ūdenskrituma<br />

modelis ir īstajā vietā.<br />

‘b’ modelis<br />

Viens <strong>no</strong> ūdenskrituma modeļa trūkumiem ir uzturēšanas fāzes neadekvāta<br />

pielietošana. Tā tiek uztverta kā atsevišķa fāze, it kā tai būtu atsevišķa ieejas un izejas<br />

informācija. Ūdenskrituma modelī netiek aprakstīta būtiskas uzturēšanas fāzes<br />

atšķirības <strong>no</strong> pārējām aktivitātēm. Jāpatur prātā, ka lielākā daļa darbietilpības, kura<br />

tiek patērēta programmatūras produkta dzīves cikla laikā, tiek patērēta uz uzturēšanas<br />

aktivitātēm.

‘b’ modeli izstrādāja N. Birrell un M. Ould, adresējot šo ūdenskrituma modeļa vāju<br />

vietu. Modelis ieguvis šādu <strong>no</strong>saukumu tāpēc, ka tā diagramma ir līdzīga ‘b’ burtam.<br />

Modelis būtībā ierosina katru izmaiņu uzturēšanas procesā uzskatīt <strong>par</strong> atsevišķo<br />

izstrādi, kurai ari ir jāiet cauri <strong>no</strong>teiktām fāzēm un aktivitātēm.<br />

‘V’ modelis<br />

Šajā modelī, kurš ir tikai vēl viena variācija <strong>par</strong> ūdenskrituma modeļa tēmu, veiksmes<br />

fāzes ir attēlotas burta ‘V’ veidā. V-veida modeļa piemērs ir attēlots zīmējumā zemāk.

Šajā diagrammā kreisais V zars <strong>par</strong>āda progresu sākot ar analīzi un projektēšanu līdz<br />

kodēšanai un pieaugošam sistēmas sadalījumam komponentēs. Labais V zars attēlo<br />

progresējošu sastāvdaļu salikšanu un testēšanu, beidzoties ar programmatūras<br />

produkta piegādi.<br />

Šī modeļa svarīgā īpašība ir dažādu fāžu savastarpējas atbilstības <strong>par</strong>ādīšana.<br />

Piemēram, patstāvīgas programmas vai moduļi tiek testēti pret patstāvīgo moduļu<br />

projektējumiem, integrētā sistēmai tiek veikta sistēm-testēšana pret sistēmasp<br />

projektējumu un visbeidzot gala sistēmai gala lietotāji veic akcepttestēšanu pret<br />

sākotnējām prasībām, <strong>no</strong>formētām prasību specifikācijā. Šajā modelī ar šīs atbilstības<br />

palīdzību, <strong>par</strong>ādās arī kvalitātes <strong>no</strong>droši<strong>no</strong>šie elementi.<br />

‘V’ modelis ir interesants projekta pārvaldniekam arī cita iemesla dēļ. Gadījumos, kad<br />

projektā tiek pieaicināti ārējie apakškontraktori, šis modelis <strong>no</strong>drošina skaidru<br />

izstrādes darba uzdevumu definēšanu un <strong>no</strong>devum pārbaudi.<br />

Pasoļu izstrādes modelis<br />

Arī pasoļu izstrādes modelis ir tikai kārtējais ūdenskrituma modeļa variants. Šo<br />

modeli pielieto gadījumos, kad projekta rezultāti tiek piegādāti pakāpeniski, katras<br />

fāzes beigās. Šis modelis padara testēšanas un piegādes procesus caurskatāmākus un<br />

vieglāk pārvaldāmu, jo gala lietotājs tiek iepazīstināts ar sistēmu jau projekta laikā.<br />

Dažreiz var šķist sarežģīti sadalīt sistēmu sastāvdaļās, kuru izstrāde un piegāde var<br />

būt neatkarīga. Parasti pēdējā piegāde satur visu iepriekš piegādāto sastāvdaļu<br />

integrāciju vie<strong>no</strong>tā produktā, kuru nepieciešams pārtestēt <strong>no</strong> sākuma līdz galam.<br />

Pasoļu piegāde ir saistīta ar ieviešanas procesu, tāpēc jau pirms soļu definēšanas, ir<br />

jābūt <strong>no</strong>skaidrotām visām prasībām. Pasoļu izstrādes modelis nav ieteicams projektos,<br />

kuros prasības nav skaidri definētas vai zināmas.<br />

Spirāles modelis<br />

Spirāles modelis atšķirās <strong>no</strong> ūdenskrituma modeļa, piedāvājot evolūcijas vai iteratīvu<br />

pieeju sistēmas izstrādei. Ūdenskrituma modelis fokusējas uz fāze-pēc-fāzes procesu

ar gala produktu <strong>no</strong> iepriekšējās fāzes, <strong>no</strong>nākot nākamajā. Šis piegājiens strādā labi<br />

gadījumos, kad prasības ir labi saprotamas un definētas, kā arī izstrādes vide ir<br />

pietiekami stabila. Ļoti bieži gadās situācijas, kad prasības nav zināmas gala<br />

lietotājiem, nav skaidri definējamas vai nav skaidrības <strong>par</strong> sistēmas pielietojumu<br />

praksē. Šajās situācijās var pielietot evolūcijas pieeju. Evolūcijas modelis <strong>par</strong>edz<br />

vairāku soļu ciklisku atkārtošanu, sniedzot arvien detalizētākas un skaidrākas<br />

prasības, kā arī atkārtojot dzīves ciklu vairākas reizes.<br />

Sākotnējā spirāles modeļa autors ir Barry Boehm. Tas ir attēlots zīmējumā zemāk.<br />

Projekts sākas ar spirāles centru un attīstās uz ārpusi. Atrodoties centrā, prasības ir<br />

grūti saprotams, bet tiek arvien vairāk papildinātas, virzoties uz priekšu pa spirāli.<br />

Kopējās projekta izmaksas pieaug ar katru nākamo soli pa spirāli. Modelis ir sadalīts<br />

četros kvadrātos. Kreisajā augšējā kvadrātā tiek <strong>no</strong>teikti mērķi un identificētas<br />

alternatīvas un ierobežojumi. Augšējā labajā kvadrātā alternatības ir <strong>no</strong>vērtētas un<br />

riski identificēti un izskatīti. Apakšējā labajā kvadrātā <strong>no</strong>tiek izstrādes uzdevumu<br />

risināšana. Apakšējā kreisejā kvadrātā tiek plā<strong>no</strong>ta nākamā fāze vai iterācija.<br />

Bohema spirāles modelis piedāvā svarīgu koncepciju, kurā mērķu <strong>no</strong>teikšana, risku<br />

pārvaldība un plā<strong>no</strong>šana ir ieļauti vispārējā ciklā.<br />

Programmatūras izstrādes projektos lietotie standarti<br />

Programmatūras izstrādes projektos tiek lietoti dažādi profesionālie standarti,<br />

piemēram,<br />

Sistēmas darbības koncepcija LVS 75:1996<br />

PPS – programmatūras prasību specifikācija LVS 70():1996<br />

Programmatūras projektējuma apraksts LVS 72:1996<br />

Lietotāja ceļvedis LVS 66:1992

Ir vairākas metodes, kā <strong>no</strong>fiksēt pasūtītāja vajadzības:<br />

Sistēmas darbības koncepcija<br />

Programmatūras prasību specifikācija (funkcionālās un nefunkcionālās prasības)<br />

Projektētājs izvēlas realizācijas vidi un līdzekļus. Nereti projektētāja lomu uzņemas<br />

programmētājs.<br />

Programmatūras ieviešanas process ir ļoti sarežģīts – tas ir saistīts ar sistēmas<br />

iedzīvināšanu pasūtītāja organizācijā, personāla apmācību.<br />

Uzturēšanā <strong>no</strong>tiek sistēmas kļūdu labošana un pasūtītāja atbalsts. Šajā posmā ir<br />

jācīnās ar izmaiņām. Vidēji sistēmas uzturēšana ilgst gadus, pēc kuriem sistēma<br />

<strong>par</strong>asti ir jāpārtaisa.<br />

1.2. Standarbu ievērošana IT projektu pārvaldībā<br />

Kas ir daudzinātais IEEE/EIA J-STD-016<br />

jeb kādus standartus lietot informācijas sistēmu izstrādē<br />

Likumi un standarti: obligātība un brīvprātība<br />

Neviens citas valsts likums vai kādas citas virsnacionālas institūcijas direktīva Latvijā<br />

nevar būt spēkā, kamēr to nav apstiprinājusi Saeima. Savukārt, ikvienai personai<br />

jāievēro tās valsts likumi, kurā tā atrodas. Te valda obligātība.<br />

Citādi ir ar standartiem. Pretēji tam, kā bija PSRS, standarti paši <strong>par</strong> sevi ir tikai<br />

ieteikumi, kuru ievērošana vai neievērošana, arī Latvijā, ir brīvprātīga. Nevienam<br />

standartam nav likuma spēka. Standarta ievērošanu padarīt obligātu var vai nu<br />

<strong>par</strong>edzot šādu prasību līgumā, vai arī kādā <strong>no</strong>rmatīvā aktā, piemēram, likumā,<br />

Ministru Kabineta <strong>no</strong>teikumos, firmas prezidenta rīkojumā u.tml. Taču standartu<br />

neobligātā daba nebūt ne<strong>no</strong>zīmē, ka tie būtu bez apdoma jāig<strong>no</strong>rē. Parasti standartos<br />

akumulēta plaša pieredze un tie balansē starp to, ko gribas, un to, ko praktiski var<br />

sasniegt. Šādas pieredzes ig<strong>no</strong>rēšana reti kad ved pie laba.<br />

Standarti kā kompromiss<br />

Kam vajadzīgi standarti, ja to ievērošana nav obligāta Informācijas teh<strong>no</strong>loģija un, it<br />

īpaši, programmēšana ir ļoti pateicīgs piemērs atbildei uz jautājumu.<br />

Akadēmiski izglītotiem datorprogrammu izstrādātājiem labi zināms (ir teorēmas,<br />

kurās tas pierādīts), ka nav nekādas iespējas <strong>no</strong>skaidrot, vai datorprogramma dara to,<br />

kas <strong>par</strong>edzēts, un nedara neko tādu, kas nav <strong>par</strong>edzēts. Mēs varam padarbināt<br />

programmu vienreiz ar vieniem datiem, otrreiz - ar citiem, trešoreiz utt., un katru reizi<br />

redzēt, ka <strong>no</strong>tiek tiešām tas, ko mēs gribējām sagaidīt. Taču vēl ir tūkstošā, miljonā un<br />

vēl arī citas reizes, kad būs citi dati. Kas būs tad, uzzināsim tikai tad, kad šī reize būs<br />

pienākusi. Tā mēs varam testēt programmu līdz pasaules galam, bet kādreiz taču tā arī<br />

"jālaiž darbā". Tātad datorprogrammas pasūtītājs un lietotājs vienmēr varēs gribēt un<br />

prasīt, lai programma būtu labāk uztaisīta un vairāk pārbaudīta un atkļūdota. Bet vai<br />

viņi var arī gaidīt "pasaules galu" un apmaksāt šo teorētiski nebeidzamo darbu No<br />

juridiskā viedokļa programmētājam ir faktiski neiespējami pārmest kļūdas programmā<br />

jau minēto apsvērumu dēļ. Tomēr gluži bezatbildīgu programmētāja rīcību arī

nedrīkst pieļaut, jo zaudējumi programmas ne<strong>par</strong>eizas darbības rezultātā dažkārt var<br />

būt katastrofāli. Ko darīt<br />

Ja nu lietotājs, cietis zaudējumus, iesūdzēs programmētāju tiesā, ko darīt tiesnesim<br />

(kurš vairumā gadījumu nav programmēšanas speciālists un viņam tādam arī nav<br />

jābūt) Viņš jautās ekspertiem, vai programmētājs varēja garantēti nepieļaut kļūdu un<br />

zaudējuma raša<strong>no</strong>s. Eksperti godprātīgi atbildēs, ka tas ir teorētiski neiespējami. Tad<br />

tiesnesis jautās, vai programmētājs ir darījis visu saprātīgi nepieciešamo, lai<br />

nepieļautu zaudējumus. Kas ir saprātīgi nepieciešamais Tas ir Standarts! Standarts(-<br />

i) ir pašreizējā teh<strong>no</strong>loģijas attīstības līmenī nepieciešamais, kompromiss starp gribēto<br />

un praktiski iespējamo, vie<strong>no</strong>šanās starp pasūtītāju un izpildītāju, balstoties uz pasaulē<br />

uzkrāto pieredzi. Ja programmētājs būs disciplinēti izpildījis visas <strong>no</strong>runāto standartu<br />

prasības, tiesnesis būs spiests viņu attais<strong>no</strong>t un zaudējumus atzīt <strong>par</strong> stihisku nelaimi.<br />

Toties līgumā <strong>no</strong>runāto standartu neievērošanas gadījumā pilnīgi pamatoti tiktu<br />

<strong>no</strong>tiesāts izstrādātājs.<br />

Starp citu, arī ierēdnis, kas būs pasūtījis programmas pie sava "čoma", ne<strong>no</strong>slēdzot<br />

detalizētu līgumu <strong>par</strong> disciplinētu standartu ievērošanu, var smagi un pelnīti ciest <strong>no</strong><br />

sava priekšnieka.<br />

Informācijas teh<strong>no</strong>loģijas valsts standartu sistēma<br />

Vai Latvijai nepieciešami pašai savi informācijas teh<strong>no</strong>loģijas standarti Pareizāk<br />

laikam būtu vaicāt, vai Latvijai vispār pietiktu resursu liela daudzuma standartu<br />

izstrādei. Arī mūsu virzība uz integrāciju Eiropā prasa harmonizāciju ar<br />

starptautiskiem standartiem.<br />

Tāpēc izstrādājami tikai tādi standarti, kas nepieciešami Latvijas kā latviešu valsts<br />

eksistencei. Skaidrs, ka tie gandrīz vienīgi skars latviešu valodas lietošanas iespēju<br />

<strong>no</strong>drošināšanu un unifikāciju. Pārējie standarti būs vai nu ISO un Eiropas Savienības<br />

standartu tulkojumi, vai arī, ja tie izrādītos retāk vai šaurāk lietojami, tiks iecelti valsts<br />

standarta rangā pat bez tulkošanas.<br />

Ir vērts piezīmēt, ka ikvienas valsts teritorijā starptautiskiem standartiem ir tikai<br />

ieteikumu raksturs, bet spēkā ir tikai tie, kas iecelti valsts standarta rangā. Tomēr, kā<br />

jau minējām, pat pēdējiem nav likuma spēka.<br />

Standartizācijas procesu Latvijā administrē Eko<strong>no</strong>mikas ministrijas pārraudzībā esošā<br />

SIA "Latvijas Standarts". Šī institūcija pārstāv Latvijas Republiku starptautiskajās<br />

standartizācijas organizācijās ISO (Starptautiskā Standartizācijas organizācija) un<br />

CEN (Eiropas Standartizācijas organizācija), glabā un izplata standartu tekstus, kā arī<br />

organizē valsts standartu izstrādi vai starptautisko standartu adaptāciju. Katrā<br />

tautsaimniecības <strong>no</strong>zarē, kurā <strong>no</strong>tiek kādas standartizācijas darbības, <strong>par</strong>asti <strong>no</strong>dibina<br />

vienu standartizācijas tehnisko komiteju. Informācijas teh<strong>no</strong>loģijas <strong>no</strong>zarē tāda ir<br />

1995.gada maijā dibinātā Informācijas teh<strong>no</strong>loģijas Standartizācijas tehniskā komiteja<br />

(ITSTK). Šī komiteja skaidrības labad savā <strong>no</strong>likumā ierakstījusi, ka tās darbība<br />

aptver precīzi tos pašus jautājumus, kas ir ISO/IEC Pirmās apvie<strong>no</strong>tās tehniskās<br />

komitejas (ISO/IEC Joint Technical Committee One) kompetencē. Kā zināms, šīs<br />

komitejas aptvertā <strong>no</strong>zare saucas "information tech<strong>no</strong>logy".<br />

Tomēr vēlreiz jāpasvītro, ka visas minētās un neminētās standartizācijas un<br />

termi<strong>no</strong>loģiskās aktivitātes nerada visiem obligātus likumus. Tikai valsts var <strong>no</strong>teikt,<br />

kuri standarti ievērojami obligāti, kā tā to ir darījusi, izdodot pazīstamos Ministru<br />

Kabineta Noteikumus [1].<br />

Pašreizējais stāvoklis<br />

Iespējamas Latvijas IT standartu izstrādes stratēģijas ir jau pasniegtas un aprakstītas<br />

vairākkārt [2-5]. Smaga resursu trūkuma apstākļos Latvija nekad nespēs adaptēt lielu

skaitu apjomīgo standartu, tulkojot tos latviski. Tas nemaz arī nebūtu lietderīgi, jo<br />

vairums standartu plaši lietoti netiek. Daudzos gadījumos būs jāapmierinās ar t.s.<br />

pirmās lappuses (cover page) metodi, kad standarta pirmā lappuse satur a<strong>no</strong>tāciju<br />

latviski, bet viss pārējais teksts ir atstāts kādā <strong>no</strong> Eiropas standartizācijas organizāciju<br />

darba valodām - angļu, franču vai vācu, <strong>par</strong>asti - angļu. Vairums standartu būtu<br />

jāadaptē vispār bez jebkādas tulkošanas, kad Informācijas teh<strong>no</strong>loģijas<br />

standartizācijas tehniskā komiteja (ITSTK) iesaka apstiprināt un nacionālā<br />

standartizācijas institūcija SIA "Latvijas Standarts" izziņo, ka tādi un tādi Eiropas<br />

standarti ir apstiprināti <strong>par</strong> valsts standartiem. Tomēr ITSTK ir stingri <strong>no</strong>teikusi, ka<br />

standarta adaptēšanas obligāts priekš<strong>no</strong>sacījums, neatkarīgi <strong>no</strong> metodes izvēles, ir<br />

standarta oriģinālā teksta brīva (ne obligāti bezmaksas) pieejamība Latvijā, bet<br />

termi<strong>no</strong>loģijas standarti gan ir jātulko visi.<br />

Programminženierijas standarti<br />

Katrai <strong>no</strong>zarei ilgstoši pastāvot, neizbēgami rodas šīs <strong>no</strong>zares pieredze un prakse.<br />

Standartos tiek apkopota attiecīgās <strong>no</strong>zares labākā prakse. Šos standartus izstrādā<br />

(<strong>par</strong>asti) starptautiskas organizācijas, kurās piedalās izcilākie attiecīgās <strong>no</strong>zares<br />

speciālisti. Standartu lietošana ir izplatīts paņēmiens kā panākt stabilitāti izstrādājamā<br />

produkta kvalitātē, tādējādi standartu ievērošanai jākļūst <strong>par</strong> neatņemamu prasību<br />

ikreiz, kad tiek slēgti piegādātāja - pasūtītāja līgumi <strong>par</strong> produkta piegādi.<br />

Viss nupat pieminētais pilnā mērā attiecas arī uz programminženierijas <strong>no</strong>zari.<br />

Jāpiebilst, ka standartu esamība neatrisina programminženierijas kvalitātes un<br />

produktivitātes problēmas. Standartu veiksmīga pielietošana iespējama tikai<br />

organizācijā, kurā ir atbilstoši apmācīts personāls un uzkrāta pieredze. Personāla ziņā<br />

ir prast pielietot atbilstoši situācijai tos ieteikumus, kurus standarti satur.<br />

Ieteikumi programmatūras dokumentācijas komplektam<br />

Turpmāk dota informācija <strong>par</strong> materiāliem (Latvijas valsts un starptautiskiem<br />

standartiem), kuri reglamentē programmatūras produktu izstrādes procesu un apraksta<br />

dokumentu veidu un dokumentos ietveramo informāciju, kura ir jāsagatavo<br />

programmatūras produktu izstrādes, uzturēšanas un darbināšanas (ekspluatēšanas)<br />

vajadzībām. Īpaši svarīgi šos <strong>no</strong>teikumus ievērot ir tādu <strong>no</strong>zīmīgu programmatūru<br />

izstrādē kā valsts <strong>no</strong>zīmes informācijas sistēmas. Izstrādāti priekšlikumi t.s. minimālā,<br />

ieteicamā un pilnā dokumentu komplekta sastāvam, kā arī raksturota minēto<br />

dokumentu <strong>no</strong>zīme. Visi ieteikumi ir veidoti, izmantojot starptautiskos, Latvijas valsts<br />

un citos standartos doto informāciju. Balstoties uz programmatūras projektu izstrādes<br />

laikā <strong>no</strong>vērotās pieredzes, minēti apsvērumi, kā konkrētā projektā izvēlēties<br />

izstrādājamo dokumentu komplektu.<br />

Pēc šīs informācijas vēlams vadīties arī zemākas <strong>no</strong>zīmes programmatūru gadījumā,<br />

ja to pasūta valsts vai pašvaldību institūcijas.<br />

Ieteikumi domāti programmatūras produkta lietotājorganizācijas vai<br />

pasūtītājorganizācijas visu līmeņu vadītājiem un darbiniekiem, lai <strong>no</strong>drošinātu<br />

standartiem atbilstošu informāciju <strong>par</strong> nepieciešamo programmatūras produkta<br />

dokumentāciju un tās saturu. Šeit apkopota īsa informācija <strong>par</strong> tiem dokumentu<br />

veidiem, kuri var tikt sagatavoti programmatūras izstrādes gaitā. Ņemot vērā šo<br />

dokumentu lomu programmatūras izstrādē un lietošanā, kā arī standartos apkopotos<br />

programmēšanas prakses ieteikumus, šie dokumenti ir sagrupēti trīs grupās -<br />

minimālais, ieteicamais un pilnais dokumentu komplekts. Šie dokumentu saraksti var<br />

tikt izmantoti, pasūtītājam un izpildītājam vie<strong>no</strong>joties <strong>par</strong> konkrētai programmatūrai<br />

sagatavojamiem dokumentiem. Papildus informācija, kas nepieciešama, lai izvēlētos<br />

sagatavojamos dokumentus, ir izstrādājamās programmatūras galvenās raksturiezīmes

un līgums starp pasūtītāju un izpildītāju, kurā ir <strong>no</strong>teikti darba apjomi, termiņi,<br />

savstarpējais darbu sadalījums, kā arī citi izstrādei būtiski momenti. Informācija<br />

izmantojama, lai <strong>no</strong>teiktu prasības izstrādātāja piegādātai dokumentācijai, kā arī lai<br />

pārbaudītu šīs dokumentācijas atbilstību prasībām.<br />

Definīcijas<br />

Izmantotas definīcijas un pamatjēdzieni (ISO 12119 un EIA/IEEE J-STD-016):<br />

Apskate (review) - programmatūras elementa(-u) vai projekta stāvokļa <strong>no</strong>vērtēšana,<br />

lai <strong>no</strong>skaidrotu pretrunas ar plā<strong>no</strong>tajiem rezultātiem un ieteiktu uzlabojumus. Šī<br />

<strong>no</strong>vērtēšana ir formalizēts process piemēram, pārvaldības apskates process, tehniskās<br />

apskates process, programmatūras inspekcijas process vai caurskates (walkthrough)<br />

process.<br />

Auditēšana (audit) - neatkarīga programmatūras produkta vai procesa <strong>no</strong>vērtēšana, lai<br />

<strong>no</strong>skaidrotu atbilstību standartiem, vadlīnijām (guidelines), specifikācijām un<br />

procedūrām.<br />

Datu bāze - savstarpēji saistītu datu kopums, kas datorā tiek uzglabāts kopā vienā vai<br />

vairākās datnēs.<br />

Ievaddati (input data) - dati, ko programmatūra saņem <strong>no</strong> ārēja avota.<br />

Izvaddati (output data) - dati, ko programmatūra <strong>no</strong>dod ārējam saņēmējam (mērķim).<br />

Kritiska programmatūra (critical software) - programmatūra, kuras kļūme dotu<br />

triecienu drošībai vai varētu būt cēlonis lieliem finansiāliem vai sociāliem<br />

zaudējumiem.<br />

Lietotāja dokumentācija - pilns dokumentācija komplekts drukātā vai elektroniskā<br />

formā, kas <strong>no</strong>drošina programmatūras lietošanu un vienlaikus ir programmatūras<br />

produkta sastāvdaļa.<br />

Nododamais dokuments jeb <strong>no</strong>devums (deliverable) - ikviens dokuments, ko sagatavo<br />

projekta izstrādāšanas laikā projekta vajadzībām, un <strong>no</strong>dod pasūtītājam kārtējā darba<br />

etapa vai visa projekta <strong>no</strong>slēgumā.<br />

Pieļaujamā vērtība - vērtība, kādu var pieņemt ievaddati, sistēmas iekšējie dati vai<br />

izvaddati programmatūras <strong>no</strong>rmāla darba režīma laikā.<br />

Prasību dokumentācija (arī prasību specifikācija) - dokuments, kas satur jebkādu<br />

rekomendāciju, prasību vai priekšrakstu kopumu, kurš programmatūrai ir jāapmierina.<br />

Produkta apraksts - dokuments, kurā aprakstītas programmatūras īpašības ar <strong>no</strong>lūku<br />

palīdzēt potenciāliem lietotājiem <strong>no</strong>vērtēt produkta atbilstību savām prasībām.<br />

Produkta atbalsts (product support) - <strong>no</strong>drošināšana ar informāciju, palīdzību vai<br />

apmācīšanu, lai instalētu programmatūru un sagatavotu to darbināšanai tai <strong>par</strong>edzētajā<br />

apkārtnē un lai padarītu pieejamas lietotājam <strong>par</strong>edzētās iespējas.<br />

Programmatūras dzīves cikls - ietver visu posmu, sākot <strong>no</strong> tā, ka ir radusies ideja kādu<br />

programmatūru izstrādāt, un beidzot ar brīdi, kad tiek izbeigta šīs programmatūras<br />

lietošana.<br />

Programmatūras pakotne (produkts) (software package) - pabeigts un dokumentēts<br />

programmu kopums, ko piegādā lietotājam <strong>no</strong>teiktu funkciju izpildīšanai.<br />

Programmatūras projektējuma apraksts (Software Design Description) -<br />

programmatūras sistēmas dokumentēts attēlojums, kas tiek radīts, lai atvieglotu<br />

izstrādājamās programmatūras analīzi, plā<strong>no</strong>šanu, īste<strong>no</strong>šanu un lēmumu pieņemšanu.<br />

Tas ir programmatūras sistēmas uzmetums vai modelis, kuru izmanto turpmākā<br />

izstrādes gaitā.<br />

Programmatūras uzturēšana (software maintenance) - programmatūras ekspluatācijas<br />

laikā veicamā modificēšana, kas nepieciešama, lai izlabotu kļūdas, uzlabotu

programmatūras darbību vai adaptētu sistēmu darbības vides vai prasību maiņas<br />

gadījumā.<br />

Programmatūras uzturēšanas rokasgrāmata - dokuments, kurš <strong>no</strong>drošina visu<br />

informāciju, kas nepieciešama programmatūras uzturēšanai.<br />

Programmatūras vienums (software item) - pirmkods, objektkods, vadības dati vai šo<br />

vienumu kopums.<br />

Projekta iekšējais dokuments - dokuments, ko sagatavo projekta izstrādāšanas laikā<br />

projekta vajadzībām, bet ne<strong>no</strong>dod pasūtītājam.<br />

Saskarne (interface) - a<strong>par</strong>atūras vai programmatūras komponenti, kas sasaista divus<br />

vai vairākus citus komponentus, vai arī lietotāju un programmatūru, lai <strong>no</strong>dotu<br />

informāciju <strong>no</strong> viena komponenta otram, vai arī <strong>no</strong> lietotāja programmatūrai un<br />

otrādi.<br />

Validācija (validation) - programmatūras <strong>no</strong>vērtēšana programmatūras izstrādāšanas<br />

procesa beigās, lai pārliecinātos <strong>par</strong> atbilstību programmatūras prasībām.<br />

Verifikācija (verification) - process, kurā <strong>no</strong>saka, vai produkts dotajā programmatūras<br />

izstrādes fāzē izpilda vai neizpilda iepriekšējo fāzu izvirzītās prasības.<br />

Programmatūras izstrādi reglamentējošie standarti un <strong>no</strong>teikumi<br />

Izstrādājot valsts institūciju rīcībā esošas sistēmas, kas <strong>par</strong>edzētas likumos un<br />

Ministru kabineta <strong>no</strong>teikumos minētas informācijas apstrādei un glabāšanai, kā,<br />

piemēram, Nodokļu maksātāju reģistrācijas un <strong>no</strong>dokļu uzskaites sistēma, jebkurā<br />

izstrādes vai uzturēšanas stadijā jāievēro atbilstība prasībām, kuras ir <strong>no</strong>teiktas valsts<br />

<strong>no</strong>zīmes datorizētām informācijas sistēmām [1]. Īpaši svarīgi ir ievērot punktu 13.10.,<br />

kas skan šādi: "sistēmu veidojot, jā<strong>no</strong>drošina tās uzturēšana un pēctecība, kā arī<br />

dokumentācijas atbilstība valsts standartiem, ērta lasāmība un pieejamība".<br />

Izstrādājot vai pasūtot programmatūru, ieteicams vadīties pēc šādiem Latvijas Valsts<br />

un starptautiskajiem standartiem:<br />

1. Valsts standarti, kas <strong>no</strong>saka latviešu valodas lietošanu un kultūras īpatnības:<br />

2. Informācijas teh<strong>no</strong>loģija, kodētas simbolu kopas. 8 bitu kodēto grafisko simbolu<br />

kopa Baltijas jūras reģiona valstīm (LVS 8-92)<br />

3. Informācijas teh<strong>no</strong>loģija, datoru tastatūras. Latviešu tastatūra datoriem (LVS 23-<br />

93)<br />

4. Informācijas teh<strong>no</strong>loģija, valodas lietošana datoros. Latviešu valoda datoriem (LVS<br />

24-93)<br />

2. Valsts standarti, kas <strong>no</strong>saka programmatūras dokumentēšanu dažādās tās attīstības<br />

stadijās:<br />

1. Informācijas teh<strong>no</strong>loģija. Programmatūras lietotāja dokumentācija (LVS 66:1996)<br />

2. Informācijas teh<strong>no</strong>loģija. Programmatūras prasību specifikācijas (PPS) ceļvedis<br />

(LVS 68:1996)<br />

3. Informācijas teh<strong>no</strong>loģija. Programmatūras testēšanas dokumentācija (LVS<br />

70:1996)<br />

4. Informācijas teh<strong>no</strong>loģija. Ieteicamā prakse programmatūras projektējuma<br />

aprakstīšanai (LVS 72:1996)<br />

5. Informācijas teh<strong>no</strong>loģija. Sistēmas darbības koncepcijas apraksts (LVS 75:1996)<br />

3. Valsts standarti, kas <strong>no</strong>saka programmatūras izstrādes procesa dokumentēšanu<br />

dažādās tās attīstības stadijās:<br />

1. Informācijas teh<strong>no</strong>loģija. Programmatūras projekta pārvaldības plāns (LVS<br />

67:1996)<br />

2. Informācijas teh<strong>no</strong>loģija. Programmatūras konfigurācijas pārvaldības plāns (LVS<br />

69:1996)<br />

3. Informācijas teh<strong>no</strong>loģija. Programmatūras verifikācijas un validācijas plāns (LVS

71:1996)<br />

4. Valsts standarti, kas <strong>no</strong>saka programmatūras kvalitātes <strong>no</strong>drošināšanas pasākumu<br />

veikšanu:<br />

1. Informācijas teh<strong>no</strong>loģija. Programmatūras kvalitātes <strong>no</strong>drošināšanas plāns (LVS<br />

65:1996)<br />

2. Informācijas teh<strong>no</strong>loģija. Programmatūras vienībtestēšana (LVS 73:1996)<br />

3. Informācijas teh<strong>no</strong>loģija. Programmatūras apskates un auditēšanas (LVS 74:1996)<br />

5. Starptautiskais standarts, kas <strong>no</strong>saka visa programmatūras dzīves cikla procesus,<br />

nepieciešamo dokumentāciju un tās saturu:<br />

1. Standard for Information Tech<strong>no</strong>logy. Software Life Cycle Processes. Software<br />

Development. Acquirer-Supplier Agreement (EIA/IEEE J-STD-016)<br />

6. Starptautiskais standarts, kas <strong>no</strong>saka programmatūras dzīves cikla procesus:<br />

1. Information tech<strong>no</strong>logy - Software life cycle processes (ISO/IEC 12207)<br />

7. Starptautiskais standarts, kas <strong>no</strong>saka prasības programmatūras produktam, kā arī to,<br />

kā veikt produkta testēšanu atbilstoši šīm prasībām:<br />

1. Information tech<strong>no</strong>logy. Software packages. Quality requirements and testing.<br />

(ISO/IEC 12119)<br />

1. PIEZĪME. Jāņem vērā, ka IEEE standartu kopa (std.610.12-1990 - std. 1219-1992)<br />

un Latvijas valsts standarti (LVS 65:1996- LVS 74:1996) atspoguļo vienu vie<strong>no</strong>tu<br />

pieeju programmatūras izstrādes un dokumentēšanas procesam, bet standarti<br />

EIA/IEEE J-STD-016 un LVS 75:1996 otru, nedaudz atšķirīgu. Tādēļ<br />

programmatūras izstrādes procesa sākumā nepieciešams vie<strong>no</strong>ties, kura <strong>no</strong> šīm<br />

koncepcijām tiks ņemta <strong>par</strong> pamatu. Šādā gadījumā otras grupas standartus var<br />

izmantot atsevišķu jautājumu vai dokumentu detalizēšanai. Ieteicams lietot EIA/IEEE<br />

J-STD-016, jo tas ir jaunāks, kaut gan nav tulkots latviski.<br />

Standartu pieejamība<br />

Latvijas nacionālos jeb valsts standartus saskaņā ar <strong>no</strong>likumu drīkst izplatīt tikai SIA<br />

"Latvijas Standarts", kura adrese ir šāda:<br />

Kr.Valdemāra ielā 157, LV-1013, Rīgā, tel. 7 362 250 (standartu bibliotēka).<br />

Bibliotēkā atrodami ISO/IEC un CEN standartu teksti, kas apstiprināti aptuveni pēc<br />

1995. gada, kad Latvija iestājās minētajās organizācijās. Tur atrodami arī daudzi, bet<br />

ne visi agrāk apstiprinātie ISO/IEC standarti.<br />

Agrāku gadu ISO/IEC u.c. standarti atrodami arī Latvijas Patentu Tehniskajā<br />

bibliotēkā (Šķūņu ielā 17; LV-1050, Rīgā, fakss 7 210 767, tel. 7 227 310).<br />

IEEE standartus var pasūtīt, piemēram, pa faksu<br />

1.908.981.9667<br />

Tiešsaistes (on-line) informācija <strong>par</strong> IEEE standartiem iegūstama globālā tīmeklī:<br />

http://stdsbbs.ieee.org/<br />

Pasta adrese:<br />

IEEE Customer Service<br />

The Institute of Electrical and Electronics Engineers, Inc.<br />

445 Hoes Lane, P.O. Box 1331, Piscataway,<br />

NJ 08855-1331, U.S.A.<br />

Ar visiem minētiem tekstiem var iepazīties (bet ne kopēt, jo to nepieļauj autortiesību<br />

ierobežojumi) arī Rīgas Informācijas teh<strong>no</strong>loģijas institūtā.<br />

Programmatūras lietošanai un uzturēšanai nepieciešamā dokumentācija<br />

Standarti un metodiskie materiāli, kas regulē jebkuras programmatūras izstrādi, operē<br />

ar tādu jēdzienu kā programmatūras dzīves cikls, kas ietver visu posmu sākot <strong>no</strong> tā, ka<br />

ir radusies ideja kādu programmatūru izstrādāt, un beidzot ar brīdi, kad tiek izbeigta

šīs programmatūras lietošana. Neatkarīgi <strong>no</strong> tā, vai šo dzīves ciklu uzskata kā<br />

sastāvošu <strong>no</strong> dažādiem etapiem vai dažādiem procesiem, tā neatņemamas, visciešāk ar<br />

lietotāju saistītās sastāvdaļas ir programmatūras darbināšana jeb ekspluatācija<br />

(operation) un uzturēšana (maintenance). Reāli programmatūras darbināšana sākas ar<br />

brīdi, kad tā tiek oficiāli <strong>no</strong>dota pasūtītājam.<br />

Iespējamie dokumentācijas komplekti<br />

Standarts ISO/IEC 12119 <strong>no</strong>saka, ka programmatūras produktam, kurš tiek izplatīts<br />

vai <strong>no</strong>dots pasūtītājam, ir jāsatur programma (un dati, ja tādi nepieciešami), kā arī<br />

jābūt apgādātam ar dokumentāciju, kura ietver produkta aprakstu un lietotāja<br />

dokumentāciju. Tas var būt pietiekami gadījumos, kad lietotājs programmatūras<br />

produktu tikai izmanto, bet neveic nekādu tā labošanu, modificēšanu u. tml. Šādā<br />

gadījumā lietotāja rīcība ierobežojas tikai ar programmatūras darbināšanu, kā arī tās<br />

gaitā atklāto kļūdu un neatbilstību fiksēšanu. To <strong>no</strong>vēršanas kārtība ir atkarīga <strong>no</strong><br />

programmatūras pasūtītāja un piegādātāja (izstrādātāja vai pārdevēja) savstarpējām<br />

attiecībām, kuras iepriekš <strong>no</strong>runātas un dokumentētas atbilstošā veidā (ar līgumu,<br />

līguma pielikumu u.tml.).<br />

Pieredze rāda, ka programmatūras ilgstošas lietošanas laikā ir nepieciešams veikt tās<br />

būtiskas modifikācijas, kā pārvietošanu uz citu a<strong>par</strong>atūru, pārveidošanu atbilstoši<br />

mainītām pasūtītāja vajadzībām utt. Piemēram, ja programmatūras darbība lielā mērā<br />

ir atkarīga <strong>no</strong> spēkā esošās likumdošanas, ir sagaidāms, ka tās uzturēšanas laikā<br />

nāksies izdarīt daudzus pārveidojumus. Šādos gadījumos programmatūras uzturēšana,<br />

neatkarīgi <strong>no</strong> tā, kas to veic, ir iespējama tikai tad, ja papildus iepriekš minētai<br />

dokumentācijai programmatūras produkta izstrādes laikā ir sagatavota vēl virkne<br />

būtisku dokumentu.<br />

1.tabulā ir dots visu programmatūras lietošanai un uzturēšanai nepieciešamo<br />

dokumentu saraksts, kā arī dotas rekomendācijas t.s. minimālam, ieteicamam un<br />

pilnam dokumentu komplektam.<br />

Tabula 1. Programmatūras uzturēšanai nepieciešamā dokumentācija.<br />

okumenta <strong>no</strong>saukums Komplekts Rekomendējošie materiāli dokumenta izstrādei<br />

Min Ieteic Pilns<br />

rogrammatūras lietošanai nepieciešamā dokumentācija<br />

rogrammatūras produkta apraksts + + ISO/IEC 12119; EIA/IEEE J-STD-016 (I.2.1.)<br />

rogrammatūras versijas apraksts + + EIA/IEEE J-STD-016 (I.2.2.)<br />

rogrammatūras lietotāja dokumentācija + + +<br />

LVS 66:1996; ISO/IEC 12119; EIA/IEEE J-STD-<br />

016<br />

rogrammatūras instalēšanas apraksts* + + + EIA/IEEE J-STD-016 (E.2.3.)<br />

rogrammatūras izpildkodi + + + EIA/IEEE J-STD-016 (I.2.1.)<br />

rogrammatūras uzturēšanai papildus nepieciešamā dokumentācija<br />

rogrammatūras darbības koncepcijas apraksts + + LVS 75:1996; EIA/IEEE J-STD-016 (F.2.1.)<br />

rogrammatūras prasību specifikācija + + +<br />

LVS 68:1996;EIA/IEEE J-STD-016 (F.2.2., F.2.3.,<br />

F.2.4.)<br />

rogrammatūras projektējuma apraksts + +<br />

LVS 72:1996; EIA/IEEE J-STD-016 (G.2.1., G.2.2.,<br />

G.2.4.)<br />

atu bāzu projektējuma apraksts* + + + EIA/IEEE J-STD-016 (G.2.3.)<br />

rogrammatūras pirmkodi + + + EIA/IEEE J-STD-016 (G.2.1.)<br />

rogrammatūras uzturēšanas rokasgrāmatas + EIA/IEEE J-STD-016 (5.13.8.)

ogrammatūras uzturēšanas plāns + ISO/IEC 12007<br />

rogrammatūras uzturēšanas procedūra + ISO/IEC 12007<br />

Dokumenti, kuri ietverami attiecīgā komplekta sastāvā, atzīmēti ar "+"ailē Komplekts<br />

(Min, Ieteic un Pilns attiecīgi). Analizējot šos dokumentu komplektus, jāņem vērā<br />

nākamajā punktā dotā informācija.<br />

Minimālais komplekts ietver tos dokumentus, bez kuriem faktiski nav iespējama ne<br />

programmatūras lietošana, ne uzturēšana, t.i., tos dokumentus, bez kuriem<br />

programmatūra nav uzskatāma <strong>par</strong> pabeigtu un nevar tikt pieņemta.<br />

Ieteicamajā komplektā iekļauti tie dokumenti, kuri <strong>no</strong>drošina <strong>no</strong>rmālu<br />

programmatūras lietošanu un neliela apjoma pārveidojumu (pārprogrammēšanas)<br />

veikšanu tās uzturēšanas laikā. Protams, t.s. ieteicamais komplekts nav vienīgais<br />

iespējamais un konkrētā gadījumā, ja to prasa projekta īpatnības, <strong>no</strong> tā var nedaudz<br />

atkāpties uz vienu vai otru pusi.<br />

Pilnajā komplektā <strong>no</strong>rādītie dokumenti atspoguļo pilnu informāciju, kura ir<br />

izstrādātāja rīcībā <strong>par</strong> programmatūras produktu, un kura ir nepieciešama gan pašam<br />

izstrādātājam jaunu produkta versiju attīstīšanai, gan arī personālam, kurš veic<br />

programmatūras būtisku mainīšanu un pilnveidošanu tās uzturēšanas laikā.<br />

Dokumentācijas komplektu īss raksturojums<br />

Apvie<strong>no</strong>jot 1.tabulā dotos dokumentus minimālā, ieteicamā un pilnā dokumentu<br />

komplekta sastāvā, tika ņemti vērā šādi apsvērumi:<br />

1. standartos aprakstītais attiecīgo dokumentu sastāvā ietveramās informācijas<br />

raksturs;<br />

2. programmatūras izstrādāšanas gaitā radusies pieredze, kas uzkrāta un apkopota<br />

starptautiskos standartos;<br />

3. programmatūras izstrādes un kvalitātes pārvaldības funkciju izpildes laikā <strong>no</strong>vērotā<br />

un uzkrātā pieredze.<br />

Šis dalījums faktiski atspoguļo informācijas <strong>no</strong>vērtējumu - lai programmatūru lietotu,<br />

ir vajadzīgs vismaz tas, kas ietverts minimālā dokumentu komplekta sastāvā. Ja<br />

nepieciešams pa laikam drusku kaut ko mainīt vai labot darba gaitā atklātās kļūdas,<br />

tad jābūt pieejamai tai informācijai, kura ietverta ieteicamā komplekta sastāvā, bet ja<br />

nepieciešama <strong>no</strong>pietna modificēšana, tad var būt nepieciešama visa tā informācija, kas<br />

iekļaujama pilnā dokumentu sarakstā minētajos dokumentos. Šajā skatījumā nav<br />

svarīgi, kā rīcībā šie dokumenti atrodas, piemēram, nesagatavojot dokumentētā formā<br />

vismaz to informāciju, kura ir ietverta minimālā komplekta sastāvā, nevar būt runas<br />

<strong>par</strong> to, ka programma būtu pabeigta un to varētu pieņemt. Agri vai vēlu, tādu<br />

programmu nebūtu spējīgs lietot pat tās izstrādātājs.<br />

Turklāt arī šī informācija ir atkarīga <strong>no</strong> konkrētās programmatūras veida. Piemēram,<br />

ja programmatūra nestrādā ar datu bāzēm, 1.tabulas 2.3.1. punktā minētam<br />

dokumentam nav jēgas. Toties, lietojot datu bāzu sistēmas, ja bez programmu<br />

apraksta pieredzējis programmētājs vēl kaut kā var tās uzturēt, tad bez datu bāzu<br />

apraksta tas nekādi nav iespējams.<br />

1.tabulā doto informāciju kopumā vēlreiz var raksturot šādi - tajā ir dots visu<br />

standartos minēto dokumentu saraksts, kuru saturā tiek ietverta informācija, kas<br />

nepieciešama programmatūras lietošanas un uzturēšanas gaitā. Tieši kāda ir šī<br />

informācija - tas ir atkarīgs <strong>no</strong> konkrētās programmatūras un <strong>no</strong> līgumā <strong>no</strong>teiktām<br />

pasūtītāja un izstrādātāja attiecībām.<br />

Jāņem vērā, ka tabulā izmantotie standartos minētie attiecīgo dokumentu<br />

NOSAUKUMI NAV OBLIGĀTI, toties standartos prasītā informācija - ir gan; tāpat<br />

nav obligāti katru <strong>no</strong> minētajiem materiāliem <strong>no</strong>formēt kā patstāvīgu dokumentu.<br />

Toties OBLIGĀTI ir abām pusēm (pasūtītājam un izpildītājam) vie<strong>no</strong>ties <strong>par</strong>

<strong>par</strong>edzēto dokumentu komplektu, to konkrētiem <strong>no</strong>saukumiem un <strong>par</strong> to, kur kāda<br />

veida informācija tiks izvietota, un šo VIENOŠANOS DOKUMENTĒT. Šīs<br />

vie<strong>no</strong>šanās laikā pats svarīgākais ir <strong>no</strong>vērtēt konkrētās programmatūras īpatnības un<br />

izvēlēties tām atbilstošākos dokumentus. Bez tabulā dotajām rekomendācijām, ir<br />

iespējama arī jebkura cita komplektācija, izņemot minimālās samazināšanu.<br />

Kā jau minēts augstāk, 1. tabulā nav atspoguļots tas, kura <strong>no</strong> minētās dokumentācijas<br />

tiek <strong>no</strong>dota pasūtītājam un kura paliek tikai programmatūras izstrādātāju rīcībā.<br />

Nododamās dokumentācijas komplekts ir atkarīgs, pirmkārt, <strong>no</strong> tā, kas veiks<br />

programmatūras uzturēšanu. Šo darbu sadali vēlams īpaši atrunāt līgumā, vai arī slēgt<br />

atsevišķu līgumu <strong>par</strong> programmatūras uzturēšanu. Jāņem vērā, ka veicamā darba<br />

apjoms un līdz ar to programmatūras uzturēšanai nepieciešamais personāls un<br />

izmaksas ir aptuveni vienādas gan tad, ja programmatūras uzturēšanu veic lietotājs,<br />

gan tad, ja to dara programmatūras izstrādātājs. Lietotāja gadījumā izmaksas un<br />

darbietilpība būs lielāka vēl <strong>par</strong> tik, cik vajadzīgs, lai apgūtu programmatūras darbību<br />

un pirmkodus līdz tādam līmenim, ka ir iespējams veikt to modificēšanu. Par<br />

<strong>no</strong>dodamās dokumentācijas (deliverables) komplektu pasūtītājam un izstrādātājam<br />

jāvie<strong>no</strong>jas atsevišķi, rakstiski dokumentējot šo vie<strong>no</strong>ša<strong>no</strong>s (piemēram, līguma<br />

pielikumā). Jāņem vērā, ka dokumentu sagatavošana, īpaši ja tie tiek gatavoti<br />

<strong>no</strong>došanai lietotājam, ir darbietilpīga un līdz ar to arī dārga. Turklāt jāņem vērā, ka<br />

programmatūras uzturamība nebūt nepieaug proporcionāli tās dokumentācijas<br />

apjomam. Pārāk liels dokumentācijas apjoms izsauc pretēju efektu - to sagatavot un<br />

apgūt ir ļoti darbietilpīgi, var būt grūti lietot. Turklāt arī pieaug bīstamība, ka nav<br />

pilnībā izsekotas un atspoguļotas visas izmaiņas, kas tiek izdarītas programmatūras<br />

dzīves jebkurā etapā. Pēdējais moments ir sevišķi bīstams, jo padara dokumentāciju<br />

pretrunīgu.<br />

Vienkāršoti runājot, programmatūras lietošanā un tai atbilstošās dokumentācijas<br />

sagatavošanā var būt šādas raksturīgas situācijas.<br />

A. Programmatūra veic kādas <strong>no</strong>teiktas funkcijas, kuras praktiski nav nepieciešams<br />

mainīt. Turklāt starp programmatūras pasūtītāju un izstrādātāju ir <strong>no</strong>slēgts līgums <strong>par</strong><br />

programmatūras uzturēšanu atbilstoši kuram programmatūras lietošanas laikā atklātās<br />

kļūdas labo izstrādātājs. Šādā gadījumā lietotājam tiešām praktiski pietiek ar lietotāja<br />

dokumentāciju (kurā var būt ietverts arī instalēšanas apraksts, ja tāds nepieciešams)<br />

un programmatūras izpildkodiem. Visa pārējā dokumentācija, kas nepieciešama kļūdu<br />

labošanai, atrodas pie programmatūras izstrādātājiem. Šāda situācija ir raksturīga arī<br />

komerciālu programmatūru gadījumos, kad izstrādātājs ir īpaši ieinteresēts aizsargāt<br />

autortiesības. Šādiem produktiem programmatūras pirmkodi <strong>par</strong>asti ir tikai<br />

izstrādātāja rīcībā.<br />

B. Programmatūra veic kādas <strong>no</strong>teiktas funkcijas, kuras laiku pa laikam var būt<br />

nepieciešams mainīt. Šādos gadījumos, protams, ir iespējams arī iepriekšējā punktā<br />

minētais sadarbības variants. Ja programmatūras uzturēšanu pilnībā vai daļēji pārņem<br />

pasūtītājs, tādā gadījumā ir rūpīgi jāizanalizē, kāda apjoma izmaiņas veic viena vai<br />

otra puse un tā jā<strong>no</strong>drošina ar atbilstošo dokumentāciju. Katrā ziņā, lietotāja rīcībā ir<br />

nepieciešami programmatūras pirmkodi. Ieteikumi varētu būt šādi - sākot jau <strong>no</strong><br />

programmatūras projektēšanas, liela uzmanība ir jāpievērš tādai prasībai, kā<br />

programmatūras modificējamība, un konstanti jāuzrauga tās īste<strong>no</strong>šana. Pasūtītājam<br />

(un līdz ar to turpmākam lietotājam) var būt lietderīgi pārņemt savā ziņā operatīvu<br />

kļūdu labošanu un lokālu izmaiņu izdarīšanu, kā, piemēram, izmaiņas, kas saistītas ar<br />

kāda maksājuma aprēķināšanas algoritma maiņu. Šo pienākumu sadalei ir raksturīgs,<br />

ka, jo vairāk funkciju veic izpildītājs, jo vairāk pasūtītājs ir <strong>no</strong> tā atkarīgs, turklāt ir<br />

nepieciešams zināms papildus laiks darba attiecību <strong>no</strong>formēšanai. Savukārt <strong>no</strong>

lietotāja programmatūras uzturēšana prasa, lai būtu <strong>no</strong>drošināti atbilstošas<br />

kvalifikācijas speciālisti. Šiem speciālistiem darbs var būt tikai periodisks, turklāt,<br />

atšķirībā <strong>no</strong> izstrādātājiem, var būt darbietilpīgāks, jo profesionālam programmētājam<br />

apgūt cita izstrādātas programmas ir iespējams tikai ar zināmu papildus darba<br />

patēriņu. Tādējādi lielāka apmēra izmaiņu izdarīšanu var būt lietderīgi uzticēt<br />

izstrādātājam. Turklāt pēdējā gadījumā ne vienmēr tas būs sākotnējais<br />

programmatūras izstrādātājs.<br />

IETEIKUMS! Lai jebkurā programmatūras dzīves cikla posmā būtu iespējams<br />

izvēlēties kādu <strong>no</strong> sadarbības variantiem, svarīgi ir pašā izstrādes sākumā un turpmāk<br />

jebkuru <strong>no</strong>pietnu izmaiņu izdarīšanas laikā <strong>par</strong>edzēt, ka šādiem gadījumiem<br />

nepieciešamie dokumenti vispār tiks izstrādāti. Tie var tikt <strong>no</strong>doti lietotāja rīcībā tūlīt,<br />

var būt līgumā <strong>par</strong>edzēti <strong>no</strong>sacījumi, ka tiek <strong>no</strong>doti vēlāk zināmās situācijās, vai<br />

<strong>par</strong>edzēts vēl kāds cits piemērots variants.<br />

Pilnas projekta dokumentācijas raksturojums<br />

Iepriekšējā <strong>no</strong>dalījumā tika aplūkoti tikai tie standartu ieteiktie programmatūras<br />

produkta izstrādes dokumenti, kuri ir saistīti ar programmatūras lietošanu un<br />

uzturēšanu. Vienlaikus esam jau teikuši, ka pašā izstrādes sākumā un turpmāk jebkuru<br />

<strong>no</strong>pietnu izmaiņu izdarīšanas brīdī pats svarīgākais ir <strong>par</strong>edzēt, ka šādiem gadījumiem<br />

nepieciešamie dokumenti vispār tiks izstrādāti. Lai pārliecinātos, ka visā<br />

programmatūras attīstības gaitā tiek veikti pasākumi, kas nepieciešami, lai gala<br />

produkts atbilstu tam izvirzītajām prasībām, var būt nepieciešami vai vēlami vēl citi<br />

dokumenti, nekā minēti programmatūras lietošanai un uzturēšanai minētajā sarakstā.<br />

Daži <strong>no</strong> šiem dokumentiem var būt arī papildus <strong>no</strong>derīgi brīžos, kad tiek veiktas<br />

būtiskas modifikācijas. Tādēļ 2.tabulā tiek dots visu to dokumentu saraksts, kurus<br />

standarti iesaka izstrādāt programmatūras projekta dažādos etapos. Lai iegūtu pilnīgu<br />

kopskatu, šajā sarakstā ir iekļauti arī iepriekšējā <strong>no</strong>daļā aplūkotie dokumenti.<br />

Līdzīgi kā 1.tabulā, dokumenti šeit ir iekļauti minimālā, ieteicamā un pilnā<br />

dokumentu komplekta sastāvā, kuri raksturo dokumentos iekļautās informācijas<br />

apjomu.<br />

Tabula 2. Programmatūras izstrādes dokumentācijas pilns saraksts.<br />

okumenta <strong>no</strong>saukums Komplekts Rekomendējošie materiāli dokumenta izstrādei<br />

Min Ieteic Pilns<br />

rojekta sagatavošanas un uzturēšanas dokumenti<br />

ākotnējie projekta priekšlikumi (Preliminary<br />

esign Proposal)<br />

+ +<br />

DATI firmas standarts<br />

PKN.STD.PPPR.22.1.B.1995<br />

īgums ar pasūtītāju + + +<br />

īguma izpildes kalendārais plāns* + + +<br />

rojekta dienasgrāmata + +<br />

rogrammatūras izstrādes datne + + EIA/IEEE J-STD-016<br />

rojekta plā<strong>no</strong>šanas dokumenti<br />

rogrammatūras (Sistēmas) izstrādes plāns + EIA/IEEE J-STD-016<br />

rojekta pārvaldības plāns* + LVS 67:1996; IEEE 1058.1<br />

rogrammatūras konfigurācijas pārvaldības<br />

lāns*<br />

+ + LVS 69:1996; IEEE 1042, IEEE 828<br />

rojekta iekšējo pārbaužu plāns* + +<br />

valitātes <strong>no</strong>drošināšanas plāns* (Software<br />

uality Assurance Plan)<br />

+ + LVS 65:1996; IEEE 730.1<br />

rogrammatūras verifikācijas un validācijas + LVS 71:1996; IEEE 1012

lāns<br />

rogrammatūras (kvalifikācijas) testēšanas<br />

lāns<br />

+ + + LVS 70:1996; EIA/IEEE J-STD-016, IEEE 829<br />

rogrammatūras pārcelšanas (transition) plāns + EIA/IEEE J-STD-016<br />

rogrammatūras instalēšanas plāns +* + + EIA/IEEE J-STD-016 (E.2.3.)<br />

rojekta specifikācijas<br />

arbības koncepcijas apraksts (Operational<br />

oncept Description)<br />

+ + LVS 75:1996; EIA/IEEE J-STD-016 (F.2.1.)<br />

istēmas/apakšsistēmas (kopā ar a<strong>par</strong>atūru)<br />

rasību specifikācija<br />

+ + + LVS 72:1996; EIA/IEEE J-STD-016 (F.2.2.)<br />

rogrammatūras prasību specifikācija<br />

Software Requirements Specification)<br />

+ + + LVS 72:1996; EIA/IEEE J-STD-016 (F.2.4.)<br />

askarņu prasību specifikācija* + + + LVS 72:1996; EIA/IEEE J-STD-016 (F.2.3.)<br />

rogrammatūras produkta specifikācija + + ISO/IEC 12119; EIA/IEEE J-STD-016 (I.2.1.)<br />

rogrammatūras versijas apraksts + + EIA/IEEE J-STD-016 (I.2.2.)<br />

rojektējumu (design) dokumentācija<br />

istēmas/apakšsistēmas (kopā ar a<strong>par</strong>atūru)<br />

LVS 72:1996; EIA/IEEE J-STD-016 (G.2.1.)<br />

+ +<br />

rojektējuma apraksts<br />

IEEE 1016<br />

rogrammatūras projektējuma apraksts + +<br />

LVS 72:1996; EIA/IEEE J-STD-016 (G.2.4.)<br />

IEEE 1016<br />

askarņu projektējuma apraksts* + +<br />

LVS 72:1996; EIA/IEEE J-STD-016 (G.2.2.)<br />

IEEE 1016<br />

atu bāzu projektējuma apraksts* + + +<br />

LVS 72:1996; EIA/IEEE J-STD-016 (G.2.3.)<br />

IEEE 1016<br />

mplementēšanas dokumentācija<br />

rogrammatūras pirmkodi + + + EIA/IEEE J-STD-016 (G.2.1.)<br />

rogrammatūras izpildkodi + + + EIA/IEEE J-STD-016 (I.2.1.)<br />

ietotāja dokumentācija<br />

ietotāja rokasgrāmata + + +<br />

LVS 66:1996; ISO/IEC 12119; EIA/IEEE J-<br />

STD-016 (J.2.1.)<br />

atora programmēšanas rokasgrāmata** + EIA/IEEE J-STD-016 (I.2.3.)<br />

rogramma<strong>par</strong>atūras atbalsta rokasgrāmata** + EIA/IEEE J-STD-016 (I.2.4.)<br />

rogrammatūras uzturēšanas rokasgrāmatas + EIA/IEEE J-STD-016 (5.13.8.)<br />

rogrammatūras ievadizvades rokasgrāmata + EIA/IEEE J-STD-016 (J.2.2.)<br />

atora darbināšanas rokasgrāmata + EIA/IEEE J-STD-016 (J.2.4.)<br />

estēšanas dokumentācija<br />

rogrammatūras testēšanas apraksts + + +<br />

LVS 70:1996; LVS 73:1996; EIA/IEEE J-STD-<br />

016 (G.2.3.); IEEE 1008; IEEE 829<br />

estu projektējuma specifikācija + + LVS 70:1996; IEEE 829<br />

estpiemēru specifikācijas + + LVS 70:1996; IEEE 829<br />

estēšanas procedūras specifikācija + + LVS 70:1996; IEEE 829<br />

estēšanas žurnāls + + + LVS 70:1996; IEEE 829<br />

roblēmu ziņojumi + +<br />

LVS 70:1996; IEEE 829; firmas problēmu<br />

reģistrācijas rīks

estēšanas (kopsavilkuma) pārskats + + + LVS 70:1996; IEEE 829<br />

rojekta iekšējo pārbaužu pārskatu dokumentācija<br />

rogrammatūras izstrādes plāna apskates<br />

ārskats<br />

+ LVS 74:1996<br />

rogrammatūras testēšanas plāna apskates<br />

ārskats<br />

+ + + LVS 74:1996<br />

rogrammatūras instalēšanas plāna apskates<br />

ārskats<br />

+ + + LVS 74:1996<br />

rogrammatūras pārcelšanas (transition) plāna<br />

pskates pārskats<br />

+ LVS 74:1996<br />

rogrammatūras projekta pārvaldības plāna<br />

pskates pārskats<br />

+ LVS 74:1996<br />

rogrammatūras verifikācijas un validācijas<br />

lāna apskates pārskats<br />

+ LVS 74:1996<br />

rogrammatūras konfigurāciju pārvaldības<br />

lāna apskates pārskats<br />

+ + LVS 74:1996<br />

rogrammatūras kvalitātes <strong>no</strong>drošināšanas<br />

lāna apskates pārskats<br />

+ + LVS 74:1996<br />

atorsistēmas darbības koncepcijas apskates<br />

ārskats<br />

+ + LVS 74:1996<br />

rogrammatūras prasību apskates pārskats + + + LVS 74:1996<br />

rogrammatūras projektējuma apskates<br />

ārskats<br />

+ + LVS 74:1996<br />

estēšanas gatavības apskates pārskats + LVS 74:1996<br />

estēšanas rezultātu apskates pārskats + + LVS 74:1996<br />

rogrammatūras lietojamības apskates<br />

ārskats<br />

+ LVS 74:1996<br />

rogrammatūras uzturamības apskates<br />

ārskats<br />

+ LVS 74:1996<br />

ritisku prasību apskates pārskats + 6 + LVS 74:199<br />

Šajā tabulā doti visi dokumenti, kurus rekomendē gatavot programmatūras produkta<br />

izstrādes laikā. Tā kā standartu kopas, uz kurām šajā tabulā ir dotas atsauces,<br />

atspoguļo nedaudz atšķirīgu pieeju programmatūras produkta un projekta<br />

dokumentēšanai (sk. 1. piezīmi <strong>no</strong>dalījumā 6.2.), vie<strong>no</strong>s standartos <strong>par</strong>edzētā<br />

informācija var būt iekļauta citu standartu <strong>no</strong>teiktā vienā vai vairākos atšķirīga<br />

<strong>no</strong>saukuma dokumentos. Tādēļ jāņem vērā, ka vienā projektā nekad nebūs vajadzīgi<br />

visi šīs tabulas pilnā dokumentu komplekta ailē <strong>no</strong>rādītie dokumenti. Piemēram, var<br />

tikt sagatavots vai nu Programmatūras izstrādes plāns atbilstoši standartam EIA/IEEE<br />

J-STD-016, vai arī Projekta pārvaldības plāns un/vai Programmatūras konfigurācijas<br />

pārvaldības plāns, Projekta iekšējo pārbaužu plāns un Kvalitātes <strong>no</strong>drošināšanas plāns<br />

atbilstoši 2.tabulā <strong>no</strong>rādītajiem IEEE standartiem.<br />

Tādējādi, pasūtītājam un izpildītājam vie<strong>no</strong>joties <strong>par</strong> izstrādājamo dokumentāciju,<br />

vispirms ir jāizvēlas, kura <strong>no</strong> standartu grupām tiks ņemta <strong>par</strong> pamatu. Tas neliedz<br />

otras grupas standartus izmantot atsevišķu jautājumu vai dokumentu detalizēšanai.<br />

Vēlreiz īpaši jāpasvītro tas, ka neviens <strong>no</strong> šiem standartiem nebūt neprasa, lai jebkurš<br />

<strong>no</strong> 2.tabulā dotiem dokumentiem tiešām tiktu sagatavots kā atsevišķs dokuments tieši<br />

ar <strong>no</strong>rādīto <strong>no</strong>saukumu. Standarti apraksta informācijas tipu un <strong>no</strong>teikti prasa, lai

projekta sākumā tiktu dokumentāli fiksēta vie<strong>no</strong>šanās, kura informācija tiks<br />

sagatavota un kādos konkrēta <strong>no</strong>saukuma dokumentos tā tiks izvietota.<br />

2.tabulā, tāpat kā iepriekšējā, nav dotas <strong>no</strong>rādes, kurš <strong>no</strong> šiem dokumentiem tiek<br />

izstrādāts tikai projekta iekšienē un kurš tiek <strong>no</strong>dots pasūtītājam. Par šiem<br />

jautājumiem pasūtītājam un izpildītājam katra konkrēta līguma gadījumā ir īpaši<br />

jāvie<strong>no</strong>jas un šī vie<strong>no</strong>šanās dokumentāli jāapstiprina. Nododamo dokumentu<br />

komplekts ir cieši saistīts ar programmatūras īpatnībām, abu pušu vie<strong>no</strong>ša<strong>no</strong>s <strong>par</strong><br />

programmatūras uzturēšanu, autortiesību aizsardzību, kā arī citiem jautājumiem.<br />

Atsauces<br />

1. LR MK Noteikumi Nr. 70 (pieņemti 19.03.1996.) Noteikumi <strong>par</strong> valsts <strong>no</strong>zīmes<br />

datorizēto informācijas sistēmu statusa piešķiršanas kārtību un tehniskās realizācijas<br />

prasībām.<br />

2. A.Ādamsone, J.Borzovs, R.Čevere, M.Lučkina. Framework for Potential Latvian<br />

Software Engineering Standards._ In: Hele-Mai Haav, Bernhard Thalheim(Eds.)<br />

Databases and Information Systems: Proc. 2nd Int. Baltic Workshop, Tallinn, 1996,<br />

pp. 105-112.<br />

3. J.Borzovs. Informācijas teh<strong>no</strong>loģija Latvijā: likumi un standarti._ Rakstu krājums<br />

"Latvija ceļā uz informācijas sabiedrību", Latvijas Akadēmiskā bibliotēka, 1996, lpp.<br />

35-40.<br />

4. I.Mētra. IT Standardization Activities in Latvia._ Baltic IT Review, No. 3, 1996,<br />

pp.48-50.<br />

5. J.Borzovs. Information Tech<strong>no</strong>logy in Latvia: Laws and Standards._ Baltic IT<br />

Review, No. 3, 1996, pp.44-47.<br />

2.1. <strong>Konspekts</strong><br />

Programminženierija<br />

Lekcijas saturs:<br />

Kas ir sistēma<br />

SDK<br />

Prasību uzkrāšana un analīze<br />

Prototipēšana<br />

Sistēmas projektēšana un analīze<br />

Kas ir sistēma<br />

Def. Informācijas sistēma (IS) ir cilvēku, datu, procesu un informācijas teh<strong>no</strong>loģiju<br />

kopums, kurš sadarbojas lai reģistrētu, uzkrātu un apstrādātu informāciju, kura<br />

nepieciešama organizācijas atbalstam.<br />

Def. Informācijas teh<strong>no</strong>loģijas (IT) ir moderns termins, kurš apraksta datoru<br />

teh<strong>no</strong>loģijas (a<strong>par</strong>atūras un programmatūras) kombināciju ar telekomunikāciju<br />

teh<strong>no</strong>loģijām (datu, balss u.c. tīkli).<br />

Sistēmas iedalās 7 veidos:<br />

Transakciju apstrādes sistēmas (Transaction Processing Systems) – uzkrāj un apstrādā<br />

uzņēmuma transakciju datus.

Vadības informācijas sistēmas (Management Information Systems) – <strong>no</strong>drošina<br />

vadībai atskaites <strong>par</strong> uzņēmuma transakciju apstrādi un operācijām.<br />

Lēmumu atbalsta sistēmas (Decision Support Systems) – palīdz identificēt lēmumu<br />

pieņemšanas iespējas vai <strong>no</strong>drošina informāciju lēmumu pieņemšanai.<br />

Izpildes informācijas sistēmas (Executive Information Systems)<br />

Ekspertu sistēmas (Expert Systems) – uzkrāj darbinieku kompetenci un pieredzi<br />

Komunikāciju un sadarbības sistēmas (Communication & Collaboration Systems) –<br />

<strong>no</strong>drošina efektīvu komunikāciju starp darbiniekiem, sadarbības <strong>par</strong>tneriem, klientiem<br />

un piegādātājiem, lai uzlabot viņu sadarbības iespējas.<br />

Biroja automatizācijas sistēmas (Office Automation Systems) – atbalsta dažāda veida<br />

biroja darbu plūsmas.<br />

Informācijas sistēmas veic šādas funkcijas : datu uzkrāšana, aktualizācija,<br />

reģistrēšana, maiņa, likvidēšana, piekļuves <strong>no</strong>drošināšana u.c.<br />

Mūsdienu informācijas sistēmas dzinējspēki ir šādi:<br />

Uzņēmējdarbības dzinējspēki<br />

eko<strong>no</strong>mikas globalizācija - jauns augošs starptautisks tirgus:<br />

pieprasījums pēc dažādu valodu, valūtu <strong>kursu</strong>, uzņēmējdarbības kultūru atbalsta;<br />

pieprasījums starptautisku datu konsolidācijas;<br />

pieprasījums pēc mutiskas un rakstiskas komunikācijas ar vadību un lietotājiem, kuri<br />

runā dažādās valodās.<br />

elektroniskas uzņēmējdarbības un komercijas aktualitāte;<br />

drošība un privātums;<br />

sadarbība un <strong>par</strong>tnerība;<br />

zināšanu vērtību pārvaldība;<br />

procesu uzlabošana un kvalitātes pārvaldība.<br />

Teh<strong>no</strong>loģiskie dzinējspēki<br />

datortīkli un internets (perspektīvākas teh<strong>no</strong>loģijas- xHTML un XML, skriptu<br />

valodas, tīmekļa specifiskas programmēšanas valodas, Intranets, Extranets, portāli,<br />

tīmekļa pakalpojumi (Web services);<br />

mobilas un bezvadu teh<strong>no</strong>loģijas (PDAs, Smart phones, Bluetooth)<br />

objektu teh<strong>no</strong>loģijas (objektu orientēta analīze un projektēšana, atkalizmantošanas<br />

iespējas, Agile izstrādes metodoloģija, objektu orientētas programmēšanas valodas C,<br />

java, Smaltalk, Visual Basic, .NET);<br />

uzņēmumu lietojumprogrammatūra (klientu apkalpošanas sistēmas, piegādes tīkla<br />

pārvaldības sistēmas, personāla vadības sistēmas, finansu sistēmas, tirgvedības un<br />

pārdošanas sistēmas, operāciju vadības sistēmas, uzņēmuma resursu plā<strong>no</strong>šanas u.c.);

1. attēls. Informācijas sistēmas izstrādes fāzes un tajās iesaistītie dalībnieki.<br />

Dinamiskas vai statiskas sistēmas (objekti mainās vai nemainās laikā)<br />

Izstrādes modeļi:

2. attēls. Secīgas un iteratīvas izstrādes modeļi.<br />

SDK<br />

Ar kādām metodēm SDK var dabūt gatavu Trīs avoti:<br />

1. tiesiskie jeb <strong>no</strong>rmatīvie akti

2. intervijas (grāmatas apraksts, kā to darīt)<br />

3. iepriekšējā pieredze<br />

Prasību analīze<br />

- tehniskā realizējamība (vai to var īste<strong>no</strong>t)<br />

- eko<strong>no</strong>miskā lietderība<br />

Prasības izanalizē, reizēm atgriežas pie prasību precizēšanas.<br />

Prasību uzkrāšana un analīze<br />

Prasību uzkrāšana:<br />

Tiek izstrādāta sistēmas prasību specifikācija:<br />

- Izpildāmas funkcijas (funkcionālais modelis)<br />

- lietojamie jēdzieni un to sakarības (datu modelis)<br />

- sistēmas funkcionēšana (dinamiskais modelis) prasības programmatūrai<br />

- prasības tehniskai drošībai<br />

- citas specifikas prasības<br />

Prasību analīze:<br />

Tiek izstrādātas rekomendācijas sistēmas izveidei:<br />

- sistēmas koncepcija<br />

- tehniska realizējamība un variantu analīze<br />

- eko<strong>no</strong>miska lietderība- vai ir eko<strong>no</strong>miski izdevīgi sistēmu taisīt<br />

- izmaksas un termini - cik maksā sistēmas izstrāde un cik ātri to var izveidot<br />

- darbu organizācija.<br />

Darbu organizācijas plāns, projekta vadība.<br />

Prototipēšana<br />

Prototipēšana - izstrādes metodoloģijas veids. Sākumā tiek izstrādāts sistēmas<br />

prototips, tas tiek <strong>par</strong>ādīt sistēmas pasūtītajam, lai precizētu prasības. Papildus<br />

prasības tiek uzskaitītas un pēc to realizācijas pasūtītājam atrāda nākamo prototipu.<br />

Parasti līgumā tiek atrunāts iterāciju skaits, lai nerastos domstarpības.<br />

Prototipēšanā ļoti bieži tiek izmantoti jau eksistējošie moduļi vai koda bibliotēkas.<br />

Prototipu izstrāde <strong>no</strong>tiek ātri un vienā iterācijā netiek izstrādāta visa sistēma, bet gan<br />

tās daļa. Tādējādi klients ātri ierauga topošo sistēmu un pārliecinās <strong>par</strong> tās sastāvdaļu<br />

piemērotību un nepieciešamību.<br />

Prototipēšanu izmanto gadījumos, kad (1) izstrādes komandai trūkst pieredzes līdzīga<br />

veida sistēmu izstrādē; (2) izstrādes vai sistēmas ārējā vide ir nestabila vai ne<strong>no</strong>teikta;<br />

(3) ir būtiskas problēmas lēmumu pieņemšanā.<br />

Sistēmas projektēšana un analīze<br />

Projektēšana:<br />

Tiek izstrādātas sistēmas projekts (projektējuma apraksts):<br />

- izpildāmas funkcijas (meņu)<br />

- ER modelis un datu struktūras<br />

- Sistēmas funkcionēšanas algoritms

- Lietotāju saskarsme (ekrānu formas un atskaites)<br />

- Standartprogrammatūras, datortehnikas, tīklu un citu elementu izvēle.<br />

Analīze:<br />

- Tiek akceptēts sistēmas projekts (pieprasījuma apraksts):<br />

- Standartprogrammatūras, tikli un datortehnikas<br />

- Instalācija un aprobācija<br />

- Simulēšana - reakcijas laiki, drošības situācijas<br />

Programmēšanas vides izvēle<br />

2.2. Kā top informācijas sistēmas I<br />

Kā top informācijas sistēmas<br />

Ivars Solovjovs, DatorPasaule 12 '99<br />

Īss ieskats informācijas sistēmu izstrādes projektu ikdienā<br />

Projekti un to vadība<br />

Droši var apgalvot, ka projekti un to vadība pastāv jau kopš civilizācijas<br />

pirmsākumiem. Vai tā būtu ēģiptiešu piramīdas celtniecība, vai romiešu kara<br />

kampaņas organizēšana, visos šajos gadījumos cilvēks ir risinājis problēmu, kā <strong>no</strong><br />

izejas situācijas A <strong>no</strong>kļūt vēlamajā situācijā B. Gadsimtu gaitā šī pieredze ir<br />

pilnveidojusies un 20. gadsimtā kļuvusi <strong>par</strong> zinātnisku disciplīnu un vienu <strong>no</strong> vadības<br />

zinātņu stūrakmeņiem. Projekts ir uzskatāms <strong>par</strong> citu dimensiju tradicionālajam<br />

veidam, kā tiek veiktas aktivitātes kādā organizācijā. Ja ilglaicīgi un vienveidīgi<br />

tipveida darbi tiek pildīti statisku, funkcionālu struktūrvienību ietvaros, tad<br />

vienreizēja netipiska uzdevuma izpilde tiek organizēta un vadīta kā projekts, tā<br />

izpildei uz laiku apvie<strong>no</strong>jot dažādu struktūrvienību resursus vie<strong>no</strong>tā projekta grupā,<br />

lai sasniegtu konkrētus projekta mērķus. Jauna veida produkcijas ražošanas<br />

uzsākšanu, uzņēmuma struktūras izmaiņu vai jaunas datorsistēmas ieviešanu uzskata<br />

<strong>par</strong> tipiskām aktivitātēm, kuras ir organizējamas kā projekti.<br />

IT projekti un programminženierija<br />

Jaunas informācijas sistēmas (IS) izveide organizācijā bieži vien ir saistīta ar<br />

kardinālām izmaiņām pašā organizācijā un tās biznesa procesos, tāpēc sekmīga IS<br />

izveide nav iespējama bez projektu vadības metožu izmantošanas, kuras, bagātinātas<br />

ar specifisko IT projektu pieredzi, radīja jaunu disciplīnu, kas kopš 70. gadu sākuma ir<br />

pazīstama kā programminženierija (software engineering). Par spīti zinātnieku un<br />

praktiķu pūliņiem, kā arī uzkrātai pieredzei šajā jomā, "sudraba lode" līdz šim tā arī<br />

vēl nav atrasta un centieni pilnveidot IS un programmatūras izstrādes metodes<br />

joprojām turpinās. Taču ir izkristalizējušies virkne principu un paņēmienu, bez kuriem<br />

sekmīga IS izstrādes projektu realizācija nav iespējama.<br />

Amatnieciskā un rūpnieciskā IS izstrāde<br />

Datoru un citu informācijas teh<strong>no</strong>loģiju pieejamība, kā arī bieži kultivētais mīts <strong>par</strong><br />

programmēšanu kā mākslu rada ilūziju, ka IS izstrāde ir vienkārša un īpašus vadīšanas<br />

pūliņus neprasa, jo ir pašregulējoša aktivitāte. IS izveide atbilstoši šim priekšstatam<br />

līdzinātos, teiksim, tam, kā tiek remontēts dzīvoklis, kad palīdz krāsotājs Pēteris, kurš,<br />

kā jau kārtīgs amatnieks, <strong>no</strong> pusvārda saprot jūsu aptuvenās vēlmes un ātri, bez

jebkādām formalitātēm izkrāso jūsu dzīvokli vēlamajā krāsā. Gadījumā, ja neiznāks,<br />

kā vajag, viņš pārkrāsos, jo gan jau jūs kaut kā vie<strong>no</strong>sities. Ļaunākajā gadījumā, ja<br />

bieži rodas vēlēšanās mainīt krāsu, var pieņemt viņu pie sevis darbā, lai būtu visu<br />

laiku pie rokas. Šo piemēru var uzskatīt <strong>par</strong> tipiski amatniecisku pieeju, kura šajā<br />

situācijā ir absolūti dabiska un eko<strong>no</strong>miski gandrīz vai vienīgi iespējamā. Pavisam<br />

cita situācija ir, ja mēs apskatām, piemēram, debesskrāpja vai tilta būvniecību, kur bez<br />

izsmeļoša eko<strong>no</strong>miskā pamatojuma, precīza projekta, tāmes, apakšuzņēmēju<br />

iesaistīšanas un citu it kā birokrātisku procedūru ievērošanas sekmīgs rezultāts<br />

vienkārši nav iespējams. Šāda mēroga un <strong>no</strong>zīmes objektu būvniecībā tiek izmantotas<br />

industriālas metodes, kuras būtiski atšķiras <strong>no</strong> amatnieciskajām.<br />

Tieši tāpat ir ar informācijas sistēmu izstrādi, jo var izmantot abas pieejas – gan<br />

amatniecisko (ja ir runa <strong>par</strong> vienkāršu programmiņu, ar kuru tiktu galā viens cilvēks<br />

divās nedēļās), gan arī rūpnieciskās (industriālās) IS izstrādes metodes (ja tiek<br />

izstrādāta valstiskas <strong>no</strong>zīmes vai uzņēmuma kritisku funkciju <strong>no</strong>droši<strong>no</strong>ša sistēma,<br />

kurā tiek iesaistīti 10 un vairāk cilvēku). Runājot līdzībās, jāsaka, ka galvenais ir<br />

nemēģināt būvēt debesskrāpi, paļaujoties tikai uz amatnieku zelta rokām.<br />

Kāpēc IS izstrādē ir nepieciešami standarti<br />

Kā jau tika minēts, IS izstrādes projekti ļoti bieži ir lieli, un tādos nevar iztikt bez<br />

lielāku uzdevumu sadalīšanas sīkākos, to veikšanu uzticot daudziem izpildītājiem un<br />

pēc tam integrējot atsevišķi iegūtos rezultātus. Nav iespējams šos projektus īste<strong>no</strong>t arī<br />

bez koordinācijas <strong>no</strong>drošināšanas starp atsevišķiem apakšprojektiem, plānu izpildes<br />

gaitas uzraudzības un plānu precizēšanas, bez dažādu ražotāju IT produktu<br />

izmantošanas utt. Normāla sadarbība starp projektā iesaistītajiem dalībniekiem nevar<br />

<strong>no</strong>tikt, ja tie nebalstās uz vie<strong>no</strong>tiem metodoloģiskiem un teh<strong>no</strong>loģiskiem principiem.<br />

Šo iemeslu dēļ, kā jau jebkurā industrializētā <strong>no</strong>zarē, standartu ievērošana kļūst <strong>par</strong><br />

priekš<strong>no</strong>sacījumu, kaut arī ne garantiju veiksmīgam rezultātam. Kā galve<strong>no</strong>s IS<br />

izstrādes procesu reglamentējošos standartus var minēt šādus:<br />

• ISO 9000 grupas standarti, kas <strong>no</strong>saka vispārējos organizācijas darbības principus<br />

un sakārtotību (ieskaitot arī ISO 9000-3 standartu, kurš reglamentē ISO 9000<br />

standartu lietošanu programmatūras izstrādē);<br />

• Standartu kopa, ko veido gan ISO, gan IEEE standarti, kas reglamentē informācijas<br />

sistēmas dzīves ciklu, projekta procesus un to savstarpējo saistību, starpproduktu<br />

<strong>no</strong>menklatūru, saturu un formu (programminženierijas standarti);<br />

Katrai organizācijai jāpiemēro standarti konkrētām vajadzībām, kuru ietvaros<br />

atbilstoši standartu <strong>no</strong>stādnēm ir jādefinē konkrētos apstākļos nepieciešamie procesi,<br />

aktivitātes, attiecīgo dokumentu konkrēts saturs un forma, kā arī vadlīnijas standartu<br />

izmantošanai organizācijā.<br />

Ar ko sākas IS izstrādes projekts<br />

IT izmantošana organizācijā un IS izstrāde nav pašmērķis, bet tikai līdzeklis<br />

(instruments) konkrētu biznesa mērķu sasniegšanai, tāpēc IS izstrāde ir uzskatāma <strong>par</strong><br />

uzņēmuma (vai organizācijas) darbības uzlabošanas procesa sastāvdaļu.<br />

Pirms IS izveides sākuma, uzņēmumam ir jātiek skaidrībā, kādi ir organizācijas<br />

biznesa mērķi, kas un kā ir jāpārveido uzņēmumā, lai tos sasniegtu, kādas ir tās<br />

funkcijas, kuru atbalstam nepieciešams izmantot IT, kāda ir IS izveides un<br />

darbināšanas stratēģija (IS izveide pašu spēkiem vai produktu un pakalpojumu<br />

iepirkšana <strong>no</strong> ārpuses). Parasti šie jautājumi tiek atspoguļoti stratēģiskas dabas<br />

dokumentā (tā <strong>no</strong>saukums varētu būt, piemēram, "Informācijas sistēmas stratēģiskais<br />

plāns"), kas tiek akceptēts visaugstākajā vadības līmenī. Šīs stratēģiskās plā<strong>no</strong>šanas

aktivitātes attiecas ne tik daudz uz IS izstrādi, bet gan uz organizācijas biznesa<br />

procesa sakārtošanu, tāpēc konkrētu standartu, kas reglamentētu šo procesu, nav.<br />

IS izstrādes dzīves cikls<br />

Tāpat kā dzīva būtne, arī IS netop vienā mirklī, un tai ir savs dzīves cikls, kas tiek<br />

aprakstīts ar dzīves cikla modeli. Jau kopš 70. gadu sākuma <strong>par</strong> klasiskām sistēmas<br />

izstrādes dzīves cikla (system development life cycle –SDLC) sastāvdaļām tiek<br />

uzskatītas šādas fāzes (sk.1. zīm.):<br />

• Prasības (sistēmu analīze, prasību specificēšana) –<br />

tiek apzinātas, izanalizētas un dokumentētas prasības (visdažādākās: sākot ar<br />

funkcionālajām un beidzot ar tehniskajām), kurām izstrādājamai IS ir jāatbilst;<br />

• Projektēšana – atbilstoši prasībām tiek projektēta sistēmas iekšējā uzbūve;<br />

• Kodēšana un vienību testēšana – atbilstoši projektētajam tiek izstrādāta (kodēta)<br />

programmatūra un veikta atsevišķu sistēmas sastāvdaļu (moduļu) auto<strong>no</strong>ma testēšana;<br />

• Sistēmas integrācija – atsevišķās sistēmas daļas un komponenti tiek apvie<strong>no</strong>ti vienā<br />

strādājošā sistēmā, kas pēc attiecīgas pārbaudes tiek palaista ražošanā;<br />

• Darbināšana un uzturēšana – regulārs darbs ar sistēmu, kā arī sistēmas modificēšana<br />

atbilstoši prasībām, kas <strong>par</strong>ādās jau tās darbināšanas laikā;<br />

Tas ir tā saucamais vienkāršais (once-trough) ūdenskrituma modelis (waterfall), kas<br />

<strong>par</strong>edz lineāru atsevišķu fāžu secību. Katrā fāzē ir definēti konkrēti mērķi un<br />

aktivitātes, kā arī rezultāti, kurus izmanto nākamajā fāzē. Lai gan pastāv variācijas<br />

attiecībā uz fāžu <strong>no</strong>saukumiem, kā arī atsevišķas fāzes dažkārt tiek dalītas vēl sīkāk,<br />

konkrētais modelis ir uzskatāms <strong>par</strong> klasisku.<br />

Pamatprincipi, uz kuriem balstās ūdenskrituma modelis, ir šādi:<br />

• Pirms projekta uzsākšanas, tas ir rūpīgi jāizplā<strong>no</strong>;<br />

• Jādefinē sistēmas ārējā uzvedība (atribūti), pirms uzsāk sistēmas iekšējās uzbūves<br />

konstruēšanu;<br />

• Jādokumentē katras aktivitātes rezultāti;<br />

• Pirms sistēmas kodēšanas (programmēšanas) tā ir jāprojektē;<br />

• Pēc sistēmas uzbūvēšanas tā ir jātestē.<br />

IS izstrādes dzīves cikla modeļa paveidi<br />

Ūdenskrituma modeļa (klasiskajā variantā) galvenais trūkums – pirms sistēmas<br />

izstrādes uzsākšanas ir jābūt precīzi definētām izstrādājamās sistēmas prasībām.<br />

Ņemot vērā to, ka sistēmas mēdz būt lielas un sarežģītas, kā arī risku, kas ir saistīts ar<br />

nepilnīgi definētām prasībām, praksē bieži vien tiek piemēroti <strong>no</strong> konkrētā modeļa<br />

atvasināti varianti.<br />

Viena iespēja, kā mazināt risku, ir izstrādāt sistēmu pa daļām. Tas ir inkrementālais

modelis (sk. 2. zīm.).<br />

Izstrādes scenārijs, atbilstoši kuram pēc pirmā būvējuma uz tā darbināšanas pieredzes<br />

pamata tiek papildinātas (precizētas) sistēmas prasības, ir evolucionārais modelis (sk.<br />

3. zīm.).<br />

Ņemot vērā moder<strong>no</strong> programmatūras rīku iespējas, dažkārt ir lietderīgi pirms<br />

izstrādes sākuma uzbūvēt sistēmas vienkāršotu prototipu, uz kura pamata tiek<br />

definētas izstrādājamās sistēmas prasības. Tas ir prototipēšanas modelis (sk. 4. zīm.).<br />

IS izstrādes dzīves cikla modeļu galve<strong>no</strong> iezīmju salīdzinājums.

Izstrādes stratēģija (modelis)<br />

Vai vispirms<br />

definē visas<br />

prasības<br />

Vai ir vairāki<br />

izstrādes cikli<br />

Vai tiek izplatīti<br />

(darbināti)<br />

starpbūvējumi<br />

Vienkāršā (once- trough) Jā Nē Nē<br />

Inkrementālā Jā Jā Iespējams<br />

Evolucionārā Nē Jā Jā<br />

Bez minētajiem vēl ir pazīstams spirāles modelis, kas attēlo sistēmas izstrādes procesu<br />

kā iteratīvu ciklu (spirāli), kurš sastāv <strong>no</strong> mērķa uzstādīšanas, risinājuma izvēles un<br />

alternatīvu analīzes, izstrādes, rezultātu salīdzināšanas ar sākotnējo uzdevumu, kā arī<br />

jauna mērķa uzstādīšanas utt.<br />

Lai gan visi šie modeļi savā būtībā nav pretrunīgi un viens otru papildina, tomēr viens<br />

<strong>no</strong> galvenajiem projekta lēmumiem ir izvēlēties konkrētai situācijai piemērotāko<br />

izstrādes stratēģiju. Noteikti būtu jāņem vērā tādi faktori kā problēmas sarežģītība, cik<br />

viegli ir definējamas prasības, prasību izmaiņu varbūtība, cik ātri nepieciešama pirmā<br />

(daļēja) sistēmas funkcionalitāte, finansu iespējas, izstrādei nepieciešamie<br />

cilvēkresursu ierobežojumi un citi faktori.<br />

Mazai sistēmai, kuras visu funkcionalitāti ir iespējams izstrādāt vienā paņēmienā (vai<br />

arī nav jēdzīga/iespējama daļas funkciju realizācija), visdrīzāk derēs vienkāršais vai<br />

prototipa modelis (ja puses atrod <strong>par</strong> ērtāku prasības definēt uz "fiziski aptaustāma"<br />

prototipa pamata). Savukārt lielas sistēmas, kā likums, tiek realizētas vairākās<br />

iterācijās (resursu ierobežojumu dēļ, kā arī lai mazinātu risku un papildu izdevumus,<br />

kas saistīti ar pārlieku liela projekta vadīšanu). Vissaprātīgākais šādā gadījumā ir katrā<br />

nākamajā iterācijā koriģēt/papildināt prasības atbilstoši iepriekšējās iterācijas<br />

rezultātiem (evolucionārais modelis). Taču bieži tiek piemērots arī inkrementālais<br />

scenārijs, kad prasības tiek iesaldētas jau izstrādes sākumā un pēc tam vairākās kārtās<br />

realizētas (ja prasības ir pietiekami stabilas un detalizētas un ir<br />

nepieciešama/iespējama daļas funkciju ātrāka realizācija, kā arī izstrāde tiek<br />

organizēta kā atsevišķs fiksētas cenas kontrakts uz detalizēta prasību specifikācijas<br />

dokumenta pamata).<br />

3.1. <strong>Konspekts</strong><br />

Sistēmas modelēšana

<strong>Izmantoti</strong>e materiāli: Roger S. Pressman, Chapter 10. Sistēmas inženierija. lpp.235-<br />

248<br />

Plāns:<br />

• Sistēmas modelēšana<br />

• Uzņēmuma modelēšana<br />

• Biznesa līmeņa datu modelēšana<br />

• Procesu modelēšana<br />

• Informācijas plūsmas modelēšana<br />

• Sistēmas arhitektūras modelēšana<br />

Sistēmas modelēšana<br />

Sistēmu izstrāde ir modelēšanas process. Neatkarīgi <strong>no</strong> tā, vai uzmanība tiek pievērsta<br />

pasaules redzējumam, vai detalizētākam redzējuma, inženieris izstrādā modeli, kurš:<br />

definē procesus, kuri apmierina šī redzējuma vajadzības;<br />

reprezentē procesu uzvedību un pieņēmumus, uz kuriem balstās procesu uzvedība;<br />

skaidri definē modeļa ieejas informāciju - eksogē<strong>no</strong> un endogē<strong>no</strong> ievadu;<br />

reprezentē visus savie<strong>no</strong>jumus, ieskaitot izvadus, kuri <strong>no</strong>drošinās inženiera labāko<br />

problēmas sfēras redzējumu.<br />

Lai uzbūvētu sistēmas modeli, inženierim ir jāņem vērā vairāki svarīgi faktori:<br />

1. Pieņēmumi, kuri samazina iespējamo permutāciju un variāciju skaitu, tādā veidā<br />

<strong>no</strong>droši<strong>no</strong>t modeļa iespēju adekvāti reaģēt uz problēmu.<br />

2. Vienkāršošana <strong>no</strong>drošina modeļa ātrāku izstrādi.<br />

3. Ierobežojumi, kuri palīdz identificēt būvējamās sistēmas robežas.<br />

4. Teh<strong>no</strong>loģiskie ierobežojumi, kuri <strong>no</strong>saka vadlīnijas būvējamās sistēmas modeļa<br />

realizācijai un implementēšanai.<br />

5. Preferences, kuras <strong>no</strong>saka vēlamo arhitektūras īpašības gan datiem, gan funkcijām,<br />

gan teh<strong>no</strong>loģijām.<br />

Uzņēmuma modelēšana<br />

Veicot uzņēmuma modelēšanu, inženieri izstrādā trīsdimensiju skatījumu uz<br />

uzņēmuma biznesu. Pirmā dimensija pārvalda organizācijas struktūru un funkcijas,<br />

kuras tiek veiktas dotajās organizācijas struktūrās. Otrā dimensija palīdz atdalīt<br />

biznesa funkcijas <strong>no</strong> tām, kuras palīdz biznesa funkcijām eksistēt un realizēties.<br />

Visbeidzot trešā dimensija organizācijai un tās funkcijām pievie<strong>no</strong> mērķus un<br />

kritiskus veiksmes faktorus. Papildus tam, uzņēmuma modelēšanas procesā tiek<br />

izveidots biznesa līmeņa datu modelis, kurš definē datu objektus un to saistību ar<br />

citiem elementiem uzņēmuma modelī.<br />

Biznesa organizācija <strong>par</strong>asti tiek definēta kā klasiska biznesa vienību hierarhija (skat.<br />

Attēlu 1). Katra diagrammas aile raksturo organizācijas biznesa darbības sfēru.<br />

Protams, šo hierarhisko attēlu var detalizēt līdz pat mazām izstrādes komandām vai<br />

pat atsevišķiem darbiniekiem, taču modelēšanas mērķiem tas nav vajadzīgs.<br />

Tālāk tiek identificētas biznesa funkcijas un atbilstošie procesi, nepieciešami šo<br />

biznesa funkciju realizācijai. Biznesa funkciju definē kā biznesa sfēras nepieciešamo<br />

<strong>no</strong>tiekošu aktivitāti. Biznesa funkciju <strong>par</strong>asti raksturo lietvārds. Biznesa procesam,<br />

savukārt, ir ieejas informācija, kuru pārveidojot tiek iegūta izejas informācija. Biznesa<br />

procesu <strong>par</strong>asti raksturo darbības vārds.

Attēls 1. Organizācijas hierarhiskā struktūra un to funkcijas.<br />

Biznesa līmeņa datu modelēšana<br />

Biznesa līmeņa datu modelēšana ir uzņēmuma modelēšana aktivitāte, kurā galvenā<br />

uzmanība tiek pievērsta datu objektiem (tā saucamajām entītēm), kuri ir nepieciešami<br />

biznesa funkcijas mērķu sasniegšanai. Biznesa līmenī tipiskie datu objekti iekļauj<br />

informācijas sniedzējus un informācijas patērētājus (piemēram, klients), lietas<br />

(piemēram, pārskati, atskaites), <strong>no</strong>tikumus (piemēram, konference), organizācijas<br />

lomas (piemēram, vice-prezidents), organizācijas vienības (piemēram, pārdošanas un<br />

mārketinga de<strong>par</strong>taments), vietas (piemēram, rūpnīca) vai informācijas struktūras<br />

(piemēram, darbinieku datne). Datu objektam ir virkne atribūtu, kuri raksturo tā<br />

kvalitāti, raksturojumu vai datus, kurus objekts satur.<br />

Piemēram, aplūkosim datu objekta piemēru - Klients. Lai detalizēti aprakstītu klientu,<br />

izmantosim šādus atribūtus:<br />

______________________<br />

Objekts: Klients<br />

Atribūti:<br />

Vārds<br />

Organizācijas <strong>no</strong>saukums<br />

Amats<br />

Interesējošie produkti<br />

Pirkumu/pasūtījumu vēsture<br />

Pēdējā kontakta datums<br />

Kontakta statuss<br />

Kad ir skaidri datu objekti, tiek identificētas to savstarpējas attiecības. Attiecības<br />

identificē veidu, kā objekti sadarbojas viens ar otru. Piemēram, ir identificēti objekti<br />

Klients, Produkts A un Pārdevējs. Inženieris veido diagrammu, lai attēlotu šo objektu<br />

savstarpējas attiecības. Parasti attiecības var būt lasītas gan <strong>no</strong> viena objekta puses,

gan <strong>no</strong> otra objekta puses. Piemēram, Klients kontaktējas ar Pārdevēju, vai Pārdevējs<br />

palīdz Klientam.<br />

Attēls 2. Biznesa līmeņa datu objektu attiecības<br />

Un visbeidzot ir svarīgi sastādīt griezskaņa (cross-relation) matricu, kurā tiktu<br />

uzskaitītas visas savastarpējas attiecības starp organizāciju un tās biznesa sfērām,<br />

biznesa mērķiem, biznesa funkcijām un procesiem, kā arī datu objektiem.<br />

Procesu modelēšana<br />

Darbs, kurš tiek veikts kādā organizācijā satur virkni biznesa funkciju, kurus <strong>no</strong>formē<br />

kā biznesprocesus.<br />

Izskatīsim procesu modelēšanu uz pārdošanas funkcijas piemēra. Pārdošana satur<br />

vairākus procesus:<br />

- Nodibināt kontaktu ar klientu;<br />

- Nodrošināt literatūru un citu informāciju <strong>par</strong> produktu;<br />

- Atbildēt uz interesējošiem jautājumiem;<br />

- Nodrošināt produktu;<br />

- Pieņemt pircēja pasūtījumu;<br />

- Pārbaudīt pasūtījuma pieejamību;<br />

- Sagatavot piegādi;<br />

- Saskaņot ar pasūtītāju pasūtījuma konfigurāciju, apmaksas un piegādes veidu;<br />

- Pārsūtīt pasūtījumu <strong>par</strong> izpildi atbildīgajam de<strong>par</strong>tamentam;<br />

- Turpināt sarunu ar klientu.<br />

Šai procesa plūsmai var izveidot šādu procesa plūsmas diagrammu (skat. Attēls 3.)

Attēls 3. Procesa plūsmas modelis pārdošanas funkcijai.<br />

Datu plūsmas modelēšana<br />

Datu plūsmas modelis tiek integrēts ar Procesu plūsmas modeli, lai attēlotu kādā<br />

veidā informācija ceļo līdz biznesprocesiem. Katram procesam tiek attēlota ieejas un<br />

izejas informācija, attēlojot informācijas pārveidošanas plūsmu kamēr tiek izpildīta<br />

kāda biznesa funkcija. Datu plūsmas piemēru skat. Attēlā 4.<br />

Attēls 4. Datu plūsmas pievie<strong>no</strong>šana procesa plūsmas modelim.<br />

Kad procesa un datu plūsmas modeļi ir izstrādāti, inženieris, sekojot biznesa procesu<br />

izpildei, mēģina identificēt iespēju optimizēt kādu posmu, ieejas un izejas<br />

informāciju, piemeklējot piemērotāko teh<strong>no</strong>loģisko vai organizatorisko risinājumu.<br />

Uz šo modeļu bāzes vēlāk tek izstrādāta būvējamās sistēmas prasību specifikācija.<br />

Sistēmas arhitektūras modelēšana<br />

Katra sistēmas var būt modelēta kā informācijas pārveidošanas arhitektūra: "ievadsapstrāde-izvads".<br />

Sistēmas modeļa izstrādē tiek izmantota arhitektūras sagatave.<br />

Inženieris uzskaita visus arhitektūras elementus sekojošās grupās: 1) lietotāju

saskarnes; 2) ievadi; 3) sistēmas funkcija un kontroles mehānismi; 4) izvads; 5)<br />

sistēmas uzturēšana un paštesti. Arhitektūras sagataves forma ir redzama attēlā 5.<br />

Attēls 5. Arhitektūras sagataves forma.<br />

Tāpat kā pārējās modelēšanas tehnikas, arhitektūras sagataves ļauj analītiķim pielietot<br />

detalizācijas hierarhiju. Arhitektūras konteksta diagrammas (ACD) atrodas hierarhijā<br />

pašā augšā. Konteksta diagramma <strong>no</strong>sprauž robežas starp sistēmu un sistēmas<br />

ekspluatācijas vidi. Proti, arhitektūras konteksta diagramma definē visus sistēmas<br />

ārējos informācijas piegādātājus un izmantotājus, kā arī visas entītes, kuras sadarbojas<br />

ar ārējiem datu failiem, izmantojot interfeisus.<br />

Piemērā ir attēlota konveijera līnijas sortēšanas sistēma (skat. attēlu 6).<br />

Attēlos 6. Konveijera līnijas sortēšanas sistēmas arhitektūras konteksta diagramma..<br />

Vēlāk inženieris detalizē arhitektūras konteksta diagrammu, identificējot zem katras<br />

kantainas ailes apakšsistēmas, kuras <strong>no</strong>drošina sistēmas funkcionēšanu.<br />

Apakšsistēmas var attēlot arhitektūras plūsmas diagrammā (AFD), kurš balstās uz<br />

arhitektūras konteksta diagrammu (skat. attēlu 7).

Attēls 7. Arhitektūras plūsmas diagramma (AFD).<br />

Pirmā arhitektūras plūsmas diagramma kļūst <strong>par</strong> augšējo virsotni kokā, kura lapas ir<br />

kantainas ailes, kuras, ejot arvien dziļāk, iegūst arvien lielāku detalizācijas pakāpi. Šis<br />

process ir redzams attēlā 8.<br />

Attēls 8. Arhitektūras plūsmas diagrammas hierarhija

3.2. Datu plūsmu diagrammas piemērs<br />

Datu plūsmu diagrammas piemērs<br />

Izmantots kursa projekts: "Personāla darba uzdevumu uzskaites sistēma" R. Zviedris;<br />

M. Vārpa.<br />

Arthur Andersen<br />

vadība<br />

Klients<br />

4.1. <strong>Konspekts</strong><br />

Dati <strong>par</strong> izmaiņām<br />

kompānijās, grupās<br />

un klasifikācijās<br />

Dati <strong>par</strong><br />

meklējamo<br />

personu<br />

ER - diagrammas<br />

Personāla<br />

vadītājs<br />

Dati <strong>par</strong><br />

darbinieku<br />

Darbinieks<br />

Dati <strong>par</strong><br />

prombūtni<br />

Sekretāre<br />

Dati <strong>par</strong><br />

izmaiņām<br />

kompānijās<br />

Kompānijas<br />

Dati <strong>par</strong><br />

darbinieku<br />

Dati <strong>par</strong><br />

darbinieku<br />

Dati <strong>par</strong><br />

prombūtni<br />

Dati <strong>par</strong><br />

Dati <strong>par</strong> "meklētāju"<br />

prombūtni<br />

Apzīmējumi<br />

Dati <strong>par</strong><br />

izmaiņām<br />

grupās<br />

Grupas<br />

Dati<br />

<strong>par</strong><br />

izmaiņām<br />

klasfikācijās<br />

Klasifikācijas<br />

Dati <strong>par</strong><br />

kompānijām<br />

Dati <strong>par</strong><br />

grupām<br />

Personālās<br />

informācijas<br />

redaktors<br />

Dati <strong>par</strong><br />

klasifikācijām<br />

Jauns<br />

ieraksts<br />

Atrašanās<br />

vietas<br />

redaktors<br />

Jauns<br />

ieraksts<br />

Entītija - klase, vienveidīgu objektu kopums. Datubāzē tas pārvērtīsies <strong>par</strong> vienu<br />

tabulu. Nosaukumā lieto lietvārdu.<br />

Piemēri.<br />

Personālā<br />

Personas: klients, darbinieks, students, pasniedzējs. informācija<br />

Atrašanās vietas<br />

informācija<br />

Vietas: universitāte, auditorija, viesnīca, restorāns.<br />

Objekti: grāmata, mašīna, produkts, programmatūras Klasificēta licence, programmatūras<br />

Klasificēta<br />

rīks.<br />

informācija<br />

informācija<br />

Notikumi: apbalvošana, pieņemšana darbā, atlaišana <strong>no</strong> darba, ceļojums.<br />

Entītijas instance ir viena entītijas <strong>par</strong>ādīšanās, piemēram, entītijas Students instance<br />

var būt Austris Ozoliņš.<br />

Personālās<br />

informācijas<br />

apskats<br />

Atrašanās vietu<br />

informācijas<br />

apskats<br />

Elektronisko<br />

ziņu<br />

redaktors<br />

Jauns<br />

ieraksts<br />

Darbinieka<br />

e-pastkaste<br />

Informācija <strong>par</strong> darbienieku<br />

Informācija <strong>par</strong> darbinieka atrašanās vietu<br />

Grāmatvedība<br />

Personāla<br />

vadītājs<br />

Sekretāre<br />

Klients

1. attēls. Entītija Students un tās instances tabulārajā reprezentācijā.<br />

Atribūts ir entītijas raksturojošs elements vai aprakstoša īpašība. Atribūta si<strong>no</strong>nīmi -<br />

elements, īpašība un lauks. Piemēram, Studentam var būt vārds, uzvārds, matu krāsa,<br />

svars u.tml.<br />

Saliktais atribūts ir tāds atribūts, kurš satur citus atribūtus.<br />

Atribūts, kurš atšķir kopas elementus ir galvenā atslēga (primary key), piemēram,<br />

studentus atšķir Studenta apliecības numurs, kurš visiem studentiem ir unikāls. Tā<br />

vietā varētu lietot arī Personas kodu, bet studentiem <strong>no</strong> dažādām valstīm tie būs<br />

dažāda garuma un izskata.<br />

Kandidātatslēga ir viena <strong>no</strong> vairākām atslēgām, kuras var kalpot kā galvenā atslēga (ir<br />

unikāla katrai entītijas instancei).<br />

Alternatīva atslēga ir kandidātatslēga, kura netiek izvēlēta kā galvenā atslēga.<br />

Si<strong>no</strong>nīms - sekundārā atslēga.<br />

Asociatīva entītija ir entītija, kura manto savu galve<strong>no</strong> atslēgu <strong>no</strong> vairāk nekā vienas<br />

citas entītijas (kurus sauc <strong>par</strong> vecākiem (<strong>par</strong>ents)).<br />

Datu tips ir atribūta īpašība, kura identificē to datu tipu, kurus saturēs atribūts.<br />

Attiecība (relācija) - dabiska asociācija starp dažādām entītijām. Attiecība var<br />

reprezentēt <strong>no</strong>tikumu vai citu atbilstību, kura sasaista entītijas. Piemēram, Studenta un<br />

Mācību programmas attiecība - students mācās pēc mācību programmas, savukārt<br />

mācību programmai reģistrē vienu vai vairākus studentus.<br />

2. attēls. Attiecības piemērs.<br />

Attiecības mēdz būt dažāda veida, atkarībā <strong>no</strong> sasaistīto entītiju skaita. Modalitāte -<br />

minimālais instanču <strong>par</strong>ādīšanās skaits, kardinalitāte - maksimālais instanču<br />

<strong>par</strong>ādīšanās skaits.<br />

Nosaukums<br />

Modalitāte Kardinalitāte Grafiskā attēlošana<br />

Tieši viens 1 1

Nulle vai viens 0 1<br />

Viens vai vairāk 1 n (>1)<br />

Nulle, viens vai<br />

vairāk<br />

0 n (>1)<br />

Vairāk <strong>par</strong> vienu n n<br />

ER modeļu realizācija ar tabulām<br />

Tabulu kolonas atbilst atribūtiem. Rindiņu skaits nav ierobežots.<br />

Mācību priekšmets<br />

Kods Nosaukums ...<br />

Y1<br />

Programmēšana<br />

Y2<br />

Diskrētā matemātika<br />

Y3<br />

Projektu vadība<br />

...<br />

...<br />

Mācību priekšmeta galvenā atslēga ir Kods.<br />

Pasniedzējs<br />

Personas kods Vārds Uzvārds ...<br />

PK1- Juris Borzovs<br />

PK2- Jānis Bičevskis<br />

PK3- Guntis Arnicāns<br />

...<br />

Pasniedzēja galvenā atslēga ir Personas kods.<br />

Students<br />

Personas kods Vārds Uzvārds Studiju programma ...<br />

PK1- Juris Bērziņš Datorzinātņu bakalaurs<br />

PK2- Aivis Ozoliņš Programmētājs<br />

PK3- Ieva Liepiņa Datorzinātņu bakalaurs<br />

...<br />

Studenta galvenā atslēga ir personas kods.<br />

Priekšmets - Students<br />

Priekšmets Students Reģistrēšanas datums ...<br />

Y1 PK1 7.IX.03<br />

Y2 PK2 2.II.04<br />

Y3 PK3 5.IX.03<br />

...

Priekšmeta-Studenta tabulā tiek lietotas 2 ārējās atslēgas (foreign key) - mācību<br />

priekšmeta kods un studenta personas kods.<br />

Priekšmets - Pasniedzējs<br />

Priekšmets Pasniedzējs Semestris Kvalitāte ...<br />

Y1 PK1 II ļoti laba<br />

Y2 PK2 III ļoti laba<br />

Y3 PK3 III ļoti laba<br />

...<br />

Ja IS pašos pamatos ieliek neveiksmīgu datu modeli, var sanākt pārtaisīt visu <strong>no</strong><br />

sākuma.<br />

Konceptuālajā modelī var būt m:n attiecības. Realizācijas modelē vairs m:n nav, tur<br />

vēl ir arī kodējumi.<br />

3. attēls. Piemērs.<br />

Datu modelēšanas fāzes.<br />

1. Konceptuālais datu modelis<br />

- lai <strong>no</strong>teiktu projekta sfēru<br />

2. Uz atslēgām balstītais datu modelis<br />

- likvidē nespecifiskas attiecības<br />

- pievie<strong>no</strong> asociatīvas entītijas<br />

- iekļauj galvenās un alternatīvas atslēgas<br />

- precizē kardinalitātes<br />

3. Pilnīgi izskaidrojams datu modelis<br />

- iekļauti visi atlikušie atribūti<br />

- apakškopu veidošanas kritēriju izvēle<br />

4. Normalizēts modelis<br />

4.2. ER modeļa piemērs I<br />

ER modeļa piemērs<br />

Izmantots kursa projekts: "Datu mobilā uzskaite" A. Maruškins; D. Seluto.

Atras mediciniskas palidzibas<br />

automasinu apkalpošanas<br />

bazes<br />

Atras mediciniskas palidzibas<br />

bazes<br />

Pilseta<br />

Atras mediciniskas palidzibas<br />

masinas<br />

Atras mediciniskas palidzibas<br />

personals<br />

Iela<br />

Pasta indekss<br />

Pacienta arstejosais arsts<br />

Apdrosinasanas<br />

kompanijas<br />

Atras mediciniskas<br />

palidzibas izsauksanas<br />

apmaksasanas tarifs<br />

Darba laika aprakstisana<br />

Mediciniskie instrumenti<br />

Izsauktais arsts<br />

Pacienti<br />

Hroniskas<br />

saslimsanas<br />

Starpgadijumi<br />

Kardiologiskas<br />

saslimsanas<br />

Pulmo<strong>no</strong>logiskas<br />

saslimsanas<br />

Nevrologiskas<br />

saslimsanas<br />

Travmotologiskas<br />

saslimsanas<br />

Manipulacijas<br />

EKG defekti<br />

Atras mediciniskas palidzibas<br />

arsta pizimes<br />

Pacienta <strong>par</strong>vesana<br />

Medikamenti<br />

4.3. ER modeļa piemērs II<br />

ER modeļa piemērs<br />

Izmantots kursa projekts: "Personāla darba uzdevumu uzskaites sistēma" R. Zviedris;<br />

M. Vārpa.

4.4. Entītes un atribūti<br />

Entītes un atribūti. Piemērs.<br />

Izmantots kursa projekts: "Datu mobilā uzskaite" A. Maruškins; D. Seluto.<br />

Ātrās medicīniskās<br />

palīdzībās automašīnu<br />

bāzes<br />

1) IDN<br />

2) Ātrās<br />

medicīniskās palīdzības<br />

automašīnu bāzes<br />

identifikācijas numurs<br />

Ātrās medicīniskās<br />

palīdzības bāzes<br />

1) IDN<br />

2) Ātrās<br />

medicīniskās palīdzības<br />

bāzes identifikācijas

numurs<br />

3) Ātrās<br />

medicīniskās palīdzības<br />

bāzes <strong>no</strong>daļas<br />

identifikācijas numurs<br />

Ātrās medicīniskās<br />

palīdzības mašīnas<br />

1) IDN<br />

2) Ātrās<br />

medicīniskās palīdzības<br />

bāzes IDN<br />

3) Mašīnās valsts<br />

numurs<br />

4) Mašīnās<br />

kilometrāže<br />

Ātrās medicīniskās<br />

palīdzības personāls<br />

1) IDN<br />

2) Ātrās<br />

medicīniskās palīdzības<br />

ārsta identifikācijas<br />

numurs<br />

3) Ātrās<br />

medicīniskās palīdzības<br />

medmāsas<br />

identifikācijas numurs<br />

4) Ātrās<br />

medicīniskās palīdzības<br />

vādītāja identifikācijas<br />

numurs<br />

5) Ātrās<br />

medicīniskās palīdzības<br />

bāzes IDN<br />

Darba laika aprakstīšāna<br />

1) IDN<br />

2) Ātrās<br />

medicīniskās palīdzības<br />

pesonāla IDN<br />

3) Ātrās<br />

medicīniskās palīdzības<br />

bāzes IDN<br />

4) Ātrās<br />

medicīniskās palīdzības<br />

mašīnas IDN<br />

5) Darba sakuma

laiks<br />

6) Darba beigas laiks<br />

7) Mašīnas<br />

kilometrāzē darba dienas<br />

sakumā un beigā<br />

Pilsēta<br />

1) IDN<br />

2) Nosaukums<br />

Iela<br />

1) IDN<br />

2) Nosaukums<br />

Pasta indekss<br />

1) IDN<br />

2) Indekss<br />

Apdrošināšanas<br />

kompānijas<br />

1) IDN<br />

2) Nosaukums<br />

3) Identifikācijas<br />

numurs<br />

4) Pilsēta IDN<br />

5) Iela IDN<br />

6) Pasta indeks IDN<br />

7) Adresa<br />

precizēšana<br />

Ātrās medicīniskās<br />

palīdzībās izsaukšanās<br />

apmaksāšanās tarifs<br />

1) IDN<br />

2) Izsauktais ārsts<br />

IDN<br />

3) Tarifa veids<br />

Pacienta ārstējošais ārsts<br />

1) IDN<br />

2) Vārds, uzvārds<br />

3) Identifikācijas<br />

numurs<br />

Izsauktāis ārsts<br />

1) IDN<br />

2) Ārsta tips<br />

3) Ārsta veids

Pacienti<br />

1) IDN<br />

2) Vārds<br />

3) Uzvārds<br />

4) Dzimšanas<br />

datums<br />

5) Vecums<br />

6) Pilsēta IDN<br />

7) Iela IDN<br />

8) Pasta indeks IDN<br />

9) Adresa<br />

precizēšana<br />

10) Dzimums<br />

11) Apdrošināšanas<br />

kompānijas IDN<br />

12) Apdrošināšanas<br />

aģenta (Aa) vārds<br />

13) Aa uzvārds<br />

14) Aa dzimšanas data<br />

15) Aa pilsēta IDN<br />

16) Aa iela IDN<br />

17) Aa pasta indekss<br />

IDN<br />

18) Aa adresa<br />

precizēšana<br />

19) Darba devēja (Dd)<br />

pilsēta IDN<br />

20) Dd iela IDN<br />

21) Dd pasta indekss<br />

IDN<br />

22) Dd adresa<br />

precizēšana<br />

23) Darba dienas<br />

identifikācijas numurs<br />

24) Ātrās medicīniskās<br />

palīdzības mašīnas<br />

izsaukšanas laiks un<br />

datums<br />

25) Ātrās medicīniskās<br />

palīdzības mašīnas<br />

izbraukšanas laiks un<br />

datums<br />

26) Ātrās medicīniskās<br />

palīdzības mašīnas<br />

atbraukšanas laiks un<br />

datums<br />

27) Ātrās medicīniskās<br />

palīdzības mašīnas<br />

aizbraukšanas laiks un<br />

datums

28) Ātrās medicīniskās<br />

palīdzības mašīnas<br />

tiekoša kilometrāža<br />

vertība<br />

29) Darba laika<br />

aprakstīšanas IDN<br />

30) Pirma starpposmu<br />

pieturas (Psp) pilsētas<br />

IDN<br />

31) Psp ielas IDN<br />

32) Psp pasta indeksa<br />

IDN<br />

33) Psp adresa<br />

precizēšana<br />

34) Otra starpposmu<br />

pietura (Osp) pilsētas<br />

IDN<br />

35) Osp ielas IDN<br />

36) Osp pasta indeksa<br />

IDN<br />

37) Osp adresa<br />

precizēšana<br />

38) Treša starpposmu<br />

pietura (Tsp) pilsētas<br />

IDN<br />

39) Tsp ielas IDN<br />

40) Tsp pasta indeksa<br />

IDN<br />

41) Tsp adresa<br />

precizēšana<br />

42) Ātrās medicīniskās<br />

palīdzības izsaukšanās<br />

apmaksāšanās tatrifs<br />

IDN<br />

Medikamenti<br />

1) IDN<br />

2) Grupa<br />

3) Nosaukums<br />

4) Ievada veids<br />

5) Laiks<br />

6) Pacients IDN<br />

Mediciniskie<br />

instrumenti<br />

1) IDN<br />

2) Grupa<br />

3) Nosaukums<br />

4) Ievada veids<br />

5) Laiks

6) Pacients IDN<br />

Manipulācijas<br />

1) IDN<br />

2) Veids<br />

3) Rezultāts<br />

4) Rezultātu grafiks<br />

5) Pacients IDN<br />

Starpgadijumi<br />

1) IDN<br />

2) Nosaukums<br />

3) Laiks<br />

4) Izpausmju veids<br />

5) Pacients IDN<br />

Pacienta <strong>par</strong>vēšana<br />

1) IDN<br />

2) Apmaksāšanas<br />

veids<br />

3) Steidzums<br />

4) Reanimācijas<br />

veids<br />

5) Pīrma<br />

medicīniska palidzība<br />

6) Parvēšanas<br />

veids<br />

7) Pacienta<br />

stavoklis arvēšanas laikā<br />

8) Pacients IDN<br />

EKG defekti<br />

1) IDN<br />

2) Nosaukumi<br />

3) Pacients IDN<br />

Hroniskās saslimšanas<br />

1) IDN<br />

2) Grupa<br />

3) Nosaukums<br />

4) Pacients IDN<br />

Kardioloģiskās<br />

saslimšanas<br />

1) IDN<br />

2) Nosaukums<br />

3) Pacients IDN<br />

Pulmo<strong>no</strong>loģiskās<br />

saslimšanas

1) IDN<br />

2) Nosaukums<br />

3) Pacients<br />

IDN<br />

Travmotoloģiskās<br />

saslimšanas<br />

1) IDN<br />

2) Nosaukums<br />

3) Sarežgetība<br />

4) Izvietojums<br />

5) Pacients IDN<br />

Nevroloģiskas<br />

saslimšanas<br />

1) IDN<br />

2) Grupa<br />

3) Nosaukums<br />

4) Pacients IDN<br />

5.1. <strong>Konspekts</strong><br />

Modelēšanas rīki<br />

Valdis Vītoliņš, e-pasaule 9 '2003<br />

Ir grūti iedomāties biznesa jomu, kurā varētu kaut ko paveikt bez iepriekšējas<br />

plā<strong>no</strong>šanas un analīzes. Tāpēc tiek izstrādāti dažādi modelēšanas rīki, kas atvieglo<br />

dažādu biznesa jomu modelēšanu.<br />

Var pieņemt, ka rīks atbalsta biznesa modelēšanu, ja:<br />

iespējams grafiskā veidā attēlot, kāds ir uzņēmums un kādas darbības tiek veiktas;<br />

dažādos veidos var attēlot arī uzņēmuma resursus, darbības kvalitāti, apkārtni, un jau<br />

ir metodika un/vai šabloni šo aspektu modelēšanai;<br />

uzņēmuma darbību var virtuāli simulēt un pat attēlot kā animāciju (vēlams).<br />

Šāda veida rīki veido <strong>no</strong>sacītu spektru <strong>no</strong> biznesa modelēšanas līdz programmatūras<br />

izstrādei. Biznesa modelēšanas rīkos lielāka uzmanība tiek pievērsta dažādu biznesa<br />

aspektu attēlošanai, metodikai, procesu simulācijai, kā arī vairāki rīki piedāvā savu<br />

metodiku biznesa analīzē. Metodikas atbilst Deminga/ISO vai Balanced Scorecard<br />

kvalitātes pārvaldības procesam, Portera Value Added Chain vai ir pilnīgi atšķirīgas<br />

kā Zahmana metodika (Zachman framework) un ARIS metodiku kompilācija.<br />

Diemžēl šīs metodikas ir zināmā mērā <strong>no</strong>vecojušas, jo slikti atbilst mūsdienās<br />

izplatītajai biznesa transakciju pieejai (B2B un Web servisu izstrādē) un<br />

objektorientēto/sadalīto sistēmu izstrādei.<br />

Programmatūras izstrādes rīki atbalsta modelēšanas valodu Unified Modeling<br />

Language 2.0 (UML) (izņemot Timing diagrammu), kā arī veic programmatūras koda<br />

ģenerēšanu, reinženieriju (koda analīzi) un/vai koda sinhronizēšanu ar modeli. Tā kā<br />

programmatūras kodu klasiski ģenerē tikai <strong>no</strong> klašu diagrammām, citas diagrammas<br />

biznesa modelēšanā kalpo tikai aprakstam.

Pirms izmantot kādu rīku, jāizlemj, vai tas tiks lietots tikai biznesa cilvēku<br />

vajadzībām (uzņēmuma modelēšanai, darbības, kvalitātes, izmaksu un citu aspektu<br />

analīzei) vai arī "tehnisko" darbinieku vajadzībām - programmu izstrādei un<br />

ieviešanai.<br />

Microsoft Visio Professional 2002, Visual Studio .NET Enterprise Architect<br />

Visio ir rīks, kura spēcīgās grafiskās iespējas, pēc Microsoft pārņemšanas, ir<br />

papildinātas ar programmatūras izstrādes un modelēšanas iespējām. Šajā rīkā vairāk ir<br />

attīstītas programmatūras izstrādes iespējas. Biznesa modelēšanai to var izmantot,<br />

lietojot tā UML redaktora iespējas. Rīks ļauj veidot visas praksē izmantotās UML<br />

diagrammas, <strong>no</strong> kurām biznesa modelēšanā vērtīgākās ir klašu un aktivitāšu<br />

diagrammas. Visual Studio .NET Enterprise Architect ir tikai plašākas<br />

programmatūras koda pārvaldības iespējas.<br />

1. attēls. Microsoft Visio Professional 2002<br />

Popkin Software System Architect 8.8<br />

Tas ir "spilgts" biznesa modelēšanas rīks, kas piedāvā īpašu Zahmana metodiku<br />

modeļu izveidē. Šajā metodikā tiek piedāvāts problēmu apskatīt <strong>no</strong> dažādiem<br />

aspektiem un dažādos līmeņos, iegūstot tabulu (divdimensiju matricu):<br />

Diemžēl šī metodika nesasaucas ar objektorientētu un sadalītu sistēmu izstrādi, jo tika<br />

izstrādāta vēl pirms šādas izstrādes izgudrošanas. Rīks ļauj veidot visas izplatītākās<br />

UML diagrammas un piedāvā savas modelēšanas valodas - IDEF0 (ir līdzība ar UML<br />

Use Case) un IFEF3 (UML Activity Diagram). Šīs modelēšanas valodas ir labi<br />

formalizētas, tāpēc IDEF3 (un Process Chart) ļauj arī simulēt un animēt procesus, kas<br />

būtiski palīdz procesu pārveidē un analīzē.<br />

2. attēls. Popkin Software System Architect ar Zahmana piedāvāto modelēšanas<br />

metodiku (pa kreisi) un ar IDEF3 procesa diagrammu (pa labi)<br />

Rational Rose 2002 Modeler Edition<br />

Jaunākā versija gan ir Rose 2003, bet nekas, izņemot XP veida grafisko saskarni, tajā<br />

nav savādāks. Izplatītākais modelēšanas rīks ASV un arī pasaulē. UML standarta<br />

diagrammas tiek zīmētas, lietojot šo rīku. Pārsvars tirgū gan vairāk ir iegūts ar<br />

mārketingu, jo kā grafikas redaktors rīks ir vājš un lielas diagrammas zīmēt ir grūti<br />

(pēc <strong>no</strong>klusēšanas līnijas netiek veidotas tais<strong>no</strong>s leņķos, bet gan slīpi pa īsāko ceļu).

Šis rīks ļauj veidot praktiski visas UML diagrammas, kā arī ģenerēt programmas<br />

kodu. Rational Rose 2002 Modeler Edition neļauj <strong>no</strong> koda ģenerēt (vai sinhronizēt ar)<br />

diagrammu. Biznesa modelēšanai tas <strong>no</strong>der tikai kā konstruktors, un nekādas gatavas<br />

papildu iespējas (piemēram, Org diagrammai, biznesa apkārtnes aprakstīšanai,<br />

simulācijai) nepiedāvā.<br />

S<strong>par</strong>x Systems Enterprise Architect 3.51<br />

Rīks, kas ļauj veidot izplatītākās UML diagrammas un papildus vēl piedāvā savu<br />

pieeju biznesa modelēšanā. Biznesa modelēšanai piedāvā īpašu metodiku (atbilst<br />

Deminga/ISO procesu pārvaldībai un Portera Value Added Chain), bet nepiedāvā<br />

procesu simulāciju. Kā izstrādes rīks <strong>no</strong>drošina arī koda ģenerēšanu un<br />

sinhronizēšanu ar diagrammu. Grafikas redaktors līdzīgs Rational Rose. S<strong>par</strong>x<br />

Systems Enterprise Architect 3.51 ir viskompaktākais <strong>no</strong> visiem testētajiem rīkiem<br />

(programmas kataloga izmērs 17 MB!).<br />

3. attēls. S<strong>par</strong>x Systems Enterprise Architect 3.51.<br />

Casewise Corporate Modeler 8e<br />

Jaudīgs biznesa modelēšanas rīku komplekts, kas tomēr ne<strong>no</strong>drošina sasaisti ar<br />

programmu izstrādi. Līdzīgi kā System Architect, modelēšanā atbalsta Zahmana<br />

metodiku. Simulēto procesu analīzes metodika atbilst Balanced Scorecard. Šajā rīkā<br />

iespējams dažādos skatos (diagrammās) vairākkārt izmantot tos pašus projekta<br />

objektus (items), un īpašā matricā tiek <strong>par</strong>ādītas konkrētās izmantošanas vietas. Tas<br />

ļauj simulēt un animēt Process Dynamic diagrammas. Rīks neļauj uzreiz zīmēt UML<br />

diagrammas, bet var izveidot savus šablonus. (Šādām diagrammām netiks veikta<br />

UML loģikas analīze, kas neļauj zīmēt nekorekti.) Rīks <strong>no</strong>drošina Dynamics un Data<br />

Flow diagrammu konvertēšanu uz/<strong>no</strong> Rose Use Case diagrammām (saglabājot<br />

topoloģiju) un Dynamics diagrammu uz/<strong>no</strong> Visio blokshēmām (pat saglabājot<br />

grafisko izvietojumu!).<br />

QPR Software Plc QPR ProcessGuide 7.0, Infologistik GRADE 4.0 un IDS Sheer<br />

Aris 6.1<br />

QPR ProcessGuide 7.0 ir biznesa modelēšanas rīks, kas piedāvā savu īpašu biznesa<br />

modelēšanas metodiku. Biznesa process tiek apskatīts kā Portera Value Added Chain,<br />

procesu (kvalitātes) pārvaldībā tiek izmantots Balanced Scorecard cikls. Rīkam ir<br />

sava modelēšanas valoda, kas ir pietiekami elastīga lai tajā iekļautu arī dažādus<br />

neformālus elementus (zīmējumus), bet arī pietiekami formāla, lai ļautu izveidoto<br />

procesu simulēt. Pēc simulācijas tiek piedāvāta dažādu datu analīze un attēlošana<br />

grafikos. Rīks <strong>no</strong>der tikai analīzei, jo programmatūras izstrādei tas nav <strong>par</strong>edzēts.

4. attēls. QPR Software Plc QPR ProcessQuide 7.0.<br />

GRADE 4.0 ir labākā cenas/jaudas attiecība, turklāt ar to var veidot patiesi lielas<br />

diagrammas. Šis rīks nepiedāvā īpašu metodiku, bet pilnībā var izmantot biznesa<br />

modelēšanai (ir arī organizatoriskā diagramma). Tas ir ar vecmodīgu Windows 3.1<br />

saskarni un neatbalsta UML 2.0 diagrammas (rīka izstrādes laikā tika izstrādāta UML<br />

1.3).<br />

IDS Cheer Aris 6.1 piedāvā īpašu metodiku kompilāciju (Value Added Chain,<br />

Deminga/ISO pārvaldības ciklu, Score Card), kā arī lielu diagrammu klāstu. Procesu<br />

simulācija iespējama eEPC diagrammām, un tiek izmantota activity-based cost<br />

metodika. Tas palīdz veidot dažādus skatījumus uz organizāciju un tās procesiem, bet<br />

slikti sasaucas ar programmatūras izstrādes <strong>par</strong>adigmām. To varētu izmantot biznesa<br />

cilvēki, bet zināmas problēmas būtu šo rīku lietot gan biznesa procesu aprakstīšanai,<br />

gan to <strong>no</strong>drošināšanai, iztrādājot pārvaldības sistēmas. Vadoties pēc palīdzības (help),<br />

UML klašu diagrammu praktiski izveidot neizdevās.<br />

Citi rīki<br />

Vienā rakstā nav iespējams vispusīgi aplūkot visus vadošos biznesa modelēšanas<br />

rīkus. Tāpēc šajā numurā tika apskatīt Latvijā pieejamākie un pazīstamākie rīki.<br />

Gartnera grupas sagatavotu vadošo biznesa modelēšanas rīku apskatu var izlasīt<br />

http://www.gartner.com/gc/webletter/idsscheer/issue1/article1.html (pētījumu<br />

pasūtījusi IDS Scheer).<br />

5.2. GRADE diagrammu piemēri<br />

GRADE diagrammu piemēri<br />

GRADE diagrammu piemēri atrodami -<br />

http://www.gradetools.com/grade40/examples.htm<br />

Workstation example

UML: class diagram

UML: use case diagram

UML: state diagram

GRADE: business process diagram<br />

Legend:<br />

Round rectangles - tasks (pieces of job)<br />

Arrows - events (messages)<br />

Hexagons - decisions<br />

Clocks - timers

GRADE: organization structure diagram<br />

Legend:<br />

Rectangles - organization units<br />

Round rectangles - positions<br />

Lined round rectangles - resources

GRADE: communicating objects diagram<br />

Top level diagram. Ministry of Planning and its environment

GRADE: process diagram (flowchart)<br />

Legend:<br />

Cyan - receive a message<br />

Gray - perform a simple action<br />

Yellow - take a decision<br />

Magenta - send a message<br />

Green - perform a procedure

GRADE: entity-relationship diagram<br />

You can generate database initialization scripts from these diagrams.<br />

GRADE: data type diagram<br />

Example #1

5.3. Procesu aprakstīšanas programmas<br />

Procesu aprakstīšanas programmas<br />

Juris Nazarenko, E-pasaule<br />

Publikācijā aplūkotas programmas, kuru būtiskākā funkcija ir aprakstīt biznesa<br />

procesus. Vispirms ir jāsaprot procesu aprakstīšanas būtība un pēc tam var <strong>no</strong>vērtēt un<br />

salīdzināt vairākas programmas. Rakstā nav apskatīti jautājumi, kuri ir saistīti ar<br />

procesu orientāciju (process orientation) reālā uzņēmumā, bet gan aplūkota šādas<br />

programmatūras <strong>no</strong>zīme un specifiskās īpašības.<br />

Procesa orientācijas būtība<br />

Modernajā eko<strong>no</strong>mikā ļoti liela uzmanība tiek<br />

veltīta klienta vajadzību apmierināšanai. Tas<br />

<strong>no</strong>zīmē, ka <strong>par</strong> katra uzņēmuma galve<strong>no</strong><br />

uzdevumu kļūst nevis produkta vai<br />

pakalpojuma ražošana, bet gan to pārdošana<br />

klientam. Taču, uzņēmumam paplaši<strong>no</strong>ties, tā<br />

vadība un darbinieki dažādu iemeslu dēļ sāk<br />

atšķirīgi skatīties uz vienām un tām pašām<br />

lietām un diezgan bieži klientam vairs<br />

nepiedāvā to, ko viņš vēlas. Šāda dīvaina<br />

situācija attēlota attēla augšējā daļā.<br />

Procesu orientācija<br />

Šādā situācijā vislabākis glābējlīdzeklis<br />

procesu orientācija. Tas <strong>no</strong>zīmē, ka ar programmas palīdzību tiek atspoguļota<br />

sadarbība ar klientu, sākot <strong>no</strong> pirmās sarunas vai tikšanās līdz brīdim, kad klients<br />

saņem pasūtīto preci un <strong>no</strong>rēķinās <strong>par</strong> to. Šī situācija atspoguļota attēla apakšējā daļā.<br />

Ir skaidri redzams, ka visi uzņēmuma darbinieki vienādi saprot procesa <strong>no</strong>risi un savu<br />

vietu šajā procesā.<br />

Taču vienmēr nepieciešams <strong>no</strong>vērtēt un salīdzināt izmantojamās programmas.<br />

GRADE Modeler 4.0<br />

(www.gradetools.com)<br />

Latvijas produkts, kuru izstrādāja Latvijas Universitātes speciālisti. Viens <strong>no</strong><br />

raksturīgākajiem šīs programmas vērtējumiem - tai ir ļoti plašas iespējas. Lietojot šo<br />

programmu, var ļoti detalizēti dokumentēt procesu, <strong>no</strong>teikt katrai darbībai izpildītājus,<br />

veikt procesa simulāciju ("palaist" procesu reālā laikā) un analizēt procesu <strong>no</strong><br />

dažādiem viedokļiem. Piemēram, var <strong>no</strong>teikt, cik ilgs būs viena produkta pārdošanas<br />

process, kādas ir viena procesa izmaksas, kā arī iespējams <strong>no</strong>teikt procesa vājās vietas<br />

un piedāvāt risinājumu situācijas uzlabošanai. Bez tam pastāv iespēja veikt dažādu<br />

datu eksportu un importu izmantojot atšķirīgus formātus (txt, ODBC). Kā<br />

priekšrocību var minēt to, ka aprakstīto procesu var publicēt intranetā jeb html<br />

formātā.<br />

Vēl viena šīs programmas priekšrocība ir tā, ka tai ir ļoti zema cena - ap Ls 300. Bet<br />

tas ne<strong>no</strong>zīmē, ka programmai ir kaut kādas nepilnības, jo tā tiešām piedāvā ļoti plašas<br />

iespējas.<br />

Taču jāatzīmē arī šīs programmas divi galvenie trūkumi:<br />

• Pirmkārt, procesa aprakstīšanas laikā veidojas <strong>no</strong> biznesa viedokļa nepārskatāms<br />

gala attēls. Tas <strong>no</strong>zīmē, ka tad, ja ir vēlme izprast procesa <strong>no</strong>risi, to var izdarīt, bet

emocionāli (!) tas ir diezgan grūti, jo <strong>no</strong> tīri vizuālā viedokļa<br />

attēls nav pārāk pievilcīgs.<br />

• Otrkārt, šīs programmas lietošana ir sarežģīta - lai izmantotu<br />

kaut nelielu daļu <strong>no</strong> programmas iespējām, ir diezgan daudz<br />

laika jāvelta speciālistu apmācībai. Šī iemesla dēļ pat Latvijas<br />

Universitātes datorzinību maģistranti nevar sekmīgi izveidot<br />

maģistra darbu ar šīs programmas palīdzību.<br />

Secinājums - GRADE Modeler 4.0 lietot reālajā biznesā ir<br />

diezgan apgrūti<strong>no</strong>ši, jo tā nerisina biznesa problēmas.<br />

Vācu kompānijas IDS Scheer programmu kopums ARIS<br />

(www.ids-scheer.com)<br />

IDS Scheer specializējas komplekso vadības risinājumu ieviešanā dažādu <strong>no</strong>zaru<br />

uzņēmumos. Ir atsevišķas programmas procesu aprakstīšanai, procesu simulēšanai,<br />

ABC metodoloģijas ieviešanai, sabalansētu vadības rādītāju pārvaldībai, kā arī<br />

atsevišķa programma procesu publicēšanai intranetā jeb html formātā.<br />

Protams, būtiskākā <strong>no</strong>zīme produktu <strong>no</strong>menklatūrā ir procesu aprakstīšanas rīkam<br />

ARIS Toolset. Salīdzinājumā ar iepriekš aprakstīto produktu GRADE Modeler 4.0,<br />

ARIS Toolset ir ievērojami mazāk iespēju, tāpēc, lietojot šo programmu, arī iespējams<br />

paveikt krietni mazāk. Vācu kompānija šajā programmā ir atstājusi tikai reālam<br />

biznesam nepieciešamās iespējas - procesa aprakstīšanu.<br />

Kā būtisku šīs programmas priekšrocību var minēt to, ka ar iebūvētas<br />

programmēšanas valodas palīdzību <strong>no</strong> attēlotā procesa ir iespējams izdrukāt amata<br />

instrukciju katram darbiniekam, kas piedalās procesā. Turklāt šī instrukcija tiek<br />

izveidota literārā latviešu valodā.<br />

Programmas cena ir ap 3 000 ASV dolāru.<br />

ARIS Toolset būtiskākie trūkumi ir līdzīgi iepriekšminētās programmas trūkumiem:<br />

• Procesa attēlojums ir pasmags, bet tomēr ievērojami pievilcīgāks nekā ar<br />

programmu GRADE Modeler 4.0 iegūtais procesa attēlojums.<br />

• Lai strādātu ar šo programmu, ir nepieciešams iepazīties ar procesa dokumentēšanas<br />

<strong>no</strong>teikumiem, jo pretējā gadījumā <strong>no</strong>dokumentētu procesu nevarēs simulēt.<br />

QPR ProcessGuide<br />

(www.qpr.com)<br />

Kā trešo <strong>no</strong> šāda veida programmām var<br />

apskatīt somu kompānijas QPR Software Plc.<br />

produktu QPR ProcessGuide (www.qpr.com).<br />

Arī šī kompānija piedāvā kompleksos<br />

risinājumus vadības metožu ieviešanai. Ir<br />

atsevišķas programmas gan procesu<br />

aprakstīšanai, gan ABC metodoloģijas<br />

ieviešanai, gan sabalansēto vadības rādītāju<br />

metodoloģijas ieviešanai, gan arī daudzas<br />

citas vadības programmas.<br />

Salīdzinājumā ar abām iepriekšminētajām<br />

programmām procesu dokumentēšanas programmu QPR ProcessGuide var raksturot<br />

savādāk:<br />

1) Šai programmai ir ļoti maz iespēju, jo tā ir domāta procesu dokumentēšanai un<br />

simulēšanai, tāpēc iemācīties strādāt ar to ir ļoti viegli. (Es personīgi sapratu visas<br />

programmas iespējas, <strong>no</strong>skatoties 15 minūšu garu videofilmu, kas ir pieejama QPR<br />

mājas lapā Internetā.)<br />

2) Procesa attēlojums ir ļoti pievilcīgs <strong>no</strong> lietotāja viedokļa, kā arī vizuāli uz to ir

patīkami skatīties.<br />

3) Pēc <strong>no</strong>klusēšanas procesu publicēšana <strong>no</strong>tiek intranetā vai html formātā. Tas<br />

<strong>no</strong>zīmē, ka firmas darbinieki pārlūko procesu ar standarta Interneta pārlūkprogrammu<br />

(Internet Explorer).<br />

Ņemot vērā visu jau minēto, var teikt, ka šī programma palīdz risināt tikai biznesa<br />

vajadzības. Tas <strong>no</strong>zīmē, ka ar dokumentētiem procesiem var strādāt jebkurš firmas<br />

darbinieks neatkarīgi <strong>no</strong> viņa zināšanu līmeņa. Turklāt neviena <strong>no</strong> iepriekšminētajām<br />

programmām ne<strong>no</strong>drošina iespēju izveidot tik vienkāršu un pārskatāmu attēlu. Bez<br />

tam programma QPR ProcessGuide piedāvā datu importēšanas un eksportēšanas<br />

iespējas.<br />

Taču arī šai programmai ir savs trūkums - tā ir dārgāka <strong>par</strong> visām iepriekšminētajām,<br />

jo maksā 5 000 ASV dolāru.<br />

Secinājums<br />

Apkopojot informāciju <strong>par</strong> procesu aprakstīšanas programmu tirgu, var teikt, ka ir ap<br />

1 400 procesu dokumentēšanas programmu, tāpēc ir iespējams izvēlēties sev<br />

visērtāko, izdevīgāko vai pat patīkamāko procesu dokumentēšanas programmu. Šīs<br />

programmas pārsvarā atšķiras :<br />

• ar procesa attēlošanas veidu;<br />

• ar papildu programmēšanas iespējām;<br />

• ar iespējām publicēt informāciju intranetā vai html formātā.<br />

6.1. <strong>Konspekts</strong><br />

Sistēmas objektu funkcionēšanas apraksti<br />

MS <strong>no</strong> izvēlēm un formām. Kodu ģenerē automātiski.<br />

Konceptuālais modelis -> realizācijas modelis (kur atrisinātas m:n saites)<br />

Eksistē translatori <strong>no</strong> modeļa <strong>par</strong> DB (piemēram, Rational Rose)<br />

Strukturēta angļu valoda var kalpot <strong>par</strong> algoritma aprakstu<br />

Programmēšanas valoda, ar komentāriem, atkāpēm u.tml. nav viegli uztverams.<br />

Uzskata, ka 4. paaudzes programmēšanas valodas jau ir labi uztveramas.<br />

C ir stipri līdzīgs Asemblerim, uzskatāmība zema.<br />

Blokshēma<br />

1. attēls. Blokshēmas elementi (pa kreisi) un piemērs (pa labi)..<br />

Shēmas atšķiras pēc sarežģītības. Shēmas, kuras sastāv <strong>no</strong> 3-9 elementiem ir<br />

vienkāršas. Lai shēmas būtu viegli lasāmas, tās ieteicams veidot dažādos detalizācijas<br />

līmeņos. Piemēram, 1.attēla shēmā darbības "Ieraksta apstrāde" detalizētu shēmu<br />

varētu iznest atsevišķā shēmā. Cits piemērs var būt datu apstrāde atšķirībā <strong>no</strong><br />

ievadītas vērtības (sk. 2. attēlu). Piemērā attēlota shēma, kurā atkarībā <strong>no</strong> kursa<br />

vērtībām tiek izpildītas dažādas darbības. Šajā gadījumā darbību detalizēti apraksti arī<br />

var būt iznesti atsevišķās shēmās.<br />

2. attēls. Kursa dažādu vērtību apstrāde.<br />

Strukturālā programmēšana<br />

Strukturālā programmēšanā atļautas tikai <strong>no</strong>teiktas konstrukcijas. Blokam ir viena<br />

ieeja un viena izeja. C valoda ir nestrukturāla, visi asembleri ir nestrukturāli.<br />

Strukturalitāte ne vienmēr <strong>no</strong>zīmē arī saprotamību.<br />

Stāvokļu pāreju diagramma (SPD)

Stāvoklis ir intuitīvs jēdziens. Tā ir atribūtu, vērtību kopa, kas raksturo sistēmas<br />

uzvedību.<br />

Students - imatrikuēts, pārcelts 2. kursā, ...<br />

Datora stāvokļi - ieslēgts, izslēgts, sabojāts, ...<br />

Tātad, šie stāvokļi ir skats <strong>no</strong> funkcionēšanas viedokļa.<br />

Operatīvās atmiņas stāvokļi - cits skats. 2 256MB ir praktiska bezgalība, ar tik<br />

daudziem stāvokļiem nevar tikt galā.<br />

Sistēma → automāts (neliels stāvokļu skaits, definētas stāvokļu pārejas).<br />

Tas var kalpot <strong>par</strong> labu sistēmas aprakstu.<br />

3. attēls. Uzņemšana universitātē. Nedeterminēts automāts.<br />

Tabulārais STD pieraksts.<br />

Personas kods Vārds UzvārdsStāvoklis<br />

PK1 Jānis Osis 1<br />

... ... ... ...<br />

Viegli atlasīt, toties grūti uztaisīt saprātīgu SPD.<br />

7.1. <strong>Konspekts</strong><br />

Lietotāja saskarne

(<strong>no</strong><br />

http://members.tripod.com/~bazman/checklist.htmlbutton1=GUI+Testing+Checklist)<br />

Tēmas plāns<br />

Termi<strong>no</strong>loģija un vēsture<br />

Lietotāja saskarnes <strong>no</strong>vērtēšana<br />

Lietotāju orientēta saskarne programmproduktiem<br />

Lietotāju saskarnes pārbaudes jautājumu saraksts<br />

Termi<strong>no</strong>loģija un vēsture<br />

(<strong>Izmantoti</strong> materiāli <strong>no</strong> http://www.liis.lv/mspamati/ECDL/1modulis/e1040207.htm )<br />

Definīcija:<br />

lietotāja<br />

saskarne<br />

user interface; (lietotāja interefeis), Programmu un a<strong>par</strong>ātu kopums, kas<br />

<strong>no</strong>drošina informācijas apmaiņu starp lietotāju un datu apstrādes sistēmas<br />

a<strong>par</strong>atūras un programatūras komponentiem.<br />

Lietotāja saskarne (interfeiss) ir veids kādā lietotājs var mijiedarboties ar datoru.<br />

Pirmajos IBM PC lietoja Disku Operētājsistēmu Sistēmu - DOS, kura izmantoja<br />

rakstzīmju orientētu lietotāja saskarni (lietotājs instrukcijas ievadīja teksta veidā).<br />

Rakstzīmju orientēta lietotāja saskarne (Character User Interface - CUI) ir lietotāja<br />

saskarne, kas atšķirībā <strong>no</strong> grafiskās lietotāja saskarnes komandu ievadīšanai datorā<br />

<strong>par</strong>edz izmantot tastatūru. (TTC datubāze)<br />

Tā, piemēram, lai kopētu datni <strong>no</strong> disketes uz cieto disku, jā<strong>no</strong>rāda tās <strong>no</strong>saukums<br />

atrašanās vieta un dublikāta atrašanās vieta:<br />

Vēlāk vairākas firmas izstrādāja citas operētājsistēmas:<br />

firma Apple - operētājsistēmu Macinsosh System;<br />

firma IBM - operētājsistēmu OS/2;<br />

firma Microsoft - operētājsistēmu Windows.<br />

Šajās operētājsistēmās jau lietoja grafisko lietotāja saskarni.<br />

Grafiskā lietotāja saskarne ir (Graphical User Interface - GUI) ir displeja<br />

formatēšanas veids, kas ļauj lietotājam izvēlēties komandas, palaist programmas, kā<br />

arī apskatīt datņu sarakstus un citus objektus, <strong>no</strong>rādot to piktogrāfiskos attēlus<br />

(ikonas). Izvēli var izdarīt, izmantojot tastatūru vai peli. Grafiskā lietotāja saskarne<br />

piedāvā vidi, kas <strong>no</strong>drošina tiešu dialogu ar datoru. Grafisko lietotāja saskarni<br />

izmanto, piemēram, operētājsistēma Microsoft Windows. (TTC datubāze)<br />

GUI ir opererētājsistēmas papildu daļa, kas satur izvēlnes, <strong>no</strong>rādes rīkus, programmu<br />

logus, ikonas un citus grafiskus elementus, kas veicina efektīvāku datora lietošanu.<br />

GUI atvieglo lietotāja mijiedarbība ar datoru.<br />

Tā, piemēram, lai kopētu datni <strong>no</strong> disketes uz cieto disku, izvēlas disketi un datnes<br />

ikonu pārvelk uz dublikāta atrašanās vietu:

Programmu logi var saturēt dažādus vadības objektus, piemēram, rīkjoslas,<br />

komandkartes un citu tekstuālu vai grafisku informāciju. Lai lietotājs saskarni varētu<br />

pielāgot savām vajadzībām, šo objektu <strong>no</strong>vietojums, izmēri un forma var tikt mainīti.<br />

Lietotājs vienlaicīgi atvērt var vairāk kā vienas lietojumprogrammas logu un pēc tam<br />

viegli pāriet <strong>no</strong> vienas uz otru.<br />

Ieguvumi, lietojot GUI<br />

Sarežģītu instrukciju vienkāršošana, izmantojot ikonas un izvēlnes.<br />

Vieglāk organizēt darbu un pārvaldīt programmas un datnes.<br />

Visas programmas pēc izskata ir līdzīgas.<br />

Pārēja <strong>no</strong> vienas kādas ražotāja programmas uz cita ražotāja līdzīgu programmu ir<br />

vienkārša.<br />

Lietojumprogrammas darbojas līdzīgi datorā izmantotajai operētājsistēmai.<br />

Programmētāji var izveidot pēc izskata līdzīgas programmas.<br />

Lietotāja saskarnes <strong>no</strong>vērtēšana<br />

Lietotāja saskarni var <strong>no</strong>vērtēt pēc vairākiem principiem:<br />

cik ātri un ērti var iegūt vajadzīgo rezultātu<br />

iespēja intuitīvi (bez instrukciju lasīšanas) iegūt vajadzīgo rezultātu<br />

lietotā valoda, žargons, saprotamība, gramatiskas kļūdas<br />

ekrāna formu saprotamība<br />

programmas ātrdarbība<br />

programmas drošums pret lietotāja neloģiskām darbībām<br />

programmas spēja darboties daudzlietotāju režīmā<br />

krāsu un skaņas signālu izmantošana<br />

Izstrādājot lietotāju saskarni, kā svarīgākos var minēt sekojošus atribūtus:<br />

piemērotība uzdevumam (suitability for the task);<br />

pašaprakstāmība (self-descriptiveness);<br />

vadāmība (controllability);<br />

atbilstība lietotāja gaidītajam (conformity with user expectations);<br />

kļūdu piecietība (error tolerance);<br />

piemērotība individualizācijai (suitability for individualization);<br />

mācīšanās piemērotība (suitability for learning);

Lietotāju orientēta saskarne programmproduktiem<br />

(IBM stratēģijas Ease of Use)<br />

Lietotāju saskarnei ir jābūt orientētai. Šis faktors ir vitāli svarīgs ieviešot<br />

programmatūru. Ja lietotājiem programmatūras saskarne nav ērta, saprotama un<br />

vienkārši lietojama, tad, lai arī cik laba un kvalitatīva programmatūra nebūtu, to,<br />

iespējams, neviens neizmantos.<br />

Lai izstrādātu lietotāju orientētu saskarni, jāseko šādiem projektēšanas principi:<br />

- Nospraudiet biznesa mērķus. Nosakot mērķus un lietotāju cerības ir atslēga<br />

projektējuma uzsākšanai un lietotāju iesaistīšanai.<br />

- Saprotaties ar lietotājiem. Lietotāju iesaistīšana projektēšanas procesā ir viens <strong>no</strong><br />

galvenajiem veiksmes faktoriem. Ja jūs vēlaties, lai lietotājs saprastu jūsu<br />

programmproduktu, jums ir sākumā jāsaprot lietotājs.<br />

- Sasniedziet konkurētspēju. Pārākuma sasniegšanai nepieciešams uzturēt<br />

konkurētspējīgu produktu. Kad jūs esat sapratis lietotāju uzdevumus, jums ir jātestē<br />

šos uzdevumus pret citu konkurentu alternatīvām un salīdzināt viņu un savus<br />

rezultātus.<br />

- Projektējiet vispārējo lietotāju pieredzi. Viss, ko redz un kam pieskārās lietotājs, ir<br />

projektēts kopā ar daudzdisciplīnu komanda. Tas iekļauj veidu, kā produkts tiek<br />

reklamēts, pasūtīts, iegādāts, iepakots, instalēts, administrēts, dokumentēts, atkļūdots<br />

un uzturēts.<br />

- Novērtējiet projektējumu. Lietotāju atsauksmes tiek iegūtas savlaicīgi un bieži,<br />

lietojot programmatūras prototipus, tādējādi šīs atsauksmes var virzīt<br />

programmprodukta projektēšanu un izstrādi <strong>par</strong>eizajā virzienā.<br />

- Pārvaldiet lietotāju pastāvīgu <strong>no</strong>vērošanu. Produkta dzīves cikla laikā ir svarīgi<br />

<strong>no</strong>vērot un uzklausīt lietotājus, tādējādi iegūstot atsauksmes turpmākai<br />

programmprodukta uzlabošanai, panākot labākus rezultātus.<br />

Lietotāju saskarnes pārbaudes jautājumu saraksts<br />

(<strong>no</strong> http://www.csst-tech<strong>no</strong>logies.com/guichk.htm)<br />

Šis saraksts ir izveidots, balstoties uz kļūdām, atrastām grafiskajās lietotāju saskarnēs.<br />

Šo sarakstu var izmantot kā sākumu lietotāju saskarnes testēšanā un apskatēs.<br />

Assure that the start-up icon for the application under consideration is unique from all<br />

other current applications.<br />

Assure the presence of a control menu in each window and dialog box.<br />

Assure the correctness of the Multiple Document Interface (MDI) of each window -<br />

Only the <strong>par</strong>ent window should be modal (All child windows should be presented<br />

within the confines of the <strong>par</strong>ent window).<br />

Assure that all windows have a consistent look and feel.<br />

Assure that all dialog boxes have a consistent look and feel.<br />

Assure that the child widows can be cascaded or tiled within the <strong>par</strong>ent window.<br />

Assure that icons which represent minimized child windows can be arranged within<br />

the <strong>par</strong>ent window.<br />

Assure the existence of the "File" menu.<br />

Assure the existence of the "Help" menu.<br />

Assure the existence of a "Window" Menu.<br />

Assure the existence and proper location of any other menus which are logically<br />

required by the application.<br />

Assure that the proper commands and options are in each menu.<br />

Assure that all buttons on all tool bars have a corresponding menu commands.

Assure that each menu command has an alternative(hot-key) key sequence which will<br />

invoke it where appropriate.<br />

In "tabbed" dialog boxes, assure that the tab names are <strong>no</strong>t abbreviations.<br />

In "tabbed" dialog boxes, assure that the tabs can be accessed via appropriate hot key<br />

combinations.<br />

In "tabbed" dialoged boxes, assure that duplicate hot keys do <strong>no</strong>t exist<br />

Assure that tabs are placed horizontally across the top (avoid placing tabs vertically<br />

on the sides as this makes the names hard to read).<br />

Assure the proper usage of the escape key (which is to roll back any changes that have<br />

been made).<br />

Assure that the cancel button functions the same as the escape key.<br />

Assure that the Cancel button becomes a Close button when changes have be made<br />

that can<strong>no</strong>t be rolled back.<br />

Assure that only command buttons which are used by a <strong>par</strong>ticular window, or in a<br />

<strong>par</strong>ticular dialog box, are present.<br />

When a command button is used sometimes and <strong>no</strong>t at other times, assure that it is<br />

grayed out when it should <strong>no</strong>t be used.<br />

Assure that OK and Cancel buttons are grouped se<strong>par</strong>ately from other command<br />

buttons.<br />

Assure that command button names are <strong>no</strong>t abbreviations.<br />

Assure that command button names are <strong>no</strong>t technical labels, but rather are names<br />

meaningful to system users.<br />

Assure that command buttons are all of similar size and shape.<br />

Assure that each command button can be accessed via a hot key combination (except<br />

the OK and CANCEL buttons which do <strong>no</strong>t <strong>no</strong>rmally have hot keys).<br />

Assure that command buttons in the same window/dialog box do <strong>no</strong>t have duplicate<br />

hot keys.<br />

Assure that each window/dialog box has a clearly marked default value (command<br />

button, or other object) which is invoked when the Enter key is pressed.<br />

Assure that focus is set to an object which makes sense according to the function of<br />

the window/dialog box.<br />

Assure that option button (AKA radio button) names are <strong>no</strong>t abbreviations.<br />

Assure that option button names are <strong>no</strong>t technical labels, but rather are names<br />

meaningful to system users.<br />

If hot keys are used to access option buttons, assure that duplicate hot keys do <strong>no</strong>t<br />

exist in the same window/dialog box.<br />

Assure that option box names are <strong>no</strong>t abbreviations.<br />

Assure that option box names are <strong>no</strong>t technical labels, but rather are names<br />

meaningful to system users.<br />

If hot keys are used to access option boxes, assure that duplicate hot keys do <strong>no</strong>t exist<br />

in the same window/dialog box.<br />

Assure that option boxes, option buttons, and command buttons are logically grouped<br />

together in clearly demarcated areas.<br />

Assure that each demarcated area has a meaningful name that is <strong>no</strong>t an abbreviation.<br />

Assure that the Tab key sequence which traverses the defined areas does so in a<br />

logical way.<br />

Assure that the <strong>par</strong>ent window has a status bar.<br />

Assure that all user-related system messages are presented via the status bar.<br />

Assure consistency of mouse actions across windows.

Assure that the color red is <strong>no</strong>t used to highlight active GUI objects (many individuals<br />

are red-green color blind).<br />

Assure that the user will have control of the desktop with respect to general color and<br />

highlighting (the application should <strong>no</strong>t dictate the desktop background<br />

characteristics).<br />

Assure that the GUI does <strong>no</strong>t have a cluttered appearance (GUIs should <strong>no</strong>t be<br />

designed to look like a mainframe character user interfaces (CUIs) when replacing<br />

such data entry/retrieval screens)<br />

Lasiet vēl : http://hcibib.org/sam/ - Guidelines for design user interface software<br />

7.2. Lietotāja saskarnes testēšanas kontrolsaraksts<br />

Lietotāja saskarnes testēšanas kontrolsaraksts<br />

CONTENTS:<br />

Section 1 - Windows Compliance Standards<br />

<strong>1.1.</strong> Application<br />

1.2. For Each Window in the Application<br />

1.3. Text Boxes<br />

1.4. Option (Radio Buttons)<br />

1.5. Check Boxes<br />

1.6. Command Buttons<br />

1.7. Drop Down List Boxes<br />

1.8. Combo Boxes<br />

1.9. List Boxes<br />

Section 2 - Tester's Screen Validation Checklist<br />

2.1. Aesthetic Conditions<br />

2.2. Validation Conditions<br />

2.3. Navigation Conditions<br />

2.4. Usability Conditions<br />

2.5. Data Integrity Conditions<br />

2.6. Modes (Editable Read-only) Conditions<br />

2.7. General Conditions<br />

2.8. Specific Field Tests<br />

2.8.1. Date Field Checks<br />

2.8.2. Numeric Fields<br />

2.8.3. Alpha Field Checks<br />

Section 3 - Validation Testing - Standard Actions<br />

3.1. On every Screen<br />

3.2. Shortcut keys / Hot Keys<br />

3.3. Control Shortcut Keys<br />

Section 4 - Origin & Inspiration<br />

4.1. Document origin<br />

4.2. Sources of Inspiration & information<br />

4.3. Contacting the author.

Section 1 - Windows Compliance Testing<br />

<strong>1.1.</strong> Application<br />

Start Application by Double Clicking on its ICON. The Loading message should<br />

show the application name,<br />

version number, and a bigger pictorial representation of the icon (a 'splash' screen).<br />

No Login is necessary<br />

The main window of the application should have the same caption as the caption of<br />

the icon in Program Manager.<br />

Closing the application should result in an "Are you Sure" message box<br />

Attempt to start application Twice<br />

This should <strong>no</strong>t be allowed - you should be returned to main Window<br />

Try to start the application twice as it is loading.<br />

On each window, if the application is busy, then the hour glass should be displayed. If<br />

there is <strong>no</strong> hour glass<br />

(e.g. alpha access enquiries) then some enquiry in progress message should be<br />

displayed.<br />

All screens should have a Help button, F1 should work doing the same.<br />

1.2. For Each Window in the Application<br />

If Window has a Minimise Button, click it.<br />

Window Should return to an icon on the bottom of the screen<br />

This icon should correspond to the Original Icon under Program Manager.<br />

Double Click the Icon to return the Window to its original size.<br />

The window caption for every application should have the name of the application<br />

and the window name -<br />

especially the error messages. These should be checked for spelling, English and<br />

clarity , especially on the top<br />

of the screen. Check does the title of the window makes sense.<br />

If the screen has an Control menu, then use all ungreyed options. (see below)<br />

Check all text on window for Spelling/Tense and Grammar<br />

Use TAB to move focus around the Window. Use SHIFT+TAB to move focus<br />

backwards.<br />

Tab order should be left to right, and Up to Down within a group box on the screen.<br />

All controls

should get focus - indicated by dotted box, or cursor. Tabbing to an entry field with<br />

text in it should highlight<br />

the entire text in the field.<br />

The text in the Micro Help line should change - Check for spelling, clarity and <strong>no</strong>nupdateable<br />

etc.<br />

If a field is disabled (greyed) then it should <strong>no</strong>t get focus. It should <strong>no</strong>t be possible to<br />

select them with either<br />

the mouse or by using TAB. Try this for every greyed control.<br />

Never updateable fields should be displayed with black text on a grey background<br />

with a black label.<br />

All text should be left-justified, followed by a colon tight to it.<br />

In a field that may or may <strong>no</strong>t be updateable, the label text and contents changes from<br />

black to grey depending<br />

on the current status.<br />

List boxes are always white background with black text whether they are disabled or<br />

<strong>no</strong>t. All others are grey.<br />

In general, do <strong>no</strong>t use goto screens, use gosub, i.e. if a button causes a<strong>no</strong>ther screen to<br />

be displayed, the<br />

screen should <strong>no</strong>t hide the first screen, with the exception of tab in 2.0<br />

When returning return to the first screen cleanly i.e. <strong>no</strong> other screens/applications<br />

should appear.<br />

In general, double-clicking is <strong>no</strong>t essential. In general, everything can be done using<br />

both the mouse and<br />

the keyboard.<br />

All tab buttons should have a distinct letter.<br />

1.3. Text Boxes<br />

Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from<br />

arrow to Insert Bar.<br />

If it doesn't then the text in the box should be grey or <strong>no</strong>n-updateable. Refer to<br />

previous page.<br />

Enter text into Box<br />

Try to overflow the text by typing to many characters - should be stopped Check the<br />

field width with capitals W.<br />

Enter invalid characters - Letters in amount fields, try strange characters like + , - *<br />

etc. in All fields.<br />

SHIFT and Arrow should Select Characters. Selection should also be possible with<br />

mouse. Double Click should<br />

select all text in box.<br />

1.4. Option (Radio Buttons)<br />

Left and Right arrows should move 'ON' Selection. So should Up and Down.. Select<br />

with mouse by clicking.<br />

1.5. Check Boxes

Clicking with the mouse on the box, or on the text should SET/UNSET the box.<br />

SPACE should do the same.<br />

1.6. Command Buttons<br />

If Command Button leads to a<strong>no</strong>ther Screen, and if the user can enter or change<br />

details on the other screen then<br />

the Text on the button should be followed by three dots.<br />

All Buttons except for OK and Cancel should have a letter Access to them. This is<br />

indicated by a letter underlined<br />

in the button text. The button should be activated by pressing ALT+Letter. Make sure<br />

there is <strong>no</strong> duplication.<br />

Click each button once with the mouse - This should activate<br />

Tab to each button - Press SPACE - This should activate<br />

Tab to each button - Press RETURN - This should activate<br />

The above are VERY IMPORTANT, and should be done for EVERY command<br />

Button.<br />

Tab to a<strong>no</strong>ther type of control (<strong>no</strong>t a command button). One button on the screen<br />

should be default (indicated by<br />

a thick black border). Pressing Return in ANY <strong>no</strong> command button control should<br />

activate it.<br />

If there is a Cancel Button on the screen , then pressing should activate it.<br />

If pressing the Command button results in uncorrectable data e.g. closing an action<br />

step, there should be a message<br />

phrased positively with Yes/No answers where Yes results in the completion of the<br />

action.<br />

1.7. Drop Down List Boxes<br />

Pressing the Arrow should give list of options. This List may be scrollable. You<br />

should <strong>no</strong>t be able to type text<br />

in the box.<br />

Pressing a letter should bring you to the first item in the list with that start with that<br />

letter. Pressing ‘Ctrl - F4’<br />

should open/drop down the list box.<br />

Spacing should be compatible with the existing windows spacing (word etc.). Items<br />

should be in alphabetical<br />

order with the exception of blank/<strong>no</strong>ne which is at the top or the bottom of the list<br />

box.<br />

Drop down with the item selected should be display the list with the selected item on<br />

the top.

Make sure only one space appears, shouldn't have a blank line at the bottom.<br />

1.8. Combo Boxes<br />

Should allow text to be entered. Clicking Arrow should allow user to choose from list<br />

1.9. List Boxes<br />

Should allow a single selection to be chosen, by clicking with the mouse, or using the<br />

Up and Down Arrow keys.<br />

Pressing a letter should take you to the first item in the list starting with that letter.<br />

If there is a 'View' or 'Open' button beside the list box then double clicking on a line in<br />

the List Box, should act in the same way as selecting and item in the list box, then<br />

clicking the command button.<br />

Force the scroll bar to appear, make sure all the data can be seen in the box.<br />

Section 2 - Screen Validation Checklist<br />

2.1. Aesthetic Conditions:<br />

Is the general screen background the correct colour<br />

Are the field prompts the correct colour<br />

Are the field backgrounds the correct colour<br />

In read-only mode, are the field prompts the correct colour<br />

In read-only mode, are the field backgrounds the correct colour<br />

Are all the screen prompts specified in the correct screen font<br />

Is the text in all fields specified in the correct screen font<br />

Are all the field prompts aligned perfectly on the screen<br />

Are all the field edit boxes aligned perfectly on the screen<br />

Are all groupboxes aligned correctly on the screen<br />

Should the screen be resizable<br />

Should the screen be minimisable<br />

Are all the field prompts spelt correctly<br />

Are all character or alpha-numeric fields left justified This is the default unless<br />

otherwise specified.<br />

Are all numeric fields right justified This is the default unless otherwise specified.<br />

Is all the microhelp text spelt correctly on this screen<br />

Is all the error message text spelt correctly on this screen<br />

Is all user input captured in UPPER case or lower case consistently

Where the database requires a value (other than null) then this should be defaulted<br />

into fields. The<br />

user must either enter an alternative valid value or leave the default value intact.<br />

Assure that all windows have a consistent look and feel.<br />

Assure that all dialog boxes have a consistent look and feel.<br />

2.2. Validation Conditions:<br />

Does a failure of validation on every field cause a sensible user error message<br />

Is the user required to fix entries which have failed validation tests<br />

Have any fields got multiple validation rules and if so are all rules being applied<br />

If the user enters an invalid value and clicks on the OK button (i.e. does <strong>no</strong>t TAB off<br />

the field) is the invalid entry identified and highlighted correctly with an error<br />

message.<br />

Is validation consistently applied at screen level unless specifically required at field<br />

level<br />

For all numeric fields check whether negative numbers can and should be able to be<br />

entered.<br />

For all numeric fields check the minimum and maximum values and also some midrange<br />

values allowable<br />

For all character/alphanumeric fields check the field to ensure that there is a character<br />

limit specified and that this limit is exactly correct for the specified database size<br />

Do all mandatory fields require user input<br />

If any of the database columns don't allow null values then the corresponding screen<br />

fields must be mandatory. (If any field which initially was mandatory has become<br />

optional then check whether null values are allowed in this field.)<br />

2.3. Navigation Conditions:<br />

Can the screen be accessed correctly from the menu<br />

Can the screen be accessed correctly from the toolbar<br />

Can the screen be accessed correctly by double clicking on a list control on the<br />

previous screen<br />

Can all screens accessible via buttons on this screen be accessed correctly<br />

Can all screens accessible by double clicking on a list control be accessed correctly<br />

Is the screen modal. i.e. Is the user prevented from accessing other functions when<br />

this screen is active and is this correct<br />

Can a number of instances of this screen be opened at the same time and is this<br />

correct<br />

2.4. Usability Conditions:<br />

Are all the dropdowns on this screen sorted correctly Alphabetic sorting is the<br />

default unless otherwise specified.<br />

Is all date entry required in the correct format<br />

Have all pushbuttons on the screen been given appropriate Shortcut keys<br />

Do the Shortcut keys work correctly<br />

Have the menu options which apply to your screen got fast keys associated and should<br />

they have<br />

Does the Tab Order specified on the screen go in sequence from Top Left to bottom<br />

right This is the default unless otherwise specified.<br />

Are all read-only fields avoided in the TAB sequence<br />

Are all disabled fields avoided in the TAB sequence

Can the cursor be placed in the microhelp text box by clicking on the text box with<br />

the mouse<br />

Can the cursor be placed in read-only fields by clicking in the field with the mouse<br />

Is the cursor positioned in the first input field or control when the screen is opened<br />

Is there a default button specified on the screen<br />

Does the default button work correctly<br />

When an error message occurs does the focus return to the field in error when the user<br />

cancels it<br />

When the user Alt+Tab's to a<strong>no</strong>ther application does this have any impact on the<br />

screen upon return to The application<br />

Do all the fields edit boxes indicate the number of characters they will hold by there<br />

length e.g. a 30 character field should be a lot longer<br />

2.5. Data Integrity Conditions:<br />

Is the data saved when the window is closed by double clicking on the close box<br />

Check the maximum field lengths to ensure that there are <strong>no</strong> truncated characters<br />

Where the database requires a value (other than null) then this should be defaulted<br />

into fields. The user must either enter an alternative valid value or leave the default<br />

value intact.<br />

Check maximum and minimum field values for numeric fields<br />

If numeric fields accept negative values can these be stored correctly on the database<br />

and does it make sense for the field to accept negative numbers<br />

If a set of radio buttons represent a fixed set of values such as A, B and C then what<br />

happens if a blank value is retrieved from the database (In some situations rows can<br />

be created on the database by other functions which are <strong>no</strong>t screen based and thus the<br />

required initial values can be incorrect.)<br />

If a <strong>par</strong>ticular set of data is saved to the database check that each value gets saved<br />

fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric<br />

values.<br />

2.6. Modes (Editable Read-only) Conditions:<br />

Are the screen and field colours adjusted correctly for read-only mode<br />

Should a read-only mode be provided for this screen<br />

Are all fields and controls disabled in read-only mode<br />

Can the screen be accessed from the previous screen/menu/toolbar in read-only<br />

mode<br />

Can all screens available from this screen be accessed in read-only mode<br />

Check that <strong>no</strong> validation is performed in read-only mode.<br />

2.7. General Conditions:<br />

Assure the existence of the "Help" menu.<br />

Assure that the proper commands and options are in each menu.<br />

Assure that all buttons on all tool bars have a corresponding key commands.<br />

Assure that each menu command has an alternative(hot-key) key sequence which will<br />

invoke it where appropriate.<br />

In drop down list boxes, ensure that the names are <strong>no</strong>t abbreviations / cut short<br />

In drop down list boxes, assure that the list and each entry in the list can be accessed<br />

via appropriate key / hot key combinations.<br />

Ensure that duplicate hot keys do <strong>no</strong>t exist on each screen

Ensure the proper usage of the escape key (which is to undo any changes that have<br />

been made) and generates a caution message "Changes will be lost - Continue yes/<strong>no</strong>"<br />

Assure that the cancel button functions the same as the escape key.<br />

Assure that the Cancel button operates as a Close button when changes have be made<br />

that can<strong>no</strong>t be undone.<br />

Assure that only command buttons which are used by a <strong>par</strong>ticular window, or in a<br />

<strong>par</strong>ticular dialog box, are present. - i.e make sure they don't work on the screen behind<br />

the current screen.<br />

When a command button is used sometimes and <strong>no</strong>t at other times, assure that it is<br />

grayed out when it should <strong>no</strong>t be used.<br />

Assure that OK and Cancel buttons are grouped se<strong>par</strong>ately from other command<br />

buttons.<br />

Assure that command button names are <strong>no</strong>t abbreviations.<br />

Assure that all field labels/names are <strong>no</strong>t technical labels, but rather are names<br />

meaningful to system users.<br />

Assure that command buttons are all of similar size and shape, and same font & font<br />

size.<br />

Assure that each command button can be accessed via a hot key combination.<br />

Assure that command buttons in the same window/dialog box do <strong>no</strong>t have duplicate<br />

hot keys.<br />

Assure that each window/dialog box has a clearly marked default value (command<br />

button, or other object) which is invoked when the Enter key is pressed - and NOT the<br />

Cancel or Close button<br />

Assure that focus is set to an object/button which makes sense according to the<br />

function of the window/dialog box.<br />

Assure that all option buttons (and radio buttons) names are <strong>no</strong>t abbreviations.<br />

Assure that option button names are <strong>no</strong>t technical labels, but rather are names<br />

meaningful to system users.<br />

If hot keys are used to access option buttons, assure that duplicate hot keys do <strong>no</strong>t<br />

exist in the same window/dialog box.<br />

Assure that option box names are <strong>no</strong>t abbreviations.<br />

Assure that option boxes, option buttons, and command buttons are logically grouped<br />

together in clearly demarcated areas "Group Box"<br />

Assure that the Tab key sequence which traverses the screens does so in a logical<br />

way.<br />

Assure consistency of mouse actions across windows.<br />

Assure that the color red is <strong>no</strong>t used to highlight active objects (many individuals are<br />

red-green color blind).<br />

Assure that the user will have control of the desktop with respect to general color and<br />

highlighting (the application should <strong>no</strong>t dictate the desktop background<br />

characteristics).<br />

Assure that the screen/window does <strong>no</strong>t have a cluttered appearance<br />

Ctrl + F6 opens next tab within tabbed window<br />

Shift + Ctrl + F6 opens previous tab within tabbed window<br />

Tabbing will open next tab within tabbed window if on last field of current tab<br />

Tabbing will go onto the 'Continue' button if on last field of last tab within tabbed<br />

window<br />

Tabbing will go onto the next editable field in the window<br />

Banner style & size & display exact same as existing windows

If 8 or less options in a list box, display all options on open of list box - should be <strong>no</strong><br />

need to scroll<br />

Errors on continue will cause user to be returned to the tab and the focus should be on<br />

the field causing the error. (i.e the tab is opened, highlighting the field with the error<br />

on it)<br />

Pressing continue while on the first tab of a tabbed window (assuming all fields filled<br />

correctly) will <strong>no</strong>t open all the tabs.<br />

On open of tab focus will be on first editable field<br />

All fonts to be the same<br />

Alt+F4 will close the tabbed window and return you to main screen or previous<br />

screen (as appropriate), generating "changes will be lost" message if necessary.<br />

Microhelp text for every enabled field & button<br />

Ensure all fields are disabled in read-only mode<br />

Progress messages on load of tabbed screens<br />

Return operates continue<br />

If retrieve on load of tabbed window fails window should <strong>no</strong>t open<br />

2.8. Specific Field Tests<br />

2.8.1. Date Field Checks<br />

Assure that leap years are validated correctly & do <strong>no</strong>t cause errors/miscalculations<br />

Assure that month code 00 and 13 are validated correctly & do <strong>no</strong>t cause<br />

errors/miscalculations<br />

Assure that 00 and 13 are reported as errors<br />

Assure that day values 00 and 32 are validated correctly & do <strong>no</strong>t cause<br />

errors/miscalculations<br />

Assure that Feb. 28, 29, 30 are validated correctly & do <strong>no</strong>t cause errors/<br />

miscalculations<br />

Assure that Feb. 30 is reported as an error<br />

Assure that century change is validated correctly & does <strong>no</strong>t cause errors/<br />

miscalculations<br />

Assure that out of cycle dates are validated correctly & do <strong>no</strong>t cause<br />

errors/miscalculations<br />

2.8.2. Numeric Fields<br />

Assure that lowest and highest values are handled correctly<br />

Assure that invalid values are logged and reported<br />

Assure that valid values are handles by the correct procedure<br />

Assure that numeric fields with a blank in position 1 are processed or reported as an<br />

error<br />

Assure that fields with a blank in the last position are processed or reported as an error<br />

an error<br />

Assure that both + and - values are correctly processed<br />

Assure that division by zero does <strong>no</strong>t occur<br />

Include value zero in all calculations<br />

Include at least one in-range value<br />

Include maximum and minimum range values<br />

Include out of range values above the maximum and below the minimum<br />

Assure that upper and lower values in ranges are handled correctly

2.8.3. Alpha Field Checks<br />

Use blank and <strong>no</strong>n-blank data<br />

Include lowest and highest values<br />

Include invalid characters & symbols<br />

Include valid characters<br />

Include data items with first position blank<br />

Include data items with last position blank<br />

Section 3 - Validation Testing - Standard Actions<br />

3.1. Examples of Standard Actions - Substitute your specific commands<br />

Add<br />

View<br />

Change<br />

Delete<br />

Continue - (i.e. continue saving changes or additions)<br />

Add<br />

View<br />

Change<br />

Delete<br />

Cancel - (i.e. abandon changes or additions)<br />

Fill each field - Valid data<br />

Fill each field - Invalid data<br />

Different Check Box / Radio Box combinations<br />

Scroll Lists / Drop Down List Boxes<br />

Help<br />

Fill Lists and Scroll<br />

Tab<br />

Tab Sequence<br />

Shift Tab<br />

3.2. Shortcut keys / Hot Keys<br />

Note: The following keys are used in some windows applications, and are included as<br />

a guide.<br />

Key No Modifier Shift CTRL ALT<br />

F1 Help Enter Help<br />

Mode<br />

n\a<br />

n\a<br />

F2 n\a n\a n\a n\a<br />

F3 n\a n\a n\a n\a<br />

F4 n\a n\a Close<br />

Document /<br />

Child window.<br />

Close<br />

Application.

F5 n\a n\a n\a n\a<br />

F6 n\a n\a n\a n\a<br />

F7 n\a n\a n\a n\a<br />

F8<br />

Toggle extend<br />

mode, if<br />

supported.<br />

Toggle Add<br />

mode, if<br />

supported.<br />

n\a<br />

n\a<br />

F9 n\a n\a n\a n\a<br />

F10<br />

Toggle menu<br />

bar activation.<br />

n\a n\a n\a<br />

F11, F12 n\a n\a n\a n\a<br />

Tab<br />

Move to next<br />

active/editable<br />

field.<br />

Move to<br />

previous<br />

active/editable<br />

field.<br />

Move to next<br />

open Document<br />

or Child<br />

window.<br />

(Adding SHIFT<br />

reverses the<br />

order of<br />

movement).<br />

Switch to<br />

previously used<br />

application.<br />

(Holding down<br />

the ALT key<br />

displays all<br />

open<br />

applications).<br />

Alt<br />

Puts focus on<br />

first menu<br />

command (e.g.<br />

'File').<br />

n\a n\a n\a<br />

3.3. Control Shortcut Keys<br />

Key<br />

CTRL + Z<br />

CTRL + X<br />

CTRL + C<br />

CTRL + V<br />

CTRL + N<br />

CTRL + O<br />

CTRL + P<br />

CTRL + S<br />

CTRL + B<br />

Function<br />

Undo<br />

Cut<br />

Copy<br />

Paste<br />

New<br />

Open<br />

Print<br />

Save<br />

Bold*

CTRL + I<br />

Italic*<br />

CTRL + U<br />

Underline*<br />

* These shortcuts are suggested for text formatting applications, in the context for<br />

which they make sense. Applications may use other modifiers for these operations.<br />

8.1. <strong>Konspekts</strong><br />

Darba organizācija programmēšanas grupā<br />

Projekta komanda un tās izvēle<br />

Programmatūras izstrādes projekta realizācijas komandas plā<strong>no</strong>šana ir atbildīs solis.<br />

No projekta komandas komplektācijas ir atkarīga projekta turpmākā <strong>no</strong>rise un<br />

veiksme. Novērtējot projektam nepieciešamo darbietilpību jau ir jāzina, kādi<br />

darbinieki piedalīsies sistēmanalīzē, projektēšanā, izstrādē, testēšanā, dokumentēšanā<br />

un ieviešanā.<br />

Izstrādes projektos <strong>par</strong>asti piedalās:<br />

projekta vadītājs;<br />

sistēmanalītiķi;<br />

projektētāji;<br />

programmētāji;<br />

testētāji;<br />

dokumentētāji;<br />

kvalitātes speciālisti;<br />

administrators.<br />

Taču šo lomu skaits var būtiski atšķirties atkarībā <strong>no</strong> projekta lieluma. Mazajos<br />

projektos viens un tas pats darbinieks var pildīt vairākus uzdevumus. Jo lielāks<br />

projekts, jo svarīgāka ir lomu atdalīšana un šaurāka specializācija.<br />

Tomēr šo IT organizācijas tieši projektā iesaistītie darbinieki nav vienīgie. Ne mazāk<br />

svarīgi atrast projekta sponsoru - ieinteresēto personu <strong>no</strong> Pasūtītāja puses, kā arī<br />

projekta pārraugu <strong>no</strong> IT organizācijas augstākās vadības. Ir vitāli svarīgi iesaistīt arī<br />

citus pasūtītāja pārstāvjus, kā biznescilvēkus, izstrādājamās sistēmas lietotājus un<br />

akcepttestēšanas dalībniekus.<br />

Plā<strong>no</strong>jot projekta komandu ir vērtīgi ņemt vērā šādus faktorus:<br />

Vai projekta komanda ir sastrādājusies<br />

Savstarpējas komunikācijas stingri apgrūtinātas<br />

Daļēji sastrādājusies komanda<br />

Pārsvarā sastrādājusies komanda<br />

Ļoti labi sastrādājusies komanda<br />

Kāda ir iesaistīto darbinieku pieredze līdzīgu projektu realizācijā<br />

Nav<br />

Komandai tas ir pārsvarā nepazīstams uzdevums<br />

Ir atrodamas dažas nepazīstamas vietas<br />

Komandai šis ir vispārīgos vilcie<strong>no</strong>s pazīstams uzdevums<br />

Šis ir pārsvarā pazīstams uzdevums<br />

Šis ir l abi zināms uzdevums

Kāda ir iesaistīto darbinieku pieredze IT jomā<br />

Ārkārtīgi zema (

sniegumu. Savukārt <strong>par</strong> projekta kopējiem rezultātiem ir atbildīgs projekta vadītājs,<br />

kurš saņem informāciju <strong>no</strong> grupu līderiem.<br />

Lielākajos projektos (50 un vairāk iesaistīto darbinieku) starp projekta pārvaldnieku<br />

un grupu līderiem var būt izveidots papildus līmenis - apakšprojektu vadītāji. Atkarībā<br />

<strong>no</strong> iespējas projektu neatkarīgi izstrādāt pa moduļiem, projekts var būt sadalīts<br />

vairākos apakšprojektos.<br />

Alternatīva hierarhiskajam projekta organizācijas modelim ir "Āzijas" jeb armijas<br />

modelis. Spēcīga motivācijas sistēma. Piemēri - mongoļu impērija, nacistu sistēma,<br />

padomju sistēma.<br />

Pārvaldības modelis - būvu cilvēku kompānija<br />

Vēl viens projekta organizatorisks modelis ir būvu cilvēku kompānija - lēmumu<br />

pieņemšana gandrīz neiespējama. Piemērs - Eiropa nespēj pieņemt lēmumu Irākas<br />

jautājumā, Balkānu jautājumā u.tml.<br />

2. attēls. Pārvaldības modelis - būvu cilvēku kompānija.<br />

Administratīvais (pozitīvās un negatīvās puses)<br />

- skaidra atbildība,<br />

- kontekstu var nezināt,<br />

- jo augstāk hierarhija, jo lielāka slodze un atbildība,<br />

- "aklais lidotājs - programmētāji, kas nezina kontekstu<br />

Galvenā programmētāja brigāde (Chief Programmer's Team)<br />

Funkcijas :<br />

- Galvenais programmētājs - pats pieredzējušākais, labākais u.tml.; pats izstrādā<br />

svarīgākos gabalus.<br />

- Otrais pilots - zina to pašu un var uzņemties vadību; arī pats izstrādā.<br />

- Programmētāji - izstrādā.<br />

- Instrumentālists - izvēlas vidi, apgūst, pēc tam māca / konsultē<br />

- Dokumentētājs - atbild <strong>par</strong> sistēmas dokumentāciju<br />

- Bibliotekārs - pārzina versijas<br />

- Vadītājs (manager) - <strong>no</strong>drošina resursus u.tml.<br />

Komanda uzstājas kā vie<strong>no</strong>ts organisms. Hierarhiskajā modelī vadītāji ātri pārstāj būt<br />

speciālisti (programmēšanas speciālisti). Galvenā programmētāja brigādē (GPB)<br />

saglabājas profesionalitāte, aug jauni līderi, taču jābūt saderīgiem raksturiem. Tomēr<br />

GPB ir kāds apjoma slieksnis, ko tā nespēj pārkāpt, t.i. apmēram 10-20000 gatavu<br />

koda rindiņu gadā ar visu dokumentāciju. Lielākām sistēmām hierarhija ir<br />

neizbēgama.

Prince organizācijas struktūra<br />

Pārvaldības modeļa <strong>no</strong>saukums PRINCE ir saīsinājums <strong>no</strong> 'Projects in Controlled<br />

Environments' jeb projekti pārvaldāmā vidē. PRINCE ir strukturēta pieeja projektu<br />

pārvaldībai un to ir izstrādājusi Lielbritānijas valdība. PRINCE modelis jau sākumā<br />

tika <strong>par</strong>edzēts informācijas sistēmu izstrādes projektiem, taču lielākā daļa modeļa<br />

principu ir attiecināma uz plaša spektra projektu situācijām. PRINCE piedāvā<br />

vairākas priekšrocības, kuras padara programmatūras izstrādes projektus veiksmīgus:<br />

Definēta pārvaldības struktūra<br />

Plā<strong>no</strong>šanas sistēma<br />

Pārvaldāmo procedūru kopa<br />

Fokusēšanās uz produktu plā<strong>no</strong>šanas, t.i. <strong>no</strong>devumu plā<strong>no</strong>šanas.<br />

PRINCE pārvaldības struktūra.<br />

PRINCE pārvaldības hierarhijas galā atrodas pārvaldības a<strong>par</strong>āts, kurš <strong>no</strong>saka<br />

vispārējus mērķus programmatūras izstrādes projekta organizācijai. Šis līmenis var<br />

atšķirties katrā organizācijā. Iespējams, ka svarīgākus lēmumus pieņems organizācijas<br />

vadība organizācijas valdes priekšsēdētāju sastāvā. Patstāvīgu projektu augstākā<br />

līmeņa vadība, kuru <strong>no</strong>saka PRINCE sauc <strong>par</strong> projekta valdi. Projekta valde<br />

reprezentē trīs galvenās instances, svarīgas projektu pārvaldībā : izpild-vadītājs -<br />

persona, kuru ievel organizācijas augstākā vadība savu biznesa interešu aizstāvībai;<br />

galvenais lietotājs - reprezentē biznesa sfēras intereses, kuras ietekmē jaunas<br />

informācijas sistēmas ieviešana, un runā visu gala lietotāju vārdā; galvenais<br />

piegādātājs - reprezentē jaunas informācijas sistēmas izstrādātājus, tas var būt IT<br />

direktors vai programmatūras izstrādes pārvaldnieks.<br />

Svarīgi ir tas, ka PRINCE modelis ir elastīgs, tādējādi organizatoriskā struktūra var<br />

variēt, lai labāk atbilstu projektu specifikai un vajadzībām. Piemēram, iespējama<br />

situācija, kurā izpild-vadītāja un galvenā lietotāja lomu <strong>no</strong> pasūtītāja puses pārstāv<br />

viena un tā pati persona. No otras puses, var gadīties situācija, kurā galve<strong>no</strong> lietotāja<br />

lomu pārstāv vairāki gala lietotāju pārstāvji. Galvenais ir iedibināt efektīvi strādājošu<br />

pārvaldības struktūru, kura spēj ātri pieņemt lēmumus.

Mūsdienu projektu pārvaldība ir projekta pārvaldnieka un viena vai vairāku komandu<br />

pārvaldnieku atbilstības sfēra. Projekta pārvaldnieka lomai nav nepieciešami<br />

komentāri. Kas attiecās uz komandu pārvaldniekiem, PRINCE modelis <strong>par</strong>edz, ka<br />

projekts sava dzīves cikla laikā izies cauri vairākām fāzēm, kurās iespējami būs<br />

nepieciešams atsevišķs atbildīgais. Tā kā katrā <strong>no</strong> fāzēm var būt nepieciešamas<br />

specifiskas atšķirīgas zināšanas, komandu pārvaldnieka lomu var katrā <strong>no</strong> šīm fāzēm<br />

ieņemt cits darbinieks. Tādējādi var gadīties, ka projekta pārvaldnieks strādā projekta<br />

laikā ar vairākiem komandu pārvaldniekiem; vai projekta pārvaldnieks uzņemas arī<br />

komandu pārvaldnieka lomu; vai projekta pārvaldnieka lomu var katrā atsevišķā fāzē<br />

uzņemties komandas pārvaldnieks.<br />

Projekta <strong>no</strong>drošinājuma līmenis atrodas starp projekta valdes un projekta pārvaldnieka<br />

līmeņiem. Tas iekļauj trīs galve<strong>no</strong>s aspektus - biznesa <strong>no</strong>drošinājumu (jebkuru<br />

būtisko izmaiņu ietekmes <strong>no</strong>vērtējums un kontrole), lietotāju <strong>no</strong>drošinājumu<br />

(programmatūras gala lietotāju interešu pārstāvēšana, prasību realizācijas kontrole) un<br />

tehnisko <strong>no</strong>drošinājumu (palīdzība tehnisko projekta stratēģiju definēšanā, kvalitātes<br />

kritēriju un citu tehnisko metožu un standartu ievērošanas kontrole).<br />

Projekta atbalsta līmenis atrodas starp projekta pārvaldnieku un komandu<br />

pārvaldniekiem. Projekta atbalsta komanda palīdz projekta pārvaldniekam plānu<br />

sastādīšanā, projekta atsekošanā un mērīšanā, projekta un komandu pārvaldības<br />

atskaišu sagatavošanā, kā arī veic lēmumu pieņemšanas procesa kontroli un projekta<br />

progresa uzraudzību.<br />

Lai projekts būtu veiksmīgs, ir vitāli svarīgi apzināties kurš ir pasūtītājs, kurš pieņem<br />

galve<strong>no</strong>s svarīgus lēmumus un kurš uzņemsies atbildību <strong>par</strong> projektā <strong>no</strong>tiekošo.<br />

PRINCE <strong>no</strong>drošina projekta pārvaldības metodi, kura piedāvā ērtu un efektīvu<br />

struktūru programmatūras projektu pārvaldībai.<br />

8.2. Kā top informācijas sistēmas III<br />

Kā top informācijas sistēmas<br />

<strong>Izmantoti</strong>e materiāli: Ivards Solovjovs, DatorPasaule, 2'2000, III daļa<br />

Projektu vadīšanas tehnika<br />

IS projekts <strong>par</strong>asti sastāv <strong>no</strong> daudzām savstarpēji saistītām aktivitātēm (dažkārt to ir<br />

simtiem), kurās tiek iesaistīti daudzi cilvēki (<strong>par</strong>asti 5 – 100), kā arī eksistē dažādi<br />

ierobežojumi (koplietošanas resursi, fiksēti atsevišķu <strong>no</strong>tikumu termiņi un citi). Lai šo<br />

procesu varētu <strong>no</strong>rmāli plā<strong>no</strong>t un vadīt, īpaši <strong>no</strong>derīga ir vispārpieņemtā projektu<br />

vadīšanas tehnika. Pazīstamākās <strong>no</strong> projekta plā<strong>no</strong>šanas tehnikām (rīkiem) ir GANTT<br />

un PERT diagrammas. Pirmā akcentē atsevišķu darbu izpildes termiņus un<br />

nepieciešamos resursus, otrā – aktivitāšu un <strong>no</strong>tikumu savstarpējo atkarību. Abu veidu<br />

diagrammas atbalsta arī plaši lietotā Microsoft Project programmatūra.<br />

IS izstrādes projekta GANTT diagrammas piemērs dots 1. attēlā.

Kā tipiskākos projekta vadības uzdevumus var minēt šādas aktivitātes:<br />

Darbu (aktivitāšu) sadalīšana sīkāk.<br />

Projekta mērķa dekompozīcija, atsevišķos darbos (aktivitātēs) iegūstot vairāklīmeņu<br />

hierarhisku, numurētu struktūru (work breakdown structure – WBS). Detalizācijas<br />

līmenis ir atkarīgs <strong>no</strong> abstrakcijas līmeņa, kādā projekts tiek aplūkots (piemēram,<br />

zemākā līmeņa aktivitāte var atbilst gan līgumā <strong>par</strong>edzētam darbu posmam, gan arī<br />

konkrētam darbiniekam uzdodamajam uzdevumam).<br />

Projekta darbu (aktivitāšu) secīga sakārtošana.<br />

Katram darbam tiek <strong>no</strong>rādīti tie darbi, kuru pabeigšana ir priekš<strong>no</strong>sacījums tā<br />

uzsākšanai (predsessors), Tādējādi tiek definēta darbu izpildes loģiskā secība.<br />

Darbu (aktivitāšu) termiņu, resursietilpības un izmaksu vērtēšana.<br />

Katram darbam tiek <strong>no</strong>vērtēti tā izpildei nepieciešamie resursi, kā arī termiņi (sk.<br />

nākamo sadaļu). Tā kā darba apjoms ir funkcija <strong>no</strong> laika un resursiem, tad atkarībā <strong>no</strong><br />

tā, kas ir ierobežojošais faktors, var izvēlēties dažādus darbu izpildes variantus.<br />

Projekta plāna saskaņošana ar laika ierobežojumiem.<br />

Ja ierobežojošais faktors ir projekta izpildes gala termiņš, to var mēģināt samazināt,<br />

palieli<strong>no</strong>t iesaistāmos resursus, mai<strong>no</strong>t darbu izpildes secību (piemēram, atsevišķus<br />

darbus veicot <strong>par</strong>alēli) vai radikālā gadījumā samazi<strong>no</strong>t izvirzīto mērķi<br />

(funkcionalitāti).<br />

Projekta plāna optimizēšana, izmantojot kritiskā ceļa metodi.<br />

Īpaša metode projekta plāna analīzei un optimizēšanai, <strong>no</strong>sakot to darbu virkni, kas<br />

summāri veido visgarāko laika posmu. Saīsi<strong>no</strong>t vai citādi optimizējot darbus, kuri<br />

atrodas uz kritiskā ceļa, reizē tiek samazināts arī projekta kopējais garums.<br />

Projekta plāna saskaņošana ar resursu ierobežojumiem.<br />

Ja ierobežojošais faktors ir pieejamie resursi, darbu izpildes termiņi ir "jāsakrata"<br />

atbilstoši to pieejamībai. Protams, jāizvairās arī <strong>no</strong> resursu dīkstāves, kā arī straujiem<br />

resursu izmantošanas lēcieniem.<br />

Regulāra projekta darbu izpildes uzraudzīšana, projekta plāna modificēšana, kā arī<br />

citu koriģējošu pasākumu veikšana.<br />

Tas ir regulārs process visa projekta garumā, kura ietvaros, tiek sekots līdzi, kā tiek<br />

pildīti plā<strong>no</strong>tie darbi. Termiņu kavējumu gadījumā vai nu tiek veiktas koriģējošas<br />

darbības (piemēram, izdalīti papildu resursi vai speciāli motivēti darbinieki), vai arī<br />

tiek mainīts projekta plāns atbilstoši faktiskajai situācijai. Šajā gadījumā papildus<br />

sākotnējam plānam <strong>par</strong>ādās plāna bāzlīniju versijas. Jebkuras projekta plāna izmaiņas<br />

ir formāli akceptējamas attiecīgā līmeņa projekta vadības institūcijā.<br />

Resursu un termiņu <strong>no</strong>vērtēšana – IS projektu kritiskais faktors<br />

Programmatūras izstrādei nepieciešamā darba apjoma un termiņu <strong>par</strong>eizs <strong>no</strong>vērtējums

laikam ir uzskatāms <strong>par</strong> sekmīga projekta galve<strong>no</strong> priekš<strong>no</strong>sacījumu. Pat pieredzējuši<br />

izstrādātāji, paļaujoties tikai uz savu intuīciju, šajā ziņā mēdz kļūdīties pat <strong>par</strong> kārtu.<br />

Tāpēc nav brīnums, ka jau kopš programmatūras izstrādes pirmsākumiem,<br />

pamatojoties uz uzkrāto pieredzi, ir mēģināts izveidot precīzu kvantitatīvi<br />

algoritmisku modeli, kas būtu izmantojams programmatūras izstrādei nepieciešamā<br />

darba apjoma un termiņu prog<strong>no</strong>zēšanai. Pašreiz plaši tiek izmantots COCOMO<br />

modelis (ir vairāki tā paveidi), kura pamatā ir funkcijpunkti. Tā ir <strong>no</strong>sacīta<br />

mērvienība, kas atbilst izstrādājamās programmatūras funkcionalitātei un kura tiek<br />

<strong>no</strong>vērtēta, balstoties uz programmatūras funkcionāli skaitliskiem atribūtiem (ievades,<br />

izvades, vaicājumu, iekšējo datu failu, saskarņu skaits, to sarežģītības vērtējums).<br />

Tālāk tiek <strong>no</strong>vērtēts, ar cik programmēšanas valodas <strong>no</strong>sacītām koda rindiņām dotā<br />

funkcionalitāte ir realizējama (atkarīgs <strong>no</strong> programmēšanas vides produktivitātes).<br />

Tad, ņemot vērā vairākus izstrādes procesu raksturojošus atribūtus (izstrādātāju<br />

pieredze, koda atkārtojama izmantošana, laika un citi ierobežojumi, prasību stabilitāte<br />

u.tml.), tiek <strong>no</strong>vērtēts gan darba apjoms (cilvēkmēnešos), gan termiņi (mēnešos).<br />

Turklāt jāpiezīmē, ka mēneši un cilvēki nav savstarpēji aizvietojami (deviņi cilvēki<br />

vienā mēnesī nevar paveikt to, ko viens deviņos: jo vairāk cilvēku, jo lielāka darba<br />

daļa aiziet uz komunikāciju un koordinēšanu).<br />

Jāsaka, ka šādi iegūti vērtējumi ir tikai aptuveni, turklāt – jo precīzākas mūsu<br />

zināšanas <strong>par</strong> izstrādājamo sistēmu, jo precīzāka ir prog<strong>no</strong>ze. Parastā prakse ir tāda,<br />

ka COCOMO metodi izmanto, balstoties uz programmatūras prasību specifikācijā<br />

pieejamo informāciju. Pieredze rāda, ka šādi iegūtās prog<strong>no</strong>zes pietiekami precīzi<br />

sakrīt ar faktiskajiem skaitļiem.<br />

Nozīmīgs faktors prog<strong>no</strong>zes precizitātes palielināšanai ir pieredzes uzkrāšana un<br />

formulās izmantojamo koeficientu koriģēšana, balstoties uz prog<strong>no</strong>zēto un faktisko<br />

skaitļu salīdzināšanu.<br />

Projekta organizatoriskā struktūra<br />

Efektīva projekta vadība nav iespējama bez atbilstošas projekta organizatoriskās<br />

struktūras izveides. Tas <strong>no</strong>zīmē, ka jāizveido projekta vadības institūcijas, jā<strong>no</strong>zīmē<br />

konkrētas amatpersonas, jāizstrādā un jāapstiprina attiecīgi <strong>no</strong>likumi un<br />

amatinstrukcijas.<br />

Stratēģisku projekta jautājumu risināšanai būtu jāorganizē projekta valde (angliski šo<br />

institūciju mēdz saukt <strong>par</strong> steering comitee vai project board). Šie jautājumi ietver<br />

projekta stratēģisko uzdevumu formulēšanu un izpildes kontroli, projekta plānu<br />

apstiprināšanu, koriģēšanu un plānu izpildes kontroli, principiālu projekta lēmumu<br />

pieņemšanu, finansu un citu resursu <strong>no</strong>drošināšanu, finansiālu jautājumu un<br />

konfliktsituāciju risināšanu, kā arī citus stratēģiskus jautājumus. Valdes sastāvu<br />

<strong>par</strong>asti veido uzņēmuma vadības pārstāvji, lietotāju vadības pārstāvji, uzņēmuma IT<br />

daļas vadītājs, galve<strong>no</strong> projekta izpildē iesaistīto organizāciju augstākās<br />

amatpersonas, kā arī projekta vadītāji (gan <strong>no</strong> pasūtītāja, gan izpildītāju puses).<br />

Lai risinātu konkrētus ar projekta izpildi saistītus jautājumus, <strong>par</strong>asti tiek izveidota<br />

izmaiņu vadības padome (IVP) vai vienkārši projekta vadības padome, kuras<br />

kompetencē ir projekta darbu izpildes organizēšana, prasību, projektējumu un citu<br />

dokumentu apstiprināšana, izmaiņu pieprasījumu un problēmziņojumu izskatīšana,<br />

izpildītāju darba koordinēšana, kā arī citu darba jautājumu risināšana. IVP sastāvā ir<br />

iekļaujami projektu vadītāji (gan <strong>no</strong> pasūtītāja, gan izpildītāju puses), lietotāju<br />

pārstāvji, izstrādātāju pārstāvji, uzņēmuma IT daļas pārstāvji, kā arī citi speciālisti.<br />

IVP sēdēm jā<strong>no</strong>tiek regulāri (teiksim, reizi nedēļā) un jātiek attiecīgi protokolētām.<br />

Nepieciešamības gadījumā var izveidot arī IVP apakškomisijas, kurās tiek risināti ar

Pr Vadibas Str.BMP (72898 bytes)<br />

atsevišķu apakšsistēmu (kādu komponentu vai tematisko jomu) saistīti jautājumi (sk.<br />

2. attēlu.)<br />

Izmaiņu pārvaldība<br />

Vēl viens <strong>no</strong>zīmīgs aspekts visa projekta dzīves cikla garumā ir izmaiņu pārvaldība.<br />

Lai cik precīzi mēs censtos specificēt izstrādājamo sistēmu un definēt izstrādātājam<br />

darba uzdevumu, laikā gaitā <strong>par</strong>ādās jaunas prasības, izpētes rezultātā esošās ir<br />

jāmodificē, tāpēc ir jāmaina arī darba uzdevums izstrādātājam. Sistēmas darbināšanas<br />

laikā lietotāji var vēlēties kādas jaunas iespējas vai arī tiek konstatētas dažādas<br />

nepilnības sistēmas darbā. Šāda situācija ir <strong>no</strong>rmāla, un grūti iedomāties, ka kaut cik<br />

<strong>no</strong>pietnā projektā varētu būt citādi. Lai nerastos problēmas abu pušu starpā, ir ļoti<br />

svarīgi, lai eksistētu dokumentēts un savstarpēji saskaņots mehānisms un procedūra<br />

šādu jautājumu risināšanai. Parasti visas pasūtītāja vēlmes, kā arī konstatētās<br />

problēmas tiek fiksētas izmaiņu pieprasījumu un problēmziņojumu veidā ar speciālu<br />

veidlapu palīdzību. Visi ziņojumi tiek reģistrēti, izanalizēti un izskatīti izmaiņu<br />

vadības padomē un <strong>par</strong> katru <strong>no</strong> tiem tiek pieņemts attiecīgs lēmums (piemēram,<br />

precizēt, <strong>no</strong>raidīt, realizēt nākamajā versijā utt.). Šādu problēmziņojumu un izmaiņu<br />

pieprasījumu var būt pietiekami daudz, tāpēc bieži šis darbs tiek automatizēts ar<br />

speciālu programmu palīdzību.<br />

Kvalitātes <strong>no</strong>drošināšana<br />

Ja runa ir <strong>par</strong> <strong>no</strong>pietnu projektu realizāciju (īpaši to, kuri ir saistīti ar informācijas<br />

sistēmu izstrādi un ieviešanu), kvalitātes pārvaldība ir viena <strong>no</strong> būtiskākajām<br />

aktivitātēm visā projekta dzīves ciklā. Kvalitātes pārvaldības galvenais uzdevums ir<br />

<strong>no</strong>drošināt visu projekta <strong>no</strong>risē iesaistīto un gala rezultātā ieinteresēto pušu (esošo un<br />

potenciālo) prasību un vajadzību apmierināšanu. Kvalitātes jautājumu pārraudzīšanu<br />

konkrētā projektā <strong>par</strong>asti <strong>no</strong>drošina speciāli <strong>no</strong>zīmēts cilvēks – projekta kvalitātes<br />

pārvaldnieks.<br />

Pirmais faktors kvalitatīva rezultāta <strong>no</strong>drošināšanā ir sakārtots un kvalitatīvs pats<br />

darba process. Par standartiem, atbilstoši kuriem jāorganizē darbs, jau tika stāstīts.<br />

Iesaistot darbu veikšanā vai preču piegādē citas organizācijas, jābūt pārliecībai, ka arī<br />

šo organizāciju darba procesi ir sakārtoti. Mērķtiecīgi ir orientēties uz tiem<br />

pakalpojumu sniedzējiem un preču piegādātājiem, kuriem ir ISO9000 sertifikāts.<br />

Kā otrs faktors <strong>no</strong>teikti jāmin precīzs prasību un izmaiņu pieprasījumu pārvaldības<br />

darbs, kā arī konfigurācijas pārvaldības darbs. Praktiski tas <strong>no</strong>zīmē lietotāja prasību<br />

precīzu uzskaiti un trasējamību visā projekta dzīves cikla laikā, kā arī prasību

precizēšanu un izmaiņas saskaņā ar izmaiņu vadības kārtību, visu izstrādājamo<br />

vienumu precīzu uzskaiti, versiju kontroli utt.<br />

Trešais ļoti <strong>no</strong>zīmīgs kvalitātes <strong>no</strong>drošināšanas faktors IS izstrādes projektos ir<br />

programmatūras testēšana. Tiek praktizēta dažādu veidu testēšana – autortestēšana,<br />

sistēmanalītiskā testēšana, vienību testēšana, integrācijas testēšana, kvalifikācijas<br />

testēšana u.c.<br />

Ceturtais faktors kvalitātes <strong>no</strong>drošināšanā ir regulārie gan iekšējie, gan ārējie auditi,<br />

projekta apskates un citas vadīklas (controls) (atbilstoši ISO9000 termi<strong>no</strong>loģijai), kas<br />

<strong>no</strong>drošina objektīvu informāciju <strong>par</strong> to, kādā mērā reālā situācija atbilst projekta<br />

mērķiem, lietotāja prasībām, standartiem un citiem reglamentējošiem dokumentiem.<br />

Īsas pamācības IS projektu veidošanā<br />

Apzi<strong>no</strong>ties, ka šī tēma nav aptverama viena raksta ietvaros, <strong>no</strong>beigumā dažas atziņas,<br />

kas varētu <strong>no</strong>derēt praktiskajā darbībā.<br />

1. Nebūvējiet debesskrāpi, paļaujoties tikai uz amatnieku zelta rokām, jo <strong>no</strong>pietnu<br />

informācijas sistēmu izstrāde prasa industriālu pieeju un standartu izmantošanu.<br />

2. Pirms uzsākat darbu pie IS projekta, tieciet skaidrībā <strong>par</strong> mērķiem, ko gribat<br />

sasniegt, un cik jūs esat gatavi investēt to sasniegšanā.<br />

3. Brīnumu pasaulē nav, tāpēc nevajag cerēt, ka rezultāti būs uzreiz, neprasot piepūli.<br />

4. Sistēmas tiek izstrādātas lietotājam, tāpēc viņam arī jābūt sistēmas saimniekam.<br />

5. Visa pamatā – prasības (cik labi būs definētas prasības, tik labs būs arī rezultāts).<br />

6. Koncentrējieties uz projekta vadību un procesa organizēšanu, jo tehnisko<br />

kompetenci izdevīgāk ir iepirkt <strong>no</strong> ārpuses.<br />

7. Tas, kas nav uzrakstīts, neeksistē, tāpēc izstrādes process un rezultāti ir<br />

jādokumentē.<br />

8. Izmaiņas sistēmā ir <strong>no</strong>rmāli, galvenais ir tās kontrolēt.<br />

9. Nelaidiet izstrādātājus pie sistēmas darbināšanas.<br />

10. Divas svešas acis redz labāk nekā simt savējo (apskates un auditi nav tukša laika<br />

kavēšana).<br />

11. Ja nekas cits nelīdz, izmantojiet savu pieredzi un veselo saprātu, jo nekas <strong>no</strong> jau<br />

teiktā nav dogma.<br />

8.3. Programmatūras izstrādes projekta vadītāja piezīmes<br />

Programmatūras izstrādes projekta vadītāja piezīmes<br />

E-pasaule, Vita Karnīte.<br />

Lai cik plaši būtu pieejami pētījumi <strong>par</strong> projektu vadību, ikviens programmatūras<br />

izstrādes projekta vadītājs savulaik ir pionieris un pirmatklājējs vadīšanas praksē, līdz<br />

ar pieredzi krājot arī secinājumus un ieteikumus. Rakstā apkopotas vairāku<br />

programmatūras izstrādes projektu vadītāju populārākās atziņas.<br />

Kas ir projekts<br />

Projekts = termiņš + sasniedzamais rezultāts + budžets.<br />

Projekts ir uzdevums ar <strong>no</strong>teiktiem <strong>par</strong>ametriem – sākuma un beigu datumi,<br />

sasniedzamais rezultāts, budžets.<br />

Projekta vadītājs = zināšanas + entuziasms + pieredze.

Projekta vadītājs ir cilvēks, kam jāsasniedz konkrēts rezultāts <strong>no</strong>teiktā laikā,<br />

izmantojot resursus, ko var atļauties saskaņā ar atvēlēto budžetu. Vadītājs var<br />

izmantot savas zināšanas un spējas, piesaistīt citu cilvēku zināšanas un spējas, kā arī<br />

izvēlēties palīglīdzekļus. Ja projekts tiek realizēts veiksmīgi, tā vadītājs var pamatoti<br />

lepoties ar pakāpienu savā karjerā, turklāt sevišķi augstu tiek vērtēti tie vadītāji, kuri<br />

izveduši projektu <strong>no</strong> krīzes situācijas. Projektam ciešot neveiksmi, atbildība pilnībā<br />

jāuzņemas vadītājam.<br />

Ar projektu realizāciju savas dzīves laikā sastopas ikviens cilvēks, un patstāvīgi<br />

cilvēki ar laiku pierod arī sadzīvē domāt projektu vadības kategorijās – izvirza<br />

konkrētus mērķus, <strong>no</strong>saka laiku, rēķinās ar konkrētiem līdzekļiem. Filozofiski uz to<br />

skatoties, visa cilvēka dzīve ir kā liels projekts ar daudziem apakšprojektiem, kas<br />

laika gaitā kļūst arvien sarežģītāki, piemēram:<br />

• skolā – kontroldarbs matemātikā jāuzraksta 45 minūtē, un atbildei jāsakrīt ar<br />

skolotāja rīcībā esošo;<br />

• augstskolā – programmēšanas kursam <strong>par</strong>edzēti trīs mēneši, atzīmei jābūt >8,<br />

budžetu veido stipendija un studiju kredīts;<br />

• darbā – programmatūras izstrādes termiņš ir divi gadi, tiek izstrādāta un ieviesta<br />

<strong>no</strong>rēķinu sistēma, budžets – Ls 600 000.<br />

Vadība<br />

Prakse liecina, ka 80% <strong>no</strong> veicamā uzdevuma prasa 50% tam atvēlētā laika. Ja 80%<br />

<strong>no</strong> uzdevuma ir izdarīti 80% <strong>no</strong> atvēlētā laika, ļoti iespējams, ka termiņš tiks<br />

<strong>no</strong>kavēts.<br />

Plašāk pazīstamas un praksē arvien pārbaudītas sakarības, ar kurām<br />

vadītājs var rēķināties, ir tā sauktās sakarības 80:20, piemēram:<br />

• 80% labumu var <strong>no</strong>drošināt ar 20% <strong>no</strong> prasību realizācijas,<br />

• 20% profesionālāko programmētāju rada 80% koda,<br />

• 20% vājāko programmētāju rada 80% <strong>no</strong> atklātajām kļūdām.<br />

Ja vadītājs nevar atbildēt uz kādu projekta īste<strong>no</strong>šanā radušos<br />

jautājumu, tad viņam jāzina, kā šo atbildi rast. Vadītājam jāspēj<br />

pieņemt jebkuru ar projektu saistītu lēmumu vai nu pašam, vai<br />

deleģējot lēmuma pieņemšanu speciālistam (piemēram, vai datu bāzei<br />

piekļūt ar ODBC vai OLE DB). Jebkurā gadījumā vadītājs ir atbildīgs<br />

<strong>par</strong> lēmuma sekām.<br />

Vadītājam, kas pats nav programmējis, ir ievērojami grūtāk vadīt programmatūras<br />

izstrādes projektu nekā cilvēkam, kas karjeru ir sācis kā programmētājs. Labi, ka<br />

projektā ir galvenais speciālists, kas pārzina teh<strong>no</strong>loģisko pusi un spēj pieņemt<br />

lēmumus, taču šādos gadījumos pastāv projekta dubultās vadības risks un vadītājam<br />

jābūt gatavam strādāt arī tādos apstākļos.<br />

Ja projekta gaitā rodas problēma, vadītājam jādomā <strong>par</strong> tās atrisināšanu – viņam<br />

jāzina, kā mainīt sistēmu, lai šādas problēmas vairs nerastos, un jāspēj mainīt sistēmu.<br />

Vadītājam ir jāzina un arī jājūt vietas, kuras varēs precizēt programmatūras izstrādes<br />

gaitā. Nav vērts censties izstrādāt 100% atbilstošu projektējumu, jo praktiski nav tādu<br />

projektu, kurus praksē izdotos pilnībā izstrādāt pēc ūdenskrituma modeļa.<br />

Jo vairāk problēmu iespējams atrisināt sarunājoties, jo profesionālāks ir vadītājs. Un<br />

otrādi – jo profesionālāks ir vadītājs, jo vairāk jautājumu var <strong>no</strong>kārtot sarunu ceļā.<br />

Pasūtītājs<br />

Ja vien tas ir iespējams, piedāvājums un cenu aprēķins jāiesniedz pasūtītājam<br />

personīgi, izskaidrojot un pamatojot savu piedāvājumu.

Jo mazāka ir sadarbības pieredze, jo vairāk jautājumu jārisina klātienes sarunās. Kad<br />

izveidots pamats ilgstošai sadarbībai, var atļauties daļu problēmu risināt pa e-pastu vai<br />

telefonu.<br />

Paralēli formālajiem pasākumiem (piemēram, izmaiņu vadības padomes), svarīgi<br />

“uztaustīt” pasūtītāja procesus pārzi<strong>no</strong>šu cilvēku vai cilvēkus, kam var uzdot<br />

jautājumus <strong>par</strong> dažādām situācijām. Ideāli, ja šis cilvēks ir arī oficiālā kontaktpersona<br />

<strong>par</strong> attiecīgajiem jautājumiem, jo var teikt, ka projekta panākumi ir proporcionāli tam,<br />

cik veiksmīgi izveidojas sadarbība ar šo cilvēku vai cilvēkiem.<br />

Pēc iespējas ātrāk vajag vizuāli <strong>par</strong>ādīt pasūtītājam iespējamo rezultātu, sākotnēji kaut<br />

vai sarunas laikā to uzskicējot uz papīra. Mūsdienu rīki ļauj ātri un viegli uzzīmēt<br />

ekrānformas, pirms uzsāk programmēt.<br />

Deleģēšana<br />

Jāprot prog<strong>no</strong>zēt darbinieka spēju veikt uzdevumu. Ja darbinieka spējas nav zināmas,<br />

tad, deleģējot tam uzdevumu, sākotnēji jāpieņem, ka darbinieks nepārzina konkrēto<br />

jomu, un uzdevums sīki un smalki jāizstāsta. Jāpārliecinās arī <strong>par</strong> deleģētā uzdevuma<br />

izpildi.<br />

Efektīvākais veids, kā pārliecināties, vai darbinieks sapratis uzdevumu, ir palūgt<br />

viņam atstāstīt, kā viņš to ir sapratis.<br />

Secinājumi<br />

Projektu vadība ir vairāku zinātņu apvie<strong>no</strong>jums, un, izstrādājot programmatūras<br />

projektus, tās ir – datorzinātne, vadība, psiholoģija, eko<strong>no</strong>mika. Mūsdienās ģeniāli<br />

atklājumi visvairāk tiek izdarīti kombinētajās zinātnēs, piemēram, klasiskajā<br />

matemātikā jaunu un ģeniālu atklājumu ir maz, toties, apvie<strong>no</strong>jot matemātiku ar fiziku<br />

un ķīmiju, tika radīti pirmie kvantu datori.<br />

Programmatūras izstrādes projektu vadība ir formalizēta pieeja apvie<strong>no</strong>jumā ar<br />

mākslu, un speciālisti visā pasaulē strādā, lai šajā jomā procentuāli palielinātu<br />

formalizēto pieeju un samazinātu māksliniecisko. Pašlaik šī procentuālā attiecība<br />

programmatūras izstrādes projektu vadības praksē, manuprāt, ir 50 pret 50. Kamēr tā<br />

nav būtiski mainījusies, tikmēr labs programmatūras izstrādes projektu vadītājs<br />

joprojām būs datorspeciālists, psihologs, eko<strong>no</strong>mists un nedaudz arī burvju<br />

mākslinieks.<br />

8.4. Efektīvas projekta komandas kontrolsaraksts<br />

Efektīvas projekta komandas kontrolsaraksts<br />

(<strong>no</strong> http://www.rspa.com/checklists/teams.html)<br />

The intent of this checklist is to assess the degree to which a software project team<br />

will work together effectively (SEPA 5/e, Chapter 3). It should be <strong>no</strong>ted that many<br />

factors affect the qualty of a team. However, the following issues should be addressed<br />

by the project manager/team leader as the team is formed. For this checklist, the more<br />

questions that elicit a negative response, the higher the risk that the team will fail.<br />

Has the team worked together before If so, were the results of past working<br />

experience favorable<br />

Do members of the team have the correct mix of k<strong>no</strong>wledge, training, and experience<br />

for the job to be done<br />

Do members of the team come from the same technical "culture" the same<br />

organization<br />

Have the roles and responsibilities of each team member been clearly defined

Have communication mechanisms for the team and with the outside world been<br />

clearly defined<br />

Do the team members have respect for the project manager the team technical<br />

leader<br />

Is the working environment (e.g., offices, meeting rooms, tools) conducive tgood<br />

teamwork<br />

Have team members been shielded from administrative record keeping<br />

Have team members been provided with appropriate support staff<br />

9.1. <strong>Konspekts</strong><br />

Tehniskā realizācija - centralizēts vai decentralizēts risinājums<br />

1. Nofiksētas:<br />

- funkcionālās prasības<br />

- nefunkcionālās prasības<br />

2. Novērtēta eko<strong>no</strong>miskā efektivitāte (<strong>par</strong>asti eko<strong>no</strong>miskā efekta (tiešā) nav). Mēdz<br />

spiest konkurence.<br />

3. Pieņemts lēmums <strong>par</strong> izstrādi.<br />

4. Jāsāk izstrāde.<br />

Homogēnas un heterogēnas sistēmas<br />

Homogēna sistēma - ja ir viena un tā pati datu bāžu pārvaldības sistēma (DBPS) (sk.<br />

1.attēls pa labi)<br />

Heterogēna sistēma - ja dažādas DBPS (sk. 1.attēls pa kreisi)<br />

1. attēls. Homogēnās un heterogēnas sistēmas piemēri.<br />

Heterogēnu sistēmu galvenā problēma - savstarpēja integrācija.<br />

Centralizētas un decentralizētas sistēmas<br />

Centralizētas sistēmas - pamatā ir tikai viena datu bāze (sk. 2.attēls pa kreisi).<br />

Decentralizēta sistēma - sastāv <strong>no</strong> vairākām datu bāzēm (sk. 2.attēls pa labi).

2.attēls. Centralizētas un decentralizētas sistēmas<br />

Piemēri:<br />

CSDD - centralizēta DB (kaut arī izvietota divās vietās - pašvaldībās reģistrē dzīves<br />

vietas, bet tās netiek pie centrālās DB).<br />

LUIS - centralizēta sistēma.<br />

Audzēkņu reģistrs (skolās) - decentralizēta sistēma (skolās - Lotus Notes, centrā -<br />

ORACLE).<br />

Ģimenes ārsti - decentralizēta sistēma (MS SQL centrā, 7 slimokases, ārstniecības<br />

iestādes).<br />

Ja nav ātra interneta pieslēguma, tad gandrīz <strong>no</strong>teikti jātaisa decentralizēta sistēma.<br />

Arī gadījumos, kad dažādos līmeņos funkcijas būtiski atšķiras, decentralizēts<br />

risinājums ir piemērotāks.<br />

Centralizētas sistēmas<br />

Decentralizētas sistēmas<br />

+ –<br />

vienkārša lietotājam,<br />

konfigurācijas vadība,<br />

konfidencialitāte,<br />

integritāte,<br />

izstrādes izmaksas<br />

pieejamība (drošības<br />

komponente)<br />

veiktspēja,<br />

izmaksas DB,<br />

pieejamība<br />

konfidencialitāte<br />

integritāte<br />

izstrādes izmaksas<br />

Ieskats vēsturē

3.attēls. Lieldatoru ēra (1980).<br />

Pēc lieldatoru ēras atnāca personālie datori - un tos ātri akceptēja, jo katrs dabūja savu<br />

datoru. Bet ātri vien sākās integrācijas problēmas, jo, piemēram, 3 grāmatvežiem bija<br />

jāapmainās ar datiem. Pēc tam izgudroja LAN tīklus, kas radīja sinhronizācijas<br />

problēmu.<br />

4.attēls. LAN struktūra.<br />

Fox programmas, lai taisītu kopsavilkumus, visi dati bija jādabū vie<strong>no</strong>ti, "jāpumpē"<br />

caur tīklu.<br />

Pēc tam <strong>par</strong>ādījās klient-servera arhitektūra - pamatrēķini <strong>no</strong>tiek uz servera, bet pa<br />

tīklu ceļo tikai pieprasījumi un rezultāti.<br />

Tātad esam loģiski turpat, pie lieldatoriska risinājuma.<br />

Rodas konflikti starp operatīviem pieprasījumiem un pieprasījumiem, kuru izpildei<br />

nepieciešami lieli resursi (piemēram, pilna pārbūve)<br />

10.1. <strong>Konspekts</strong><br />

Informācijas sistēmu drošība. Informācijas kodēšana<br />

Drošība → pieejamība (avalability) + integritāte (integrity) + konfidencialitāte<br />

(confidentiality)<br />

(saskaņā ar LVS, ISO standartiem un MK <strong>no</strong>teikumiem)<br />

Pieejamība - sistēmu var lietot tad, kad tas nepieciešams (tikai pilnvaroti lietotāji).<br />

Integritāte - iekšējā nepretrunība, informācijas pilnība un precizitāte.<br />

Konfidencialitāte - netiek klāt tie, kam tas nav <strong>par</strong>edzēts.<br />

Vai ir iespējama absolūti droša sistēma<br />

Izstrādājot sistēmu, jāizvērtē informācija, cik lielā mērā tā ir jāaizsargā.

- publiska informācija<br />

- ierobežotas pieejamības informācija (ja draud ar morāliem vai eko<strong>no</strong>miskiem<br />

zaudējumiem)<br />

- slepena informācija (saskaņā ar likumu)<br />

- sevišķi slepena informācija (datoru nedrīkst pievie<strong>no</strong>t tīklam)<br />

Pieejamība atkarīga <strong>no</strong><br />

- a<strong>par</strong>atūras un tīkla kvalitātes<br />

- programmatūras kvalitātes<br />

- rezervēšana (arī - kopēšana)<br />

- serveru klasteri (arī - spoguļošana)<br />

- dublēšana (a<strong>par</strong>ātiska)<br />

- karstā rezerve<br />

- aukstā rezerve<br />

- u.c.<br />

Integritāte atkarīga <strong>no</strong><br />

- programmatūras kvalitātes<br />

Sliktākais piemērs ar FOX, kas glabā indeksus operatīvajā atmiņā; izslēdzot un<br />

ieslēdzot datoru, viss <strong>no</strong>jūk un ir vai nu jāpārindeksē, vai arī jāatjau<strong>no</strong> <strong>no</strong> rezerves<br />

kopijām.<br />

Labs piemērs - ar WORD, kas glabā faila atvērtības pazīmi uz diska.<br />

Konfidencialitātes pārvarēšana - dabūt pieteikuma (login) vārdu, PIN kodu.<br />

Divdaļīgas <strong>par</strong>oles - maināmā publiskā daļa un nemaināma slepenā.<br />

Laba prakse - visas darbības uzglabāt auditācijas pierakstos (audit trial) nemaināmā<br />

protokola datnē - žurnālā (log)<br />

Visa informācija var tikt <strong>no</strong>klausīta pārraidot - informācija jāšifrē.<br />

Šifrēšanas atslēgas garums nepieciešams arvien garāks. Agrāk šifrētos datus pēc laika<br />

varēja viegli atšifrēt, mainīt un aizšifrēt atpakaļ.<br />

Laba risinājuma nav.<br />

Informācijas kodēšana<br />

Ieviesa personkodus.<br />

Kā izvēlas kodus<br />

a) visus objektus sanumurē - kods ļoti racionāls, bet to grūti lietot;<br />

b) pozicionālie kodi - objektus sadala sanumurētās grupās, piešķir numurus grupas<br />

iekšienē (piemēram, studentu liecības DatZ 01 0017).<br />

b' ) domēnspecifiskie kodi, kas vēsturiski izveidojušies <strong>no</strong>zarē<br />

c) lietotāja saskarnei jābūt "draudzīgai"<br />

- krāsas, izvietojums, u.tml.<br />

- uzskatāmi kodi, kas ir mnemoniski<br />

Izvēlnē piedāvā mnemoniskos kodus, bet sistēmas iekšienē lieto kodifikatora esošo,<br />

kas <strong>par</strong>asti ir garš un cilvēkam neuztverams. ER realizācijas modelī <strong>par</strong>ādās<br />

kodifikatoru kodi.

1<strong>1.1.</strong> <strong>Konspekts</strong><br />

Programmatūras prasību pamati<br />

(The Essential Software Requirements)<br />

<strong>Izmantoti</strong>e materiāli:<br />

Karl E. Wieger. “Software Requirements” – Microsoft Press, 1999, lpp. 350<br />

Lekcijas plāns<br />

Programmatūras prasību definīcijas<br />

Prasību līmeņi<br />

Darījumprasības (business requirements)<br />

Lietotāja prasības<br />

Funkcionālās prasības<br />

Nefunkcionālās prasības<br />

Kvalitātes atribūti<br />

ierobežojumi<br />

Biežākie neadekvāta prasību procesa rīki<br />

Piemērs<br />

MARIJA: „Sveiks, Fil! Šeit Marija <strong>no</strong> Personāla <strong>no</strong>daļas. Mums ir radusies problēma<br />

ar darbinieku sistēmu, kuru tu mums esi programmējis. Viena <strong>no</strong> darbiniecēm ir tikko<br />

mainījusi uzvārdu uz Startailts, savukārt sistēma neatļauj šo izmaiņu. Vai tu mums<br />

palīdzēsi”<br />

FILS: „Viņa ir apprecējusies ar Startailtu”<br />

MARIJA: „Nē, viņa nav apprecējusies, viņa vienkārši ir mainījusi savu uzvārdu,”<br />

atbild Marija. „Tā jau arī ir tā problēma. Izskatās, ka mēs varam <strong>no</strong>mainīt uzvārdu<br />

tikai tad, ja mainās cilvēka ģimenes stāvoklis”.<br />

FILS: „Nu, jā. Es nekad neesmu iedomājies, ka kāds varētu mainīt tāpat vien savu<br />

vārdu vai uzvārdu. Es neatceros, ka jūs man būtu <strong>par</strong> to kaut ko teikusi, kad mēs<br />

runājām <strong>par</strong> sistēmas funkcijām. Tieši tāpēc jūs arī nevarat tagad izsaukt logu<br />

„Uzvārda, vārda maiņa” bez ģimenes stāvokļa maiņas,” saka Fils.<br />

MARIJA: „Es domāju, ka tu zini, ka cilvēkiem ar likumu ir atļauts mainīt vārdu un<br />

uzvārdu, kad viņi to vien vēlas. Lai nu kā, mums ar šo problēmu ir jātiek galā līdz<br />

nākamai nedēļai, vai arī grāmatvedei nebūs iespējas aprēķināt viņas algu. Vai tu vari<br />

izlabot šo kļūdu”<br />

FILS: „Tā nav kļūda! Es nekad neesmu biju informēts <strong>par</strong> to, ka šāda iespēja ir<br />

vajadzīga. Es esmu aizņemts jaunas veiktspējas aprēķina sistēmas izstrādē. Cita<br />

starpā, man ir uzkrājušās arī citas izmaiņu prasības attiecībā uz darbinieku sistēmu...<br />

Jā, lūk, te ir vēl viena. Es tās abas varētu atrisināt līdz mēneša beigām, bet <strong>no</strong>teikti ne<br />

šonedēļ. Ļoti atvai<strong>no</strong>jos. Nākamreiz, lūdzu, brīdiniet mani <strong>par</strong> šādām lietām agrāk un,<br />

lūdzu, dariet to rakstveidā”.<br />

MARIJA: „Ko man teikt grāmatvedei Viņa kļūs patiesi dusmīga, ja nebūs iespējas<br />

aprēķināt šīs darbinieces algu.”<br />

FILS: „Marija, tā taču nav mana kļūda!” – protestē Fils. „Ja jūs man būtu <strong>no</strong> paša<br />

sākuma pateikusi, ka darbiniekiem jāvar mainīt uzvārdu un vārdu jebkurā laikā, tas<br />

pat nebūtu <strong>no</strong>ticis. Jūs nevarat mani apvai<strong>no</strong>t <strong>par</strong> nespēju lasīt jūsu domas”..<br />

MARIJA, dusmīgi un neapmierināti – „Jā, nu labi, šī ir <strong>no</strong> tām lietām, kuras liek man<br />

ienīst datorsistēmas. Piezvani man, tiklīdz problēma būs <strong>no</strong>vērsta”.

Ja kaut reizi esat pabijuši šīs sarunas klienta pusē, jūs zināsiet cik tas ir nepatīkami -<br />

lietot programmatūru, kas neļauj jums pildīt pamatfunkcijas. Jūs <strong>no</strong>teikti nebūtu arī<br />

apmierināti ar izstrādātāju, kurš atliek jūsu izmaiņu izpildi uz vēlāku laiku. No<br />

izstrādātāja puses, jūs zināt, cik nepatīkami ir pēkšņi pēc sistēmas ieviešanas atklāt<br />

trūkstošu funkcionalitāti, kuru lietotājs ir gaidījis. Tas ir arī nepatīkami, ja jūs traucē<br />

tādu izmaiņu pieprasījuma dēļ, kas izmaina sistēmu, kura strādā precīzi tā, kā to ir<br />

aprakstījis lietotājs.<br />

Daudzas programmatūras izstrādes problēmas ir izskaidrojamas ar trūkumiem prasību<br />

vākšanas, dokumentēšanas procesos un pieredzē. Runājot <strong>par</strong> Filu un Mariju, viņu<br />

problēma ir neoficiālas informācijas vākšana, nefiksēta vai šaubīga funkcionalitāte,<br />

neatklāti vai nepateikti pieņēmumi, neadekvāta prasību dokumentēšana un nejaušs<br />

izmaiņu procesa raksturs.<br />

Programmatūras prasību definēšana<br />

Viena <strong>no</strong> programminženierijas problēmām ir vienkāršu definīciju trūkums tiem<br />

terminiem, kurus mēs izmantojam mūsu darba aspektu aprakstam. Pasūtītāja<br />

"prasību" definīcija izstrādātājam izklausās pēc augstākā līmeņa koncepcijas.<br />

Savukārt izstrādātāja priekšstats <strong>par</strong> prasībām lietotājam var izklausīties pēc detalizēta<br />

projektējuma. Šīs ir dažādas perspektīvas un mainīgi precizitātes un detaļu līmeņi.<br />

IEEE Standard Glossary of Software Engineering Termi<strong>no</strong>logy (1997) definē prasības<br />

kā:<br />

(1) Nosacījums vai spēja, kura nepieciešama lietotājam problēmas risināšanai vai<br />

mērķu sasniegšanai.<br />

(2) Nosacījums vai spēja, kura var piemist sistēmai vai sistēmas komponentei, lai<br />

izpildītu līgumu, standartu, specifikāciju vai citu formāli obligātu dokumentu.<br />

(3) Dokumentēta (1) vai (2) formulēto <strong>no</strong>sacījumu vai spēju reprezentācija.<br />

Dažas „prasību” interpretācijas<br />

IEEE definīcija pārklāj gan lietotāja skatu uz prasībām (ārējo sistēmas uzvedību), gan<br />

izstrādātāja priekšstatu <strong>par</strong> to.<br />

Atslēgas koncepcija ietver sevī nepieciešamību dokumentēt prasības. Autors<br />

piedalījās vienā projektā, kurā iesaistītie programmētāji mainījās. Pasūtītājs bija<br />

<strong>no</strong>vests līdz asarām katru reizi, kad jaunais prasību analītiķis nāca un sludināja<br />

„Mums ir jāaprunājas <strong>par</strong> prasībām”. Pasūtītāja reakcija uz to bija „Es jau esmu jūsu<br />

priekštečiem visu izstāstījis. Uztaisiet man sistēmu !” Bet realitātē prasības netika<br />

dokumentētas, līdz ar to katrs analītiķis visu sāka <strong>no</strong> pamatiem. Sludināt, ka jums ir<br />

uzkrātas „prasības”, ir pašapmāns, ja viss, kas jums ir – ir daži e-pasti un balss pasta<br />

ziņojumi, "post-it" lapiņas, sapulces protokoli un miglainas priekšnama sarunu<br />

atmiņas.<br />

Cita definīcija saka, ka prasības ir „lietotāja vajadzību konstatējums, kurš izraisa<br />

programmas vai sistēmas izstrādi” (Jones 1994). Prasību specificēšanas autoritāte<br />

Alans Daviss (1993) paplašina šo koncepciju līdz „lietotāju vajadzības vai<br />

nepieciešamas sistēmas pazīmes, funkcijas vai atribūti, kuras var just <strong>no</strong> ārpus

sistēmas pozīcijas”. Šīs definīcijas uzsver, ko produkts ietvers, nevis kā produkts tiks<br />

uzprojektēts un konstruēts. Nākamā definīcija iet dziļāk <strong>no</strong> lietotāju vajadzību spektra<br />

līdz sistēmas raksturīpašībām (Sommerville un Sawyer 1997):<br />

Prasības ir... specifikācija, kurā ir teikts kas ir jāievieš. Tie ir apraksti kā sistēmai ir<br />

jāuzvedas, kādas ir sistēmas īpašības un atribūti. Tās var kalpot arī kā ierobežojums<br />

sistēmas izstrādes procesā.<br />

Šīs atšķirīgās definīcijas <strong>no</strong>rāda uz termina „prasības” neskaidrību un nepārprotamas<br />

izpratnes trūkumu. Īstas prasības patiesībā atrodas cilvēku galvās. Jebkura prasību<br />

dokumentēta forma (kā, piemēram, prasību specifikācija) ir tikai modelis vai<br />

reprezentācija (Lawrence 1998). Mums nepieciešams pārliecināties, ka visām projektā<br />

ieinteresētām pusēm ir līdzīga terminu izpratne, aprakstot prasības.<br />

Prasību līmeņi<br />

Formulēsim definīcijas, kas apraksta dažus ar prasību inženieriju saistītus terminus.<br />

Programmatūras prasības ietver trīs skaidrus līmeņus – darījumprasības, lietotāju<br />

prasības un funkcionālās prasības – kā arī dažādas nefunkcionālas prasības.<br />

Darījumprasības ir augstāka līmeņa organizācijas vai pasūtītāja mērķu reprezentācija,<br />

kuru realizāciju <strong>par</strong>edz sistēma. Šīs prasības tiek uzkrātas speciālā projekta vīzijas vai<br />

aptvēruma (scope) dokumentā. Lietotāju prasības apraksta lietotājiem nepieciešamus<br />

uzdevumus, kuri ir jārealizē sistēmā. Tās tiek ietvertas lietošanas piemēru vai<br />

scenāriju aprakstos. Funkcionālas prasības definē programmatūras funkcionalitāti,<br />

kura izstrādātājiem ir jārealizē, lai lietotāji varētu pildīt savus uzdevumus, turklāt<br />

apmieri<strong>no</strong>t darījumprasības. Iezīme (feature) ir loģiski saistīto funkcionālo prasību<br />

kopa, kura <strong>no</strong>drošina lietotājam iespēju un apmierina darījumprasības. 1. attēls <strong>par</strong>āda<br />

dažas <strong>no</strong> šīm komponentēm.<br />

1.attēls. Attiecības starp dažādām programmatūras prasību komponentēm

Funkcionālās prasības tiek dokumentētas programmatūras prasību specifikācijā – PPS<br />

(Software Requirements Specification – SRS), kas pēc iespējas precīzāk un pilnīgāk<br />

apraksta sagaidāmo ārējo sistēmas uzvedību. PPS tiek izmantota izstrādē, testēšanā,<br />

kvalitātes <strong>no</strong>drošināšanā, projekta pārvaldībā un saistītajās projekta funkcijās.<br />

Sarežģītam programmproduktam programmatūras funkcionālām prasībām jābūt<br />

sistēmas prasību apakškopai, ja tādas ir. Papildus funkcionālām prasībām, kas<br />

apraksta sistēmas uzvedību un tās veicamās operācijas, PPS satur arī nefunkcionālās<br />

prasības. Tām jāsatur standarti, <strong>no</strong>teikumi un vie<strong>no</strong>šanās, kurām produktam ir<br />

jāatbilst, kā arī ārējo saskarņu aprakstus, veiktspējas prasības, projektējuma un<br />

ieviešanas <strong>no</strong>teikumus un kvalitātes atribūtus. Ierobežojumi tiek doti izstrādātājiem<br />

tad, kad sistēmas konstrukcijā iespējami varianti. Kvalitātes atribūti paplašina<br />

produkta funkcionalitātes aprakstu, papildi<strong>no</strong>t to ar produkta raksturiezīmēm, kuras ir<br />

svarīgas lietotājiem vai izstrādātājiem.<br />

Dažādu prasību piemērs. Izstrādājamā sistēma – teksta redaktors.Darījumprasības<br />

varētu skanēt šādi - „Lietotājiem jābūt iespējai efektīvi izlabot dokumenta<br />

<strong>par</strong>eizrakstības kļūdas”. Gramatisko kļūdu labotājs varētu būt iezīme (feature), kura<br />

tiek iestrādāta programmā un kura apmierina darījumprasības. Sekojot lietotāju<br />

prasībām, prasības var tikt papildinātas ar šādu apgalvojumu (lietošanas piemēru):<br />

„Atrast dokumentā <strong>par</strong>eizrakstības kļūdas un izlemt, vai jāveic katras pārrakstīšanās<br />

aizvietošana ar vienu <strong>no</strong> piedāvātiem <strong>par</strong>eiziem variantiem”. Gramatisko kļūdu<br />

labotājam var būt daudz individuālo funkcionālo prasību, kuras <strong>no</strong>saka operācijas, kā,<br />

piemēram, ne<strong>par</strong>eizo vārdu meklēšana un izcelšana, piedāvāto <strong>par</strong>eizo variantu<br />

attēlošana un vispārējas aizvietošanas veikšana.<br />

Vadībai vai tirgvedības speciālistiem ir jādefinē programmatūras darījumprasības,<br />

kuras palīdzēs viņu organizācijai strādāt efektīvāk (informācijas sistēmām) vai<br />

veiksmīgi iekarot tirgu (komerciāliem programmatūras produktiem). Visām lietotāju<br />

prasībām ir jābūt saskaņotām ar darījumprasībām. Lietotāju prasības ļauj prasību<br />

analītiķim izsecināt lietotāju uzdevumu izpildei nepieciešamo funkcionalitāti.<br />

Izstrādātāji lieto funkcionālās prasības risinājumu projektēšanā un izstrādē, līdz ar to<br />

ieviešot nepieciešamo funkcionalitāti. Ievērojiet, ka prasības atbilstoši šīm definīcijām<br />

nesatur projektējuma un implementēšanas detaļas, projekta plā<strong>no</strong>šanas vai testēšanas<br />

informāciju. Šiem aprakstiem jābūt atdalītiem <strong>no</strong> prasībām, lai prasību aktivitātes<br />

varētu koncentrēties uz izstrādājamās sistēmas izzināšanu. Projektos var gadīties arī<br />

citu veidu prasības, kā, piemēram, izstrādes vides prasības vai prasības pret produkta<br />

versiju attīstību.<br />

Kad sliktas prasības gadās ar labiem cilvēkiem<br />

Projekta komandas, kuras nevērīgi izturas pret prasību procesiem, apdraud pašas sevi.<br />

Nepilnības prasību inženierijā velk aiz sevis virkni risku, kuri apdraud projekta<br />

veiksmi, kur „veiksme” var būt definēta kā tāda produkta piegāde, kurš apmierina<br />

lietotāju ieceres <strong>par</strong> tā funkcionalitāti un kvalitāti, pie tam savlaicīgi un <strong>par</strong> <strong>no</strong>runāto<br />

cenu. Daži <strong>no</strong> šiem riskiem ir aprakstīti zemāk.<br />

No neatbilstoša prasību procesa izrietošie riski.<br />

No nepietiekamas lietotāju iesaistīšanas izriet nepieņemams produkts.

"Peldošas" (bieži mainītas) lietotāju prasības izsauc laika pārtēriņu un produkta<br />

kvalitātes pazemināšanu.<br />

Neskaidras prasības <strong>no</strong>ved līdz neefektīvi izmantotam laikam un pārstrādei.<br />

Pārāk liela slīpēšana un izskaistināšana <strong>no</strong> izstrādātāju un lietotāju puses pievie<strong>no</strong><br />

produktam nevajadzīgas iezīmes.<br />

Minimālas prasības <strong>no</strong>ved līdz svarīgu prasību trūkumam.<br />

Noteiktu lietotāju grupu prasību izlaišana rada pasūtītāju neapmierinātību.<br />

Nepilnīgi definētas prasības padara neiespējamu projekta precīzu plā<strong>no</strong>šanu un<br />

izsekošanu.<br />

12.1. <strong>Konspekts</strong><br />

Programmatūras prasību pamati<br />

(The Essential Software Requirements)<br />

<strong>Izmantoti</strong>e materiāli:<br />

Karl E. Wieger. “Software Requirements” – Microsoft Press, 1999, lpp. 15-35<br />

Lekcijas plāns<br />

Teicamu prasību raksturojums<br />

Prasību specifikācijas raksturojums<br />

Prasību izstrāde un pārvaldība<br />

Prasības <strong>no</strong> pasūtītāja perspektīvas<br />

Kas ir pasūtītājs<br />

Programmatūras pasūtītāju tiesības<br />

Programmatūras pasūtītāju pienākumi<br />

Kādas saistības izriet <strong>no</strong> prasību specifikācijas <strong>par</strong>akstīšanas<br />

Teicamu prasību raksturojums<br />

Kādā veidā var atšķirt labas programmatūras prasību specifikācijas (PPS; angliski -<br />

Software Requirements Specification, SRS) <strong>no</strong> problemātiskām<br />

Uzmanīga PPS apskate (review) <strong>no</strong> projektā iesaistītām pusēm, reprezentējot dažādus<br />

skatupunktus, ir labākais veids, lai pārbaudītu, vai prasības atbilst visiem<br />

nepieciešamiem raksturlielumiem. Ja, formulējot un apskatot prasības, patur prātā<br />

zemāk uzskaitītos raksturlielumus (characteristics),<br />

<strong>par</strong>asti izdodas uzlabot prasību dokumentus un izstrādāt labākus programmproduktus.<br />

Prasību pārskata raksturlielumi<br />

· Pabeigtība (Complete)<br />

Katrai prasībai ir pilnīgi jāapraksta piegādājamā funkcionalitāte. Tai jāsatur visu<br />

nepieciešamu informāciju, lai izstrādātājs varētu šo funkcionalitāti uzprojektēt un<br />

implementēt.<br />

· Pareizība (Correct)<br />

Katrai prasībai ir rūpīgi jāapraksta iestrādājamā funkcionalitāte. Pareizības etalons ir<br />

prasību avots, kā, piemēram, pasūtītāja vai augstāka līmeņa sistēmas prasību<br />

specifikācija. Programmatūras prasība, kas ir pretrunā ar atbilstošo sistēmas prasību,

ir ne<strong>par</strong>eiza. Tikai lietotāju pārstāvji var <strong>no</strong>vērtēt lietotāju prasību <strong>par</strong>eizību, tieši šī<br />

iemesla dēļ ir ļoti svarīgi iesaistīt gala lietotājus prasību apskatēs. Prasību apskatēs,<br />

kurās nepiedalās lietotāji, iesaistītie dalībnieki var prātot - „Tas nav saprotams, bet<br />

laikam jau ir tas, ko viņi gribēja”. Tā ir minēšana uz labu laimi.<br />

· Iespējamība (Feasible)<br />

Ir jābūt drošai iespējai katru prasību implementēt iecerētajā sistēmā un tās vidē,<br />

ņemot vērā <strong>no</strong>teiktos ierobežojumus. Lai izvairītos <strong>no</strong> neiespējamām prasībām,<br />

prasību vākšanas procesā ieteicams iesaistīt papildus tirgvedības vai prasību<br />

analītiķim arī programmatūras izstrādes komandas dalībnieku. Šis cilvēks var<br />

<strong>no</strong>drošināt iespējamības pārbaudi – ko var un ko nevar tehniski realizēt, kā arī kuru<br />

prasību implementācija prasīs pārmērīgi lielus laika un materiālos resursus.<br />

· Nepieciešamība (Necessary)<br />

Katrai prasībai ir jādokumentē kaut kas lietotājam tiešām vajadzīgs vai arī kaut kas,<br />

kas ir nepieciešams ārējo sistēmu prasību vai standartu atbilstībai. Prasības rodas <strong>no</strong><br />

zināmiem avotiem, daži <strong>no</strong> tiem ir ar lielāku autoritāti. Prasības atkārtoti jāsalīdzina ar<br />

informāciju <strong>no</strong> citiem avotiem, piemēram, <strong>no</strong> vairākiem lietošanas piemēriem (use<br />

case).<br />

· Prioritizējamība (Prioritized)<br />

Visas prasības, funkcionalitātes un lietošanas piemēri jāsakārto pa prioritātēm, lai<br />

<strong>no</strong>vērtētu, cik svarīga ir šo prasību realizācija dotajā izstrādes versijā. Ja<br />

visām prasībām tiktu <strong>no</strong>teikta vienādi augsta prioritāte, projekta pārvaldniekam trūks<br />

brīvības, reaģējot uz jaunām prasībām, kuras nāks klāt izstrādes laikā, kā arī uz<br />

budžeta samazinājumu, laika pārtēriņu vai projekta personāla pietrūkumu.<br />

· Skaidrība (Unambiguous)<br />

Visiem prasību dokumenta lasītājiem ir jāvie<strong>no</strong>jas <strong>par</strong> vie<strong>no</strong>tu, konsekventu to<br />

interpretāciju. Dažreiz izteikumu izvēle var <strong>no</strong>vest pie divdomības, tāpēc prasības ir<br />

svarīgi izklāstīt vienkāršā, kodolīgā valodā, kuru saprot lietotāji, nevis tikai<br />

datorspeciālisti. Jāievieš prasību dokumentu apskates procedūra, rakstot testa<br />

piemērus, izstrādājot prototipus un izgudrojot specifiskus izmantošanas scenārijus, lai<br />

efektīvi panāktu izteiksmes vienkāršību.<br />

· Verificējamība jeb pārbaudāmība (Verifiable)<br />

Jāizpēta visas prasības, lai redzētu, vai ir iespējas pārbaudīt to <strong>par</strong>eizību pēc produkta<br />

ieviešanas, veicot nelielu testu skaitu vai ar citu pārbaudes pieeju palīdzību, kā,<br />

piemēram, apskatēm vai demonstrāciju. Ja prasība ir nepārbaudāma, pierādīt to, ka tā<br />

ir <strong>par</strong>eizi iestrādāta, kļūst <strong>par</strong> viedokļa jautājumu un izslēdz objektīvu analīzi.<br />

Nepārbaudāmas ir arī pretrunīgās, nesaskanīgās, nepierādāmās vai neskaidrās<br />

prasības.<br />

Prasību specifikācijas raksturojums<br />

· Pabeigtība (Complete)<br />

Nedrīkst pietrūkt kādu prasību vai nepieciešamas informācijas. Trūkstošas prasības ir<br />

grūti pamanīt, jo tās ir neredzamas. Koncentrējoties uz lietotāju uzdevumiem vairāk<br />

nekā uz sistēmas funkcijām, var izvairīties <strong>no</strong> nepilnības. Ja zināms <strong>par</strong> <strong>no</strong>teiktas

informācijas trūkumu, jābūt apņēmībai šo trūkumu <strong>no</strong>vēršanā vēl līdz konstruēšanas<br />

uzsākšanai.<br />

· Nepretrunība (Consistent)<br />

Neviena prasība nedrīkst <strong>no</strong>nākt pretrunā ar citām programmatūras vai augstāka<br />

līmeņa (sistēmas vai darījumu (business)) prasībām. Visām pretrunām starp prasībām<br />

ir jābūt atrisinātām pirms izstrādes procesa. Katras prasības <strong>par</strong>eizību var atklāt, tikai<br />

veicot mērķtiecīgu izpēti.<br />

· Maināmība (Modifiable)<br />

Ir jābūt iespējai pārskatīt PPS, ja tas ir nepieciešams, un uzturēt detalizētu prasību<br />

izmaiņu vēsturi. Tas prasa, lai katra prasība būtu unikāli apzīmēta (marķēta/numurēta)<br />

un atdalīta <strong>no</strong> citu prasību apraksta, lai uz to varētu vien<strong>no</strong>zīmīgi un skaidri<br />

atsaukties. Katrai prasībai ir PPS jā<strong>par</strong>ādās tikai vienu reizi, pretējā gadījumā, ieviešot<br />

izmaiņas, ir ļoti vienkārši pieļaut kļūdu, izmai<strong>no</strong>t prasības tikai vienā vietā. PPS<br />

izmaiņu ieviešanu vienkāršos satura tabulas, indekss un šķērsatsauces.<br />

· Trasējamība (Traceable)<br />

Jābūt iespējai sasaistīt katru <strong>no</strong> programmatūras prasībām ar tās avotu un tās<br />

projektējuma elementiem, pirmkodu un testpiemēriem, kuri kalpo kā pārbaude<br />

prasību izpildes <strong>par</strong>eizībai. Trasējamas prasības ir unikāli apzīmētas<br />

(marķētas/numurētas) un ir izklāstītas strukturētā, „smalkgraudainā” veidā, pretēji<br />

neskaidrām, plašām rindkopām.<br />

Prasību izstrāde un pārvaldība<br />

Sajukums prasību termi<strong>no</strong>loģijā attiecas arī uz šīs disciplīnas <strong>no</strong>saukumu. Daži autori<br />

sauc šo procesu „prasību inženierija” (requirements engineering), kamēr citi to sauc<br />

<strong>par</strong> prasību pārvaldību (requirements management). Mēs sadalīsim programmatūras<br />

prasību inženierijas procesus divās daļās – „prasību izstrāde” un „prasību pārvaldība”,<br />

kā ir <strong>par</strong>ādīts 1. attēlā.<br />

1.attēls. Hierarhiskā prasību inženierijas sfēras dekompozīcija.<br />

Prasību izstrāde var būt sīkāk sadalīta, ietverot prasību <strong>no</strong>skaidrošanu, analīzi,<br />

specificēšanu un pārbaudi. Šie apakšprocesi aptver visas aktivitātes, kas saistītas ar<br />

programmatūras prasību vākšanu, <strong>no</strong>vērtēšanu un dokumentēšanu. Prasību izstrādes<br />

aktivitātes ir šādas.<br />

Sagaidāmo programmprodukta lietotāju identificēšana un grupēšana<br />

Katras lietotāju grupas vajadzību <strong>no</strong>skaidrošana

Patieso lietotāju uzdevumu un mērķu, kā arī darījumu (business) vajadzību šo<br />

uzdevumu veikšanai izzināšana<br />

No lietotājiem saņemtās informācijas analīze, atšķirot viņu uzdevumu vajadzības <strong>no</strong><br />

funkcionālo prasību, darījumu <strong>no</strong>teikumu, kvalitātes atribūtu un ieteikto risinājumu<br />

viedokļa<br />

Sistēmas līmeņa prasību sadalīšana galvenajās apakšsistēmās un šo prasību<br />

piekārtošana katrai <strong>no</strong> programmatūras komponentēm<br />

Kvalitātes atribūtu svarīguma saprašana<br />

Implementēšanas prioritāšu apspriešana<br />

Ievākto lietotāju vajadzību pārvēršana rakstītajās specifikācijās un modeļos<br />

Prasību specifikāciju apskates ar mērķi pārliecināties, ka visas prasības tikušas <strong>par</strong>eizi<br />

saprastas un uzskaitītas, un izlabot visas problēmas pirms izstrādes uzsākšanas.<br />

Prasību pārvaldība <strong>no</strong>zīmē „<strong>no</strong>dibināt un uzturēt vie<strong>no</strong>ša<strong>no</strong>s ar pasūtītāju <strong>par</strong><br />

programmatūras projekta prasībām”. Šī vie<strong>no</strong>šanās tiek „iemiesota” rakstītajās<br />

prasību specifikācijas un modeļos. Pasūtītāja piekrišana ir tikai puse <strong>no</strong> prasību<br />

apstiprināšanas "vienādojuma". Izstrādātājiem arī tās ir jāapstiprina un<br />

jāiestrādā programmproduktā. Visbiežāk prasību pārvaldība ietver šādas aktivitātes.<br />

Prasību vadlīniju definēšana<br />

Ierosināto prasību izmaiņu apskates un to ietekmes <strong>no</strong>vērtēšana pirms katras <strong>no</strong>teiktas<br />

prasības apstiprināšanas<br />

Apstiprināto prasību izmaiņu iekļaušana un vadība<br />

Projekta plānu un prasību aktualitātes uzraudzība<br />

Jaunu saistību apspriešana, kuras izriet <strong>no</strong> prasību izmaiņu ietekmes <strong>no</strong>vērtējuma<br />

Individuālo prasību trasēšana uz atbilstošo projektējumu, pirmkodu un testpiemēriem<br />

Prasību statusa un izmaiņu aktivitāšu izsekošana visa projekta garumā<br />

2. attēls <strong>par</strong>āda citu skatu uz atšķirību starp prasību izstrādi un prasību pārvaldību.

2.attēls. Robeža starp prasību izstrādi un pārvaldību.<br />

Prasības <strong>no</strong> pasūtītāja perspektīvas<br />

Piemērs<br />

Džerards, "Contoso Pharmaceuticas" vecākais pārvaldnieks tiekas ar Sintiju,<br />

"Contoso" informācijas sistēmas izstrādes grupas jau<strong>no</strong> pārvaldnieci. „Mums ir<br />

nepieciešams izstrādāt ķīmisko vielu izsekošanas informācijas sistēmu "Contoso"<br />

vajadzībām,” iesāk Džerards. „Sistēmai jāļauj mums uzkrāt datus <strong>par</strong> ķīmiskām<br />

vielām, kuras atrodas fondā vai konkrētās laboratorijās. Tādējādi ķīmiķi varētu iegūt<br />

to, kas viņiem nepieciešams, <strong>no</strong> fondā jau esošām vielām tā vietā, lai pirktu<br />

katru reizi jaunas. Veselības un drošības de<strong>par</strong>tamentam arī būtu jādod iespēja veidot<br />

dažus pārskatus federālai valdībai <strong>par</strong> ķīmisko vielu izmantošanu.<br />

Vai jūsu grupa var to realizēt piecos mēnešos, lai sistēma strādātu mūsu pirmā finansu<br />

audita laikā”<br />

„Es saprotu, Džerard, kāpēc šis projekts ir tik svarīgs”, saka Sintija. „Bet pirms es<br />

varu kaut ko pateikt <strong>par</strong> termiņiem, mums ir jāveic prasību analīze jūsu<br />

sistēmai”.<br />

Džerards samulsis - „Ko jūs ar to gribat pateikt Es esmu tikko jums visu izstāstījis”.<br />

„Patiesībā jūs esat aprakstījis koncepciju un dažus projekta mērķus”, paskaidro<br />

Sintija. „Šīs ir augstākā līmeņa darījumprasības, kuras nedod man<br />

pietiekami daudz detaļu, lai pateiktu, kādu programmatūru jums nepieciešams<br />

izstrādāt un cik ātri to varētu paveikt. Man nepieciešams vismaz pāris reizes<br />

satikties ar ķīmiķiem, lai saprastu viņu prasības pret sistēmu. Tad mēs varēsim<br />

izdomāt vajadzīgo funkcionalitāti, lai apmierinātu gan jūsu mērķus, gan<br />

lietotāju vajadzības. Varbūt jums nemaz nevajag jaunu sistēmu, lai eko<strong>no</strong>mētu naudu<br />

uz ķīmiskām vielām”.<br />

Džerards nekad nebija saskāries ar šādu reakciju <strong>no</strong> programmatūras izstrādes cilvēka.<br />

„Ķīmiķi ir aizņemti cilvēki," viņš protestē. „Viņiem nav laika izklāstīt jums katru<br />

detaļu, pirms jūs varēsiet sākt programmēt. Vai jūsu cilvēki nevar paši izdomāt, ko<br />

izstrādāt”<br />

Sintija mēģina paskaidrot viņas nepieciešamību prasību vākšanai tieši <strong>no</strong> cilvēkiem,<br />

kuri izmantos jau<strong>no</strong> sistēmu: „Ja mēs pēc vislabākās apziņas minēsim,<br />

ko vajag lietotājiem, mēs nevaram paveikt labu darbu. Mēs esam programmatūras<br />

izstrādātāji, nevis ķīmiķi. Mēs īsti pat nezinām, ko ķīmiķiem vajag, lai<br />

atsekotu ķīmiskās vielas laboratorijās. Mūsu pieredze saka, ka, iesākot darbu pirms<br />

problēmas saprašanas, neviens nav apmierināts ar rezultātiem”.<br />

„Labi, mums tam visam nav laika,” uzstāj Džerards. „Es jums esmu iedevis prasības.<br />

Tagad, lūdzu, vienkārši izstrādājiet sistēmu. Un informējiet mani <strong>par</strong><br />

projekta gaitu”.<br />

Šāda veida sarunas programmatūras izstrādes jomā <strong>no</strong>tiek regulāri. Pasūtītāji, kas<br />

pieprasa jaunu informācijas sistēmu, bieži nesaprot gala lietotāju iesaistīšanas<br />

svarīgumu. Tirgvedības speciālisti ar brīnišķīgu jaunas sistēmas koncepciju var<br />

iedomāties, ka viņi ļoti labi reprezentēs pasūtītāja intereses. Diemžēl patieso gala<br />

lietotāju intervēšanai aizstājēja nav. Viens pētījums, kurā tika apskatīti 8380 projekti,<br />

atklāja, ka divi galvenie projektu neveiksmes iemesli ir lietotāju neiesaistīšana un<br />

nepilnīgas prasības un specifikācijas.

Daļa <strong>no</strong> problēmas, kas saistīta ar prasībām, ceļas <strong>no</strong> sajukuma, aprakstot dažāda<br />

līmeņa prasības: darījumprasības, lietotāju un funkcionālās prasības. Džerards<br />

izklāstīja dažas darījumprasības, bet viņš nevarēja aprakstīt lietotāja prasības, jo nav<br />

sistēmas potenciālais lietotājs. Patiesie lietotāji var aprakstīt uzdevumus, kurus viņiem<br />

būs jāpilda ar sistēmas palīdzību, bet viņi nevar identificēt visas specifiskas<br />

funkcionālās prasības, kuras ir jāievieš šo uzdevumu izpildei.<br />

Kas ir pasūtītājs<br />

Plašā <strong>no</strong>zīmē pasūtītājs ir persona vai organizācija, kura iegūst tiešu vai netiešu<br />

labumu <strong>no</strong> produkta. Programmatūras pasūtītāji ir projektā ieinteresētas puses, kuras<br />

pasūta, maksā, izvēlas vai izmanto programmatūras produktu, vai kuri saņem<br />

rezultātus <strong>no</strong> produkta izmantošanas.<br />

Džerards reprezentē tādu pasūtītāju, kurš projektu iniciē un apmaksā. Džerarda līmeņa<br />

pasūtītāji ir atbildīgi <strong>par</strong> darījumprasību precizēšanu. Viņi <strong>no</strong>drošina augstākā līmeņa<br />

koncepciju un ar darījumiem saistītā virziena uzdošanu. Kā jau bija aprakstīts,<br />

darījumprasības apraksta mērķus, kurus pasūtītājs, organizācija vai citas ieinteresētās<br />

puses grib sasniegt, vai arī vērtības, kuras viņi vēlas saņemt <strong>no</strong> sistēmas.<br />

Darījumprasības <strong>no</strong>drošina vadošo uzbūvi visa projekta garumā. Visa pārējā<br />

informācija, kura tiek uzskatīta <strong>par</strong> prasībām, tiek saskaņota ar darījumprasībām, tāpat<br />

kā katra iestrādāta funkcionalitāte. Tomēr darījumprasības ne<strong>no</strong>drošina pietiekamu<br />

detalizāciju, lai izstrādātājs zinātu, ko veidot.<br />

Nākamais prasību līmenis – lietotāju prasības. Tām ir jābūt iegūtām <strong>no</strong> cilvēkiem,<br />

kuri izmantos produktu pašu rokām. Šie lietotāji (bieži saukti <strong>par</strong> gala lietotājiem)<br />

tādējādi veido citu programmatūras pasūtītāju veidu. Lietotāji apraksta uzdevumus,<br />

kurus viņi pildīs ar programmatūras palīdzību, kā arī nefunkcionālus raksturlielumus,<br />

kuri ir svarīgi, lai produktu akceptētu.<br />

Tie pasūtītāji, kuri <strong>no</strong>drošina darījumprasības, dažreiz liecinās lietotāju vietā, bet<br />

visbiežāk viņi ir pārāk tālu <strong>no</strong> patiesiem izstrādātāju uzdevumiem, lai izklāstītu<br />

precīzas prasības. Informācijas sistēmas, līguma vai individuāla lietojuma izstrādē<br />

darījumprasībām ir jānāk <strong>no</strong> personām, kurām ir nauda, kamēr lietotāju prasībām ir<br />

jānāk <strong>no</strong> personām, kuras "spaidīs produkta pogas".<br />

Diemžēl abu pasūtītāju veidu pārstāvji var uzskatīt, ka viņiem nav laika strādāt ar<br />

prasību analītiķiem, kuri vāc, analizē un dokumentē prasības. Dažreiz pasūtītāji<br />

sagaida <strong>no</strong> analītiķiem vai izstrādātājiem izpratni <strong>par</strong> to, kas ir vajadzīgs lietotājiem,<br />

bez ilgām diskusijām un dokumentēšanas. Ja vien tas būtu tik vienkārši. Ja<br />

jpasūtītājam ir <strong>no</strong>pietna attieksme pret projekta veiksmi, ir jāsaprot, ka laiks, kad<br />

programmētājiem pa durvju spraugu tika piegādātas miglainas prasības un picas<br />

kastes, ir beidzies.<br />

Komerciālo sistēmu izstrāde (gatavo programmproduktu pārdošanai), kurā pasūtītājs<br />

ir reizē arī lietotājs, ir nedaudz atšķirīga. Pasūtītāju aizstājējs, kā, piemēram,<br />

tirgvedības de<strong>par</strong>taments, var mēģināt <strong>no</strong>teikt, kādu programmatūras produktu pircējs<br />

vēlēsies iegādāties. Tomēr arī komerciālo sistēmu izstrādē ir jāiesaista patiesus<br />

lietotājus prasību vākšanas procesā.

Programmatūras pasūtītāju tiesības<br />

Pasūtītājam ir tiesības:<br />

1. Sagaidīt, ka analītiķis runās pasūtītāja valodā.<br />

2. Sagaidīt, ka analītiķi apgūs organizācijas darījumus un sistēmas mērķus.<br />

3. Sagaidīt, ka analītiķis fiksēs prasību vākšanas procesa laikā iegūto informāciju<br />

programmatūras prasību specifikācijā.<br />

4. Sagaidīt <strong>no</strong> izstrādātājiem izskaidrojumu <strong>par</strong> prasību vākšanas darba rezultātiem.<br />

5. Sagaidīt <strong>no</strong> izstrādātājiem cieņu un profesionālu attieksmi pret sadarbību visas<br />

saskarsmes laikā.<br />

6. Sagaidīt <strong>no</strong> izstrādātājiem idejas un alternatīvus risinājumus gan prasībām, gan to<br />

ieviešanai.<br />

7. Sagaidīt programmprodukta īpašību raksturojumu, kurš padarīs tā lietošanu<br />

vieglu un patīkamu.<br />

8. Sagaidīt iespēju pielāgot prasības turpmākai esošo programmatūras komponenšu<br />

atkalizmantošanai.<br />

9. Būt <strong>no</strong>drošinātiem prasību izmaiņu gadījumos ar godīgu izmaksu un ietekmes<br />

<strong>no</strong>vērtējumu, kā arī kompromisiem.<br />

10. Saņemt sistēmu, kura apmierina funkcionālas un kvalitātes vajadzības tādā<br />

līmenī, kādā tās bija izklāstītas un akceptētas.<br />

Programmatūras pasūtītāju pienākumi<br />

Pasūtītājam ir pienākums:<br />

1. Izglītot analītiķus savā darījumu sfērā un definēt darījumu žargonu.<br />

2. Pavadīt pietiekamu laiku prasību izklāstīšanai, precizēt prasības un atkārtoti<br />

atjaunināt tās.<br />

3. Būt konkrētam un precīzam prasību izskaidrošanas laikā.<br />

4. Savlaicīgi (ātri) pieņemt lēmumus <strong>par</strong> prasībām, ja tas ir nepieciešams.<br />

5. Cienīt izstrādātāja prasību izmaksu un iespējamības <strong>no</strong>vērtējumu.<br />

6. Noteikt individuālo prasību, sistēmas funkcionalitāšu un lietošanas piemēru<br />

prioritātes.<br />

7. Veikt prasību dokumentācijas un prototipu apskates.<br />

8. Informēt <strong>par</strong> projekta prasību izmaiņām, cik ātri vien iespējams.<br />

9. Sekot projekta izstrādes organizācijas vadlīnijām, piesakot izmaiņu pieprasījumus.<br />

10. Cienīt izstrādātāju lietotus prasību inženierijas procesus<br />

Kādas saistības izriet <strong>no</strong> prasību specifikācijas <strong>par</strong>akstīšanas<br />

Viens <strong>no</strong> svarīgākiem pasākumiem pasūtītāja un izstrādātāja attiecībās ir panākt<br />

izstrādājamā produkta prasību apstiprinājumu. Daudzas organizācijas praktizē prasību<br />

specifikācijas <strong>par</strong>akstīšanu kā liecību prasību apstiprinājumam. Ir svarīgi, lai visi<br />

apstiprināšanas procesa dalībnieki zinātu, <strong>par</strong> ko viņi <strong>par</strong>akstās un kādas saistības tas<br />

uzliek.<br />

Viena problēma ir pasūtītāja pārstāvis, kurš uzskata prasību <strong>par</strong>akstīšanu <strong>par</strong><br />

bezjēdzīgu rituālu: „Man bija dota lapa, uz kuras bija uzdrukāts mans vārds ar<br />

<strong>par</strong>aksta vietu. Es to <strong>par</strong>akstīju, jo citādi izstrādātāji neuzsāktu programmēšanu”. Šāda<br />

attieksme var <strong>no</strong>vest līdz konfliktiem, kad pasūtītājs vēlas izmainīt vai papildināt

prasības, vai arī brīnās <strong>par</strong> to, kas ir piegādāts: „Protams, es <strong>par</strong>akstījos zem prasībām,<br />

bet man nebija laika tās izlasīt. Es jums uzticējos, bet jūs mani piemānījāt!”<br />

Tikpat problemātiska ir situācija, kad izstrādes vadītājs uzlūko <strong>par</strong>akstīšanas procesu<br />

<strong>par</strong> prasību negrozāmu iesaldēšanu. Kad <strong>par</strong>ādās izmaiņu pieprasījumi, viņš uzrāda<br />

PPS un protestē pret tiem: „Bet jūs esat <strong>par</strong>akstījuši šīs prasības, tieši to mēs arī<br />

izstrādājām. Ja jūs gribējāt kaut ko citu, jums vajadzēja toreiz to teikt”.<br />

Abas šīs attieksmes ir pretrunā ar reālo dzīvi – ir neiespējami zināt absolūti visas<br />

prasības projekta sākumā, kā arī nedrīkst uzskatīt, ka prasības paliks pilnīgi<br />

nemainīgas laika gaitā. Prasību <strong>par</strong>akstīšana iezīmē prasību izstrādes procesa beigas.<br />

Tomēr dalībniekiem ir precīzi jāsaprot, ko <strong>no</strong>zīmē viņu <strong>par</strong>aksti uz prasību<br />

dokumenta.<br />

Vēl svarīgāk <strong>par</strong> <strong>par</strong>akstīšanas procesu ir <strong>no</strong>dibināt prasību apstiprināšanas vadlīniju<br />

kā fiksāciju kādā <strong>no</strong>teiktā laika brīdī. Tādējādi <strong>par</strong>akstu uz prasību specifikācijas ir<br />

jātulko kā „Es piekrītu, ka šis dokuments labākā veidā reprezentē mūsu<br />

programmatūras prasību izpratni šodien. Turpmākās izmaiņas var <strong>no</strong>tikt tikai saskaņā<br />

ar projektā definēto izmaiņu procesu. Es saprotu, ka apstiprinātas izmaiņas var<br />

pieprasīt papildus izmaksas, resursus un laika grafika saskaņošanu”.<br />

Šī procesa izpratne palīdzēs situācijās, kad, projektam attīstoties, atklāsies jaunas,<br />

negaidītas izmaiņas vai izmainīsies pasūtītāja tirgus vai darījumu pieprasījums.<br />

Sākotnējo prasību <strong>par</strong>akstīšana palīdzēs veiksmīgi pārvaldīt turpmākās pasūtītājaizstrādātāja<br />

attiecības.<br />

12.2. Programmatūras prasību specifikācijas kontrolsaraksts<br />

Programmatūras prasību specifikācijas kontrolsaraksts<br />

(<strong>no</strong> http://www.rspa.com/checklists/reqspec.html)<br />

The Software Requirements Specification is the work product that is often produced<br />

as a consequence of the analysis activity. The checklist that follows will help you to<br />

assist the quality of this document. . For this checklist, the more questions that elicit a<br />

negative response, the higher the risk that the specification will <strong>no</strong>t adequately serve<br />

its purpose.<br />

Do stated goals and objectives for software remain consistent with system goals and<br />

objectives<br />

Have important interfaces to all system elements been described<br />

Have all data objects been described Have all attributes been identified<br />

Do major functions remain within scope and has each been adequately described<br />

Have functions been refined (elaborated) to an appropriate level of detail<br />

Is information flow adequately defined for the problem domain<br />

Are diagrams clear; can each stand alone without supplementary text<br />

Is the behavior of the software consistent with the information it must process and the<br />

functions it must perform<br />

Have events and states been identified<br />

Are design constraints realistic<br />

Have tech<strong>no</strong>logical risks been fully defined<br />

Have alternative software requirements been considered

Have validation criteria been stated in detail; are they adequate to describe a<br />

successful system<br />

Have inconsistencies, omissions or redundancy been identified and corrected<br />

Is the customer contact complete<br />

Has the user reviewed the Preliminary User's Manual or prototype<br />

How are the Software Project Plan estimates affected<br />

During the review of a requirements specification we attempt to uncover problems<br />

that may be hidden within the specification content. The following guidelines for a<br />

detailed specification review are suggested:<br />

Be on the lookout for persuasive connectors (e.g., certainly, therefore, clearly,<br />

obviously, it follows that), ask why<br />

Watch out for vague terms (e.g., some, sometimes, often, usually, ordinarily, most,<br />

mostly); ask for clarification.<br />

When lists are given, but <strong>no</strong>t completed, be sure all items are understood. Keys to<br />

look for: "etc., and so forth, and so on, such as."<br />

Be sure stated ranges don't contain unstated assumptions (e.g., Valid codes range from<br />

10 to 100. Integer Real Hex)<br />

Beware of vague verbs such as "handled, rejected, processed, skipped, eliminated."<br />

There are many ways they can be interpreted.<br />

Beware of ambiguous pro<strong>no</strong>uns (e.g., The I/O module communicates with the data<br />

validation module and its control flag is set. Whose control flag)<br />

Look for statements that imply certainty (e.g., always, every, all, <strong>no</strong>ne, never), then<br />

ask for proof.<br />

When a term is explicitly defined in one place, try substituting the definition for other<br />

occurrences of the term<br />

When a structure is described in words, draw a picture to aid in understanding.<br />

When a calculation is specified, work at least two examples.<br />

13.1. <strong>Konspekts</strong><br />

Prasību inženierijas labā prakse<br />

<strong>Izmantoti</strong>e materiāli:<br />

Karl E. Wieger. “Software Requirements” – Microsoft Press, 1999, lpp. 37-52<br />

Roger S. Pressman “Software Engineering. A Practioners Approach” - McGraw-Hill.<br />

Inc., 1997, 4. <strong>no</strong>daļa, lpp. 253-259<br />

Lekcijas plāns<br />

· Prasību inženierijas labā prakse.<br />

o Prioritātes<br />

o Skaidrojumi<br />

· Tehniski eko<strong>no</strong>miskas pamatojums<br />

· Eko<strong>no</strong>miskā lietderība<br />

· Tehniskā realizējamība<br />

Prasību inženierijas labā prakse<br />

Zemāk tabulā sniegti labās prakses padomi, kuri ietekmē projekta veiksmi. Padomi<br />

sakārtoti pēc to prioritātēm un sarežģītības.

Prioritāte Sarežģītība<br />

Augsta Vidēja Zema<br />

Augsta - Definēt prasību realizācijas<br />

procedūru<br />

- Izstrādāt plānus uz prasību<br />

pamata<br />

- Pārrunāt saistības<br />

- Identificēt lietošanas piemērus /<br />

scenārijus<br />

- Definēt kvalitātes atribūtus<br />

- Pielāgot PPS sagatavi<br />

Vidēja<br />

Zema<br />

- Izglītot lietotājus un vadību <strong>par</strong><br />

prasībām<br />

- Modelēt prasības<br />

- Veikt prasību riskus pārvaldību<br />

- Izmantot prasību pārvaldības<br />

rīkus<br />

- Izveidot prasību trasējamības<br />

matricu<br />

- Noturēt kopsanāksmes (Joint<br />

Application Development<br />

sessions)<br />

- Atkalizmantot prasības<br />

- Lietot kvalitātes funkciju<br />

izvietošanas (Quality Functions<br />

Deployment) pieeju<br />

- Mērīt prasību stabilitāti<br />

- Definēt izmaiņu vadības procesu<br />

- Nodibināt izmaiņu vadības<br />

padomi<br />

- Pārbaudīt prasību dokumentus<br />

- Vingrināt prasību analītiķus<br />

- Nodibināt fokusēšanas grupas<br />

- Izstrādāt prototipus<br />

- Analizēt iespējamību<br />

- Definēt pieņemšanas kritērijus<br />

- Veikt izmaiņu ietekmes analīzi<br />

- Izsekot katrai izmaiņai līdz<br />

visiem ietekmētiem<br />

darbproduktiem<br />

- Izvēlēties piemērotāko dzīves<br />

ciklu<br />

- Analizēt lietotāju darba plūsmu<br />

- Pētīt problēmu ziņojumus<br />

- Uzrakstīt lietotāju rokasgrāmatu<br />

- Uzturēt prasību vēsturi<br />

- Dokumentēt prasību<br />

darbietilpību<br />

Padomu izskaidrojums un sadalījums pa procesiem<br />

ZINĀŠANAS<br />

- Vingrināt prasību analītiķus. Visiem izstrādātājiem jābūt pamatzināšanām <strong>par</strong><br />

prasību inženieriju, savukārt analītiķus nepieciešams vairāk izglītot šajā jomā.<br />

Analītiķiem ir jābūt labām verbālās un neverbālas komunikācijas iemaņām, labi<br />

organizētiem, zi<strong>no</strong>šiem lietojumprogrammatūras jomā.<br />

- Izglītot lietotājus un vadību <strong>par</strong> prasībām. Visiem izstrādes projektos iesaistītiem<br />

darbiniekiem ir jāsaprot prasību inženierijas pamati un prasību svarīgumu un ietekmi<br />

uz projekta rezultātiem.<br />

- Vingrināt izstrādātājus problēmapgabala koncepcijās. Lai iesaistītie darbinieki labāk<br />

saprastu apgabalu, kuram tiks izstrādāta programmatūra, nepieciešams sarīkot<br />

semināru <strong>par</strong> pasūtītāja darbības jomu - darījumprocesiem, termi<strong>no</strong>loģiju, mērķiem.<br />

Tas var mazināt jucekli un komunikācijas problēmas.<br />

- Izstrādāt projekta terminu vārdnīcu. Lai mazinātu komunikācijas problēmas,<br />

- Vingrināt izstrādātājus<br />

lietojumprogrammatūras<br />

- Uzrakstīt vīziju un aptv<br />

- Identificēt lietotāju gru<br />

- Uzzīmēt konteksta dia<br />

- Identificēt prasību avot<br />

- Apzīmēt katru prasību<br />

- Nodibināt bāzlīnijas un<br />

prasību dokumentu versi<br />

kontroli<br />

- Izstrādāt zināšanu krāju<br />

- Izvēlēties produkta "če<br />

- Izveidot datu vārdnīcu<br />

- Novērot un fiksēt<br />

darījumlikumus (busines<br />

- Izstrādāt prasībām atbil<br />

testpiemērus<br />

- Sekot līdzi prasību statu

jāizstrādā terminu vārdnīca, kurā definē specializētus terminus problēmapgabala sfērā.<br />

Svarīgi iekļaut terminus ar vairākām <strong>no</strong>zīmēm.<br />

PRASĪBU IZZINĀŠANA<br />

- Uzrakstīt vīziju un aptvērumu (scope). Vīzijas un apjoma dokumentam jāsatur<br />

augstā līmeņa lietojumprogrammatūras prasības. Atbilstoši šai vīzijai tiek vēlāk<br />

izstrādāti visi lietošanas scenāriji un funkcionālās prasības.<br />

- Definēt prasību realizācijas procedūru. Prasību izzināšanas, analīzes, specificēšanas<br />

un pārbaudes soļiem jābūt definētiem un dokumentētiem vie<strong>no</strong>tā procedūrā, kura<br />

kalpo analītiķiem <strong>par</strong> ceļvedi.<br />

- Identificēt lietotāju grupas. Lai neizlaistu nevienu lietotāju prasību izzināšanas<br />

procesā, lietotāji ir jāklasificē grupās. Jāidentificē katras grupas <strong>no</strong>zīmība un ietekme<br />

uz produktu.<br />

- Izvēlēties produkta čempionus. Jāizvēlas vismaz viens pārstāvis lietotāju grupā, kurš<br />

var precīzi definēt prasības. Tiem ir jāpiedalās dažādās aktivitātēs projekta gaitā un<br />

jāvar pieņemt lēmumi.<br />

- Nodibināt fokusa grupas. Fokusa grupas ir lietotāji, kuri var nepieņemt lēmumus, bet<br />

kuri pārzina funkcionālas un nefunkcionālas programmatūras produkta prasības.<br />

- Identificēt lietošanas piemērus/scenārijus. Par lietošanas piemēriem jeb scenārijiem<br />

kalpo lietotāju pārstāvju pienākumi, kuru atbalstam nepieciešams izstrādāt<br />

lietojumprogrammatūru.<br />

- Noturēt kopsanāksmes. Kopsanāksmes (Joint Application Development sessions)ir<br />

paplašināti veici<strong>no</strong>ši semināri, kuros iesaista analītiķus un pasūtītāja pārstāvjus, lai<br />

izstrādātu prasību dokumentu. Pasūtītāja iesaistīšana šajā intensīvajā darbā,kalpo <strong>par</strong><br />

pamatu ciešām attiecībām prasību definēšanas un produkta izstrādes laikā.<br />

- Analizēt lietotāju darba plūsmu. Lai izprastu darba plūsmu, pasūtītāja pārstāvjus<br />

mēdz <strong>no</strong>vērot, pildot savus pienākumus. Darba plūsmas dokumentēšana palīdz<br />

identificēt lietošanas scenārijus un funkcionālās prasības.<br />

- Definēt kvalitātes atribūtus. Kvalitātes atribūtu un nefunkcionālo prasību<br />

(veiktspēja, efektivitāte, uzticamība, lietojamība u.c.) pirmavots ir lietotāja ieceres.<br />

- Izpētīt problēmu ziņojumus. Problēmu un uzlabojumu ziņojumi kalpo <strong>par</strong> bagātu<br />

avotu produkta papildus funkcionalitātes idejām, kuras var būt <strong>par</strong> pamatu nākamām<br />

produkta versijām.<br />

- Atkalizmantot prasības. Ja pasūtītājam nepieciešamās funkcionālās prasības ir<br />

līdzīgas jau esošajam produktam, ir vērtīgi izmantot jau iegūtās prasības, kā arī meklēt<br />

iespēju izmantot jau gatavus programmatūras komponentus.<br />

PRASĪBU ANALĪZE<br />

- Uzzīmēt konteksta diagrammu. Konteksta diagramma ir vienkāršs modelis, kurš<br />

definē robežas un saskarnes starp izstrādājamo programmatūru un pasūtītāja esošām<br />

sistēmām. Tā identificē arī informācijas un resursu plūsmu pār saskarnēm.<br />

- Izstrādāt prototipus. Ja izstrādātāji vai lietotāji nav pārliecināti <strong>par</strong> prasībām, var<br />

piemērot lietotāju saskarņu prototipus - daļēju iespējamās funkcionalitātes realizāciju,<br />

kas kalpo turpmākai koncepcijas izstrādei.<br />

- Analizēt prasību iespējamību. Katrai prasībai ir jāizvērtē realizācijas un ieviešanas<br />

iespējamība, ņemot vērā izmaksas, veiktspēju un izstrādes vidi. Jā<strong>no</strong>vērtē riski, kas<br />

var apdraudēt prasību realizācijas iespējamību, ietverot prasību konfliktus, atkarību <strong>no</strong><br />

ārējiem faktoriem un tehniskiem apstākļiem.

- Prioritizēt prasības. Ar analītiskas pieejas palīdzību pēc iespējas jāprioritizē<br />

lietošanas scenāriju, funkcionalitāšu un atsevišķo prasību realizācija. Ņemot <strong>par</strong><br />

pamatu prioritātes, jāvie<strong>no</strong>jas <strong>par</strong> to, kura programmatūras lietojuma versija saturēs<br />

kuru daļu realizēto prasību.<br />

- Modelēt prasības. Grafiskie prasību analīzes modeļi (datu plūsmas diagrammas,<br />

entītiju relāciju diagrammas, stāvokļu-pāreju diagrammas, dialogu kartes un objektu<br />

klašu un mijiedarbības diagrammas) var kalpot <strong>par</strong> vērtīgu papildinājumu PPS<br />

dokumentam.<br />

- Izveidot datu vārdnīcu. Datu vārdnīca ir centrālā krātuve visu datu vienumu un<br />

struktūru definīcijām. Tā <strong>no</strong>drošina izstrādātājiem visu nepieciešamo informāciju,<br />

strādājot pie saistītiem programmatūras komponentiem.<br />

- Pielietot kvalitātes funkciju izvietošanu. Kvalitātes funkciju izvietošana (Quality<br />

Funkcion Deployment) ir augsti sistemātiska tehnika produktu funkcionalitāšu<br />

sasaistīšanai ar pasūtītāja vērtībām un mērķiem. Tā sniedz analītisku pieeju to<br />

funkcionalitāšu identificēšanai, kuras <strong>no</strong>drošinās visaugstāko klienta apmierinātību.<br />

PRASĪBU SPECIFICĒŠANA<br />

- Izvēlēties PPS sagatavi. Organizācijā jābūt definētai programmatūras prasību<br />

specifikācijas dokumenta sagatavei, kura ļauj pielāgot šo sagatavi atkarībā <strong>no</strong> projekta<br />

vajadzībām, kā arī atvieglo prasību dokumentēšanu.<br />

- Identificēt prasību avotus. Lai pārliecinātos, ka visas ieinteresētās puses zina, kāpēc<br />

katra <strong>no</strong> funkcionālām prasībām ir iekļauta PPS, jāveic atgriezeniska prasību<br />

izsekošana, identificējot katras prasības avotu.<br />

- Apzīmēt katru prasību. Katrai PPS prasībai ir jābūt unikālam identifikatoram vai<br />

marķējumam, kas kalpo <strong>par</strong> palīgu prasību trasējamības un statusa izsekošanas<br />

procesos.<br />

- Novērot un fiksēt darījumu likumus. Darījumu likumi ir principi attiecībā uz<br />

programmatūru, kā piemēram, kurš un kādos gadījumos var veikt <strong>no</strong>teiktu funkciju.<br />

Šiem principiem jābūt dokumentētiem, lai vēlāk varētu veikt to izpildes pārbaudi.<br />

- Izveidot prasību trasējamības matricu. Katrai atsevišķai prasībai ir jābūt sasaistītai ar<br />

projektējuma elementu un kodu, kas to implementē, kā arī ar attiecīgo testu, kurš<br />

pārbauda tās realizāciju. Prasību trasējamības matrica var arī sasaistīt funkcionālās<br />

prasības ar augstākā līmeņa prasībām.<br />

PRASĪBU PĀRVALDĪBA<br />

- Definēt izmaiņu vadības procesu. Prasību izmaiņu pieteikšanai, analīzei un lēmumu<br />

pieņemšanai <strong>par</strong> prasību realizāciju ir jā<strong>no</strong>tiek saskaņā ar iepriekš definētu izmaiņu<br />

vadības procedūru.<br />

- Nodibināt izmaiņu vadības padomi. Nodibi<strong>no</strong>t nelielu ieinteresēto pušu grupu, kura<br />

saņem izmaiņu pieprasījumus, izvērtē, vai tie ir projekta aptvēruma ietvaros, un<br />

pieņem lēmumu <strong>par</strong> to akceptēšanu vai <strong>no</strong>raidīšanu, tiek panākta efektīva<br />

izmaiņuvadība - <strong>no</strong>vērtēšana, saskaņošana vai <strong>no</strong>raidīšana, prioritizēšana un<br />

piesaistīšana versijām.

- Veikt izmaiņu ietekmes analīzi. Katrai pieteiktai izmaiņai nepieciešams <strong>no</strong>vērtēt tās<br />

ietekmi uz projekta kalendāro plānu un citām prasībām.<br />

- Izsekot katras prasības ietekmei uz darbproduktiem. Kad izmaiņas ir akceptētas, tām<br />

ir jābūt saskaņotām ar prasību trasējamības matricu, lai <strong>no</strong>skaidrotu, vai nav kādas<br />

citas prasības, projektējuma komponenti, kods vai testpiemēri, kuriem atbilstoši jābūt<br />

izmainītiem.<br />

- Nodibināt bāzlīniju un veikt prasību dokumentu versiju vadību. Definēt prasību<br />

bāzlīniju, kas ir attiecīgā brīža saskaņoto prasību momentuzņēmums. Kad prasības ir<br />

<strong>no</strong>stiprinātas, tās var tikt mainītas, tikai izejot speciālu izmaiņu vadības procedūru.<br />

Vislabākā pieeja ir izmantot kādu <strong>no</strong> konfigurāciju pārvaldības rīkiem.<br />

- Uzturēt prasību vēsturi. Prasību versiju kontrole ietver vēstures uzturēšanu, t.i. fiksēt<br />

izmaiņu pieteicēju, datumu un laiku, iemeslu, prasību dokumenta rediģētāju, datumu<br />

un laiku, kā arī jaunu versijas numuru.<br />

- Sekot līdzi prasību statusam. Vislabākais veids, kā panākt prasību statusa<br />

izsekojamību, ir izveidot reģistru, kurā tiek uzturēta informācija <strong>par</strong> katras prasības<br />

atribūtiem, tai skaitā statusu (piemēram, pieteikta, apstiprināta, implementēta vai<br />

verificēta).<br />

- Mērīt prasību stabilitāti. Jā<strong>no</strong>saka <strong>no</strong>stiprināto (baselined) prasību skaitu un<br />

pieteikto un apstiprināto izmaiņu skaitu mēneša vai nedēļas laikā. Pārmērīgas prasību<br />

izmaiņas ir sarkanais karodziņš, kas liecina <strong>par</strong> problēmām projekta uzdevumu<br />

izpratnē, definēšanā vai citiem ietekmējošiem aspektiem.<br />

- Izmantot prasību pārvaldības rīkus. Komerciālie prasību pārvaldības rīki atvieglo<br />

prasību trasējamības un vadības procesu, kalpojot <strong>par</strong> palīgu komunikācijā starp<br />

analītiķiem, izstrādātājiem, testētājiem un, atsevišķos gadījumos, pasūtītājiem.<br />

PRASĪBU VERIFIKĀCIJA JEB PĀRBAUDE<br />

- Pārbaudīt (inspect) prasību dokumentus. Formāla prasību dokumenta pārbaude, ko<br />

veic dažādus skatījumus pārstāvoša speciālistu grupa (piemēram, analītiķis, pasūtītājs,<br />

projektētājs un testētājs) ir viena <strong>no</strong> augsti vērtējamām programmatūras kvalitātes<br />

<strong>no</strong>drošināšanas aktivitātēm. Tā ļauj pārbaudīt dokumentu un identificēt kļūdas pirms<br />

<strong>no</strong>došanas pasūtītājam.<br />

- Izstrādāt prasībām atbilstošos testpiemērus. Ņemot <strong>par</strong> pamatu lietošanas scenārijus,<br />

iespējams izstrādāt melnās kastes testpiemērus, lai dokumentētu sagaidāmo<br />

programmatūras uzvedību (rezultāts) pie specificētiem <strong>no</strong>sacījumiem (ieejas dati).<br />

Testpiemērus var izmantot arī prasību modeļu <strong>par</strong>eizības testēšanai (dialogu kartes,<br />

prototipu testēšanā).<br />

- Uzrakstīt lietotāju rokasgrāmatu. Lietotāju rokasgrāmatas sākotnējais variants,<br />

izstrādāts vēl pirms izstrādes, var kalpot <strong>par</strong> prasību specifikāciju vai papildinājumu<br />

tai. Laba rokasgrāmata iezīmē visu lietotājam redzamu funkcionalitāti labi saprotamā<br />

valodā.

- Definēt pieņemšanas jeb akceptēšanas kritērijus. Lai labāk izstrādātu pieņemšanas<br />

testus, ieteicams aptaujāt lietotājus, lai identificētu, kā viņi <strong>no</strong>skaidros, vai gatava<br />

programmatūra atbilst viņu prasībām. Šī informācija var tikt ietverta testpiemēros,<br />

lietošanas piemēros vai pieņemšanas testos.<br />

PROJEKTU PĀRVALDĪBA<br />

- Izvēlēties piemērotāko dzīves ciklu. Atkarībā <strong>no</strong> prasību detalizācijas un stabilitātes,<br />

organizācijai ir jāizvēlas piemērotākais dzīves cikls. Ūdenskrituma modelis ir<br />

piemērojams tajos gadījumos, kad prasības ir labi definētas jau projekta sākumā.<br />

Pretējā gadījumā jāpiemēro prototipēšanas metodika, pasoļu izstrāde vai kāds cits<br />

izstrādes dzīves cikla modelis.<br />

- Izstrādāt plānus uz prasību pamata. Darbietilpību un kalendāro plānu sākotnēji<br />

<strong>no</strong>vērtē, ņemot <strong>par</strong> pamatu darījumprasības, vīziju un aptvērumu. Šie <strong>no</strong>vērtējumi nav<br />

sevišķi precīzi, tāpēc tie ir jāpārvērtē, kad prasības kļūst skaidrākas.<br />

- Pārrunāt saistības. Kad projektam tiek pievie<strong>no</strong>tas jaunas papildus<br />

prasības,jā<strong>no</strong>vērtē, vai joprojām ir iespējams sasniegt kvalitātes saistības un iekļauties<br />

kalendārajā plānā. Ja tas nav iespējams, situācija ir jāpārrunā ar vadību, piedāvājot<br />

jaunus, reālistiskākus plānus.<br />

- Veikt prasību risku pārvaldību. Riskiem, kas saistīti ar prasībām, ir jābūt<br />

uzskaitītiem un dokumentētiem risku pārvaldības dokumentā. Ir jābūt skaidrai iespējai<br />

mazināt vai likvidēt šos riskus.<br />

- Dokumentēt prasību darbietilpību. Uzskaitot prasību izstrādei un pārvaldībai<br />

nepieciešamo darbietilpību un laiku, iespējams <strong>no</strong>vērtēt, vai plā<strong>no</strong>tās aktivitātes ir<br />

<strong>no</strong>tikušas kā plā<strong>no</strong>ts, kā arī ļauj labāk plā<strong>no</strong>t resursus nākamajos projektos.<br />

Tehniski eko<strong>no</strong>miskais pamatojums<br />

Visi projekti ir iespējami - ar neierobežotiem resursiem un laiku ! Diemžēl,<br />

programmatūras izstrādē ļoti bieži gadās situācijas, kad resursi ir ierobežoti, bet<br />

<strong>no</strong>došanas termiņi ir vairāk nereāli nekā iespējami. Tieši tāpēc ir ļoti svarīgi <strong>no</strong>vērtēt<br />

projekta iespējamību pēc iespējas ātrāk. Atklājot nereālus plānus, var <strong>no</strong>vērst mēnešu<br />

un pat gadu ilgu nepamatotu darbu, kā arī tūkstošu latu tēriņu.<br />

Iespējamības un risku analīze ir līdzīgi savā starpā. Ja projekta risks ir augsts, tad<br />

programmatūras pabeigšanas iespējamība samazinās. Tomēr, veicot produkta izstrādi,<br />

uzmanība tiek koncentrēta uz 4 galvenajām lietām:<br />

Eko<strong>no</strong>miskais pamatojums. Tiek <strong>no</strong>vērtētas izstrādes izmaksas pret ienākumiem vai<br />

citiem ieguvumiem <strong>no</strong> projekta realizācijas.<br />

Tehniskais pamatojums. Tiek izpētītas funkciju, veiktspējas un ierobežojumu, kuri var<br />

apdraudēt sistēmas izstrādes pabeigšanu.<br />

Tiesisks pamatojums. Tiek <strong>no</strong>teikti jebkuri likumpārkāpumi, traucējumi vai atbildība,<br />

kuri var iestāties vai izrietēt <strong>no</strong> sistēmas izstrādes.<br />

Alternatīvas. Tiek <strong>no</strong>vērtētas alternatīvas pieejas sistēmas izstrādei.<br />

Tehniski eko<strong>no</strong>miskais pamatojums nav obligāts, ja sistēmas izstrādes eko<strong>no</strong>miskais<br />

attais<strong>no</strong>jums ir acīmredzams, tehniskais risks ir zems, gaidāmas neliels skaits tiesisku<br />

problēmu un neeksistē saprātīgas alternatīvas. Tomēr, ja jebkurš <strong>no</strong> šiem faktoriem ir<br />

citādāks, tehniski eko<strong>no</strong>miskais pamatojums ir jāveic.

Apsvērumi, saistīti ar tehniski eko<strong>no</strong>misko pamatojumu ir šādi:<br />

Izstrādes risks. Vai sistēmas elements var būt izstrādāts, sasniedzot nepieciešamas<br />

funkcijas un veiktspēju, kā arī ņemot vērā <strong>no</strong>teiktus ierobežojumus<br />

Resursu pieejamība. Vai zi<strong>no</strong>ši darbinieki ir pieejami sistēmas vai sistēmas elementa<br />

izstrādei Vai citi resursi (a<strong>par</strong>atūra, programmatūra) ir pieejami, lai veikt izstrādi<br />

Teh<strong>no</strong>loģija. Vai atbilstoša teh<strong>no</strong>loģija ir sasniegusi līmeni, kurš nepieciešams, lai<br />

veiksmīgi atbalstītu un uzturētu sistēmas funkcijas<br />

Tehniski eko<strong>no</strong>miskais pamatojums var būt dokumentēts kā atsevišķa atskaite<br />

augstākai vadībai, kura iekļauj papildinājumus esošai sistēmas specifikācijai. Tomēr<br />

šī dokumenta forma var atšķirties. Dokumenta satura <strong>par</strong>augs:<br />

I. Ievads<br />

A. Problēmas izklāstījums<br />

B. Ieviešanas vide<br />

C. Ierobežojumi<br />

II. Pārvaldības kopsavilkums un rekomendācijas<br />

A. Svarīgie konstatējumi<br />

B. Komentāri<br />

C. Rekomendācijas<br />

D. Ietekme<br />

III. Alternatīvas<br />

A. Sistēmas konfigurācijas alternatīvas<br />

B. Gala pieejas izvēlē izmantoti kritēriji<br />

IV. Sistēmas apraksts<br />

A. Īss aptvēruma izklāstījums<br />

B. Noteikto elementu iespējamība<br />

V. Izmaksu-labumu analīze<br />

VI. Tehnisko risku <strong>no</strong>vērtējums<br />

VII. Tiesisks sazarojums<br />

VIII. Citi projektam specifiskie faktori<br />

Tehniski eko<strong>no</strong>misko pamatojumam pirmo apskati veic projekta pārvaldnieks (lai<br />

<strong>no</strong>vērtētu satura uzticamību) un tad augstākā vadība (lai <strong>no</strong>vērtētu projekta statusu).<br />

Pamatojumam ir jāseko lēmuma pieņemšanai "sākt/nesākt". Ir jāpiezīmē, ka šādi<br />

lēmumi tiks vēlāk pieņemti arī pēc plā<strong>no</strong>šanas, specifikācijas izstrādes un<br />

programmatūras izstrādes soļiem.<br />

Eko<strong>no</strong>miskā lietderība<br />

Starp citām svarīgām lietām tehniski eko<strong>no</strong>miskais pamatojums satur izmaksu un<br />

labumu analīzi - <strong>no</strong>vērtējumu sistēmas izstrādes projekta eko<strong>no</strong>miskajam<br />

pamatojumam. Izmaksu-labumu analīze attēlo projekta izstrādei nepieciešamas<br />

izmaksas un salīdzina tos ar materiāliem un nemateriāliem ieguvumiem <strong>no</strong> sistēmas<br />

izstrādes.<br />

Izmaksu-labumu analīzi sarežģī kritēriji, kuri ir atkarīgi <strong>no</strong> izstrādājamās sistēmas<br />

raksturlielumiem, relatīva projekta izmēra un sagaidāmās peļņas <strong>no</strong><br />

kapitālieguldījumiem, kura ir daļa <strong>no</strong> organizācijas stratēģiskā plāna. Bez tam, audzi<br />

ieguvumi <strong>no</strong> sistēmas izstrādes ir nes nemateriālu vērtību (piemēram, labākā<br />

projektēšanas kvalitāte, veicot iteratīvu optimizāciju, paaugstināta klientu<br />

apmierinātība, labāka lēmumu pieņemšana). Dažreiz tiešo kvantitatīvo <strong>no</strong>vērtējumu ir<br />

grūti iegūt.

Iespējamie informācijas sistēmas ieguvumiIespējamas informācijas sistēmas izmaksas<br />

Ieguvumi <strong>no</strong> aprēķinu vai drukāšanas Sagādes izmaksas<br />

uzdevumu uzlabošanas<br />

Konsultāciju izmaksas<br />

Izmaksu samazināšana katra vienuma Aprīkojuma iegādes vai <strong>no</strong>mas izmaksas<br />

aprēķinam un drukāšanai (CR)<br />

Aprīkojuma instalācijas izmaksas<br />

Aprēķinu uzdevumu precizitātes Izmaksas aprīkojuma izmaiņām (gaisa<br />

uzlabošana (ER)<br />

kondicionēšanas iekārtas, drošība u.c.)<br />

Iespēja ātri izmainīt mainīgos un vērtības Īpašuma izmaksas<br />

aprēķinu programmās (IF)<br />

Pārvaldības un ar sagādi saistītā personāla<br />

Ievērojami uzlabots aprēķinu un izmaksas<br />

drukāšanas ātrums (IS)<br />

Sākotnējas izmaksas<br />

Ieguvumi <strong>no</strong> ierakstu uzturēšanas Operētājsistēmas programmatūras<br />

uzdevumu uzlabošanas<br />

izmaksas<br />

Iespēja "automātiski" vākt un uzkrāt datus Komunikācijas aprīkojuma instalācijas<br />

<strong>no</strong> ierakstiem (CR, IS, ER)<br />

izmaksas (telefonlīnijas, datu līnijas u.c.)<br />

Ierakstu pilnīgāka un sistēmatiskāka Palaides personāla izmaksas<br />

uzturēšana (CR, ER)<br />

Darbaspēka meklēšanas un salīgšanas<br />

Paaugstināta ierakstu uzturēšanas ietilpība izmaksas<br />

- vietas un izmaksu ziņā (CR)<br />

Zaudējumi <strong>no</strong> sistēmas nepalaišanas<br />

Ierakstu uzturēšanas standartizēšana (CR, Ar projektu saistītas izmaksas<br />

IS)<br />

Lietojumprogrammatūras iegādes<br />

Uzlabota ierakstu uzkrāšanas drošība (ER, izmaksas<br />

CR, MC)<br />

Programmatūras pielāgošanas izmaksas<br />

Uzlabota ierakstu pārnesamība (IF, CR, Iekšējo lietojumu izstrādes darbaspēka,<br />

IS)<br />

u.c. izmaksas<br />

Ieguvumi <strong>no</strong> ierakstu meklēšanas Lietotāju personāla apmācības izmaksas<br />

uzdevumu uzlabošanas<br />

Datu vākšanas un datu instalācijas<br />

Ātrāka ierakstu izguve (IS)<br />

procedūru izmaksas<br />

Uzlabota iespēja piekļūt ierakstiem <strong>no</strong> Dokumentācijas sagatavošanas izmaksas<br />

lielām datu bāzēm (IF)<br />

Izstrādes pārvaldības izmaksas<br />

Uzlabota iespēja veikt labojumus ierakstos Nepārtrauktas izmaksas<br />

datu bāzēs (IF, CR)<br />

Sistēmu uzturēšanas izmaksas (a<strong>par</strong>atūra,<br />

Spēja savie<strong>no</strong>t vietnes, kurām<br />

programmatūra un telpas)<br />

nepieciešama meklēšanas iespēja, ar Īres izmaksas (elektrība, telefoni, u.c.)<br />

telekomunikāciju palīdzību (IF, IS) A<strong>par</strong>atūras amortizācijas izmaksas<br />

Iespēja auditēt un analizēt ierakstu Sistēmu pārvaldības, ekspluatācijas un<br />

meklēšanas aktivitātes (MC, ER) plā<strong>no</strong>šanas aktivitātēs iesaistītā personāla<br />

Ieguvumi <strong>no</strong> sistēmas pārveidošanas izmaksas<br />

iespēju uzlabošanas<br />

Iespēja vienlaicīgi mainīt visas ierakstu<br />

klases (IS, IF, CR)<br />

Iespēja pārvietot lielus datu failus (IS, IF)<br />

Iespēja veidot jaunus failus, apvie<strong>no</strong>jot<br />

citu failu elementus (IS, IF)<br />

Ieguvumi <strong>no</strong> analīzes un simulācijas<br />

iespēju uzlabošanas<br />

Iespēja ātri veikt sarežģītus, vienlaicīgus<br />

aprēķinus (IS, IF, ER)<br />

Iespēja veidot simulācijas sarežģītām

<strong>par</strong>ādībām, atbildot uz jautājumu "kas būs,<br />

ja..." (MC, IF)<br />

Iespēja savākt lielu apjomu datu<br />

plā<strong>no</strong>šanai un lēmumu pieņemšanai (MC,<br />

IF)<br />

Ieguvumi <strong>no</strong> procesu un resursu<br />

pārvaldības uzlabošanas<br />

Samazināta darbaspēka nepieciešamība<br />

procesu un resursu pārvaldībai (CR)<br />

Uzlabota iespēja savirknēt procesus, kā,<br />

piemēram, veidojot konveijeru (CR, MC,<br />

IS, ER)<br />

Uzlabota iespēja uzturēt ilgstošu resursu<br />

uzraudzību (MC, ER, IF)<br />

Saīsinājumi: CR - izmaksu samazināšana;<br />

ER - kļūdu samazināšana; IF - elastīguma<br />

paaugstināšana; IS - aktivitātes ātruma<br />

paaugstināšana; MC - uzlabota pārvaldības<br />

plā<strong>no</strong>šana vai kontrole.<br />

Tehniskā realizējamība<br />

Veicot tehnisko analīzi, analītiķis <strong>no</strong>vērtē sistēmas koncepcijas tehniskos plusus,<br />

<strong>par</strong>alēli uzkrājot informāciju <strong>par</strong> veiktspēju, uzticamību, uzturamību un produktivitāti.<br />

Dažos gadījumos, sistēmas analīzes solis iekļauj arī ierobežotu izpēti un projektēšanu.<br />

Tehniskā analīze sākas ar sistēmas tehniskās dzīvotspējas <strong>no</strong>vērtēšanu. Kādas<br />

teh<strong>no</strong>loģijas ir nepieciešamas, lai apmierinātu sistēmas funkcionalitāti un veiktspēju<br />

Kādi materiāli, metodes, algoritmi vai procesi ir nepieciešami un kādi ir to izstrādes<br />

riski Kā šīs teh<strong>no</strong>loģijas ietekmēs izmaksas<br />

Starp rīki, pieejamiem tehniskas analīzes veikšanai, var minēt dažus, kā, piemēram,<br />

matemātiskas modelēšanas un optimizēšanas tehnikas, iespējamības un statistikas,<br />

rindošanas teorija un kontroles teorija.<br />

Blanchard un Fabrycky definē kritēriju kopu modeļu izmantošanai, veicot tehnisko<br />

analīzi, šādi:

1. Modelim ir jāreprezentē sistēmas konfigurācijas dinamiku pietiekami vienkāršu, lai<br />

to varētu viegli saprast un manipulēt ar to, tai pat laikā pietiekami tuvu realitātei.<br />

2. Modelim ir jāiezīmē tie faktori, kuri ir svarīgi problēmas risināšanai un <strong>no</strong>klusēt<br />

tos, kuri nav tik svarīgi.<br />

3. Modelis ir jāveido kā vispārējs, iekļaujot visus būtiskus faktorus un tam ir jābūt<br />

uzticamam, ņemot vērā rezultātu atkārtojamību.<br />

4. Modeļa projektējumam jābūt pietiekami vienkāršam, lai savlaicīgi implementēt<br />

problēmu risinājumus.<br />

5. Modeļa projektējumam ir jāiekļauj <strong>no</strong>teikumi vieglai modificēšanai un/vai<br />

papildināšanai, lai ļautu <strong>no</strong>vērtēt papildus faktorus atbilstoši prasībām.<br />

No tehniskās analīzes iegūtie rezultāti veido bāzi citiem "sākt/nesākt" lēmumiem. Ja<br />

tehniskais risks ir <strong>no</strong>pietns, ja modelis <strong>no</strong>rāda uz pieprasītas funkcijas vai veiktspējas<br />

realizācijas neiespējamību, ja sistēmas daļas vienkārši nav savie<strong>no</strong>jamas - ir jāveic<br />

solis atpakaļ !<br />

14.1. <strong>Konspekts</strong> 1<br />

Projektēšanas pamati un principi<br />

(Design Concepts and Principles)<br />

<strong>Izmantoti</strong>e materiāli:<br />

Roger S. Pressman. “Software Engineering. A Practioners Approach” – McGraw-Hill.<br />

Inc., 1997, 13. <strong>no</strong>daļa (lpp.341-364)<br />

Lekcijas plāns<br />

Projektējuma dokumentācija<br />

Secinājumi<br />

Projektēšanas metodes<br />

Datu projektēšana<br />

Arhitektūras projektēšana<br />

Arhitektūras projektēšanas process<br />

Projektējuma pēc beigu apstrāde

1. attēls. Analīzes modeļa pārveidošana <strong>par</strong> programmatūras projektējumu<br />

Projektējuma dokumentācija<br />

Projektējuma dokumentācijas sagatave:<br />

I. Sfēra<br />

A. Sistēmas mērķi<br />

B. Galvenās programmatūras prasības<br />

C. Projektējuma ierobežojumi<br />

II. Datu projektējums<br />

A. Datu objekti un izrietošas datu struktūras<br />

B. Failu un datu bāžu struktūras<br />

1. ārējo failu struktūra<br />

a. loģiskā struktūra<br />

b. loģiskais ierakstu apraksts<br />

c. piekļuves metodes<br />

2. globālie dati<br />

3. failu un datu saistes <strong>no</strong>rādes<br />

III. Arhitektūras projektējums<br />

A. Datu un kontroles plūsmas apraksts<br />

B. Atvasināta programmas struktūra<br />

IV. Saskarņu projektējums<br />

A. Cilvēka-datora saskarnes specifikācija<br />

B. Cilvēka-datora saskarnes projektējuma likumi<br />

C. Ārējo saskarņu projektējums<br />

1. Saskarnes uz ārējiem datiem<br />

2. Saskarnes uz ārējām sistēmām vai ierīcēm<br />

D. Iekšējo saskarņu projektējuma likumi<br />

V. Procesuāls projektējums<br />

Katram modulim:<br />

A. Apstrādes apraksts<br />

B. Saskarņu apraksts<br />

C. Projektējuma valodas (vai citu) apraksts<br />

D. Lietotie moduļi<br />

E. Iekšējo datu struktūras<br />

F. Komentāri/ ierobežojumi<br />

VI. Prasību saistes <strong>no</strong>rādes<br />

VII. Testēšanas <strong>no</strong>teikumi<br />

A. Testēšanas vadlīnijas

B. Integrācijas stratēģija<br />

C. Īpašie apsvērumi<br />

VIII. Īpašas piezīmes<br />

IX. Pielikumi<br />

Katra projektējuma dokumentācijas sadaļa attiecas uz dažādiem projektējuma modeļu<br />

aspektiem. Numurētas sekcijas ir <strong>par</strong>asti pabeigtas, kad projektētājs sagatavo<br />

programmatūras risinājuma prezentāciju. Liela daļa informācijas, kuru satur I sekcija,<br />

nāk <strong>no</strong> programmatūras prasību specifikācijas (PPS) un analītiskā modeļa. II sekcija<br />

apraksta ārējo datņu struktūru, iekšējo datu struktūru un šķersatsauces starp datu<br />

objektiem un konkrētām datnēm. III sekcija uzskatāmi <strong>par</strong>āda, kā programmatūras<br />

arhitektūra izriet <strong>no</strong> analītiskā modeļa. IV un V sekcijas attīstās līdz ar saskarņu un<br />

procedūru projektējumu. VI sekcija satur prasību šķērsatsauces, kuru mērķis ir<br />

izveidot matricu, kurā būtu redzams, kā programmatūras projektējums apmierina<br />

klienta prasības, kā arī identificēts konkrēto prasību implementācijas kritiskums,<br />

sadalot tās pa moduļiem. VII sadaļa satur pirmo testēšanas dokumentācijas fāzi, kā arī<br />

<strong>no</strong>rādījumus produkta piegādei klientam. Visbeidzot, IX sadaļa satur<br />

papildinformāciju - algoritmu aprakstus, alternatīvas procedūras, tabulārus datus,<br />

izvilkumus <strong>no</strong> citiem dokumentiem un citu svarīgu informāciju. Ir ieteicams izstrādāt<br />

arī sākotnējo darbības/instalācijas rokasgrāmatu un iekļaut to projektējuma<br />

dokumentācijas pielikumos.<br />

Secinājumi<br />

"Mēs mēģinām risināt problēmu, steidzoties caur projektēšanas procesu, lai iekrātu<br />

pietiekami laika, ko projekta beigu posmā izmantot to defektu atklāšanai un<br />

<strong>no</strong>vēršanai, kuri mums būs radušies tāpēc, ka esam sasteiguši projektēšanas procesu".<br />

Glenford Myers<br />

Projektēšanas metodes<br />

Datu projektēšana<br />

Datu projektēšana ir pirmais un pēc dažu uzskatiem pats svarīgākais <strong>no</strong> 4<br />

projektēšanas soļiem, kurus veic programminženierijas laikā. Datu projektēšanas<br />

process ir šāds: sākotnēji tiek izvēlēta loģiskā datu objektu (struktūru) reprezentācija;<br />

tad ir ļoti svarīgi identificēt programmas moduļus, kuriem ir jāsadarbojas tieši ar datu<br />

objektiem vai loģiskām struktūrām. Vasermans (Wasserman) piedāvā šādus datu<br />

projektējuma principus.<br />

1. Sistemātiskas analīzes principus, ko lieto funkciju un uzvedības izzināšanā,<br />

jālieto arī datiem.<br />

2. Visām datu struktūrām un ar tām veiktajām operācijām ir jābūt identificētām.<br />

3. Jāizveido datu vārdnīca un tā jālieto gan datu, gan programmatūras projektēšanā.<br />

4. Zema līmeņa datu projektējuma lēmumi ir jāpieņem projektēšanas procesa<br />

beigās.<br />

5. Datu struktūras reprezentācijai ir jābūt zināmai tikai tiem moduļiem, kuri tieši<br />

izmanto datus, kurus satur atbilstošas struktūras.<br />

6. Jāizveido <strong>no</strong>derīgo datu struktūru bibliotēka ar operācijām, kuras var būt veiktas,<br />

izmantojot šīs datu struktūras.<br />

7. Programmatūras projektēšanas un programmēšanas valodai ir jāatbalsta abstraktu<br />

datu tipu specifikācija un realizācija.

Arhitektūras projektēšana<br />

Arhitektūras projektēšanas galvenais mērķis ir izstrādāt modulāru programmas<br />

struktūru un reprezentēt vadības attiecības starp moduļiem. Katrai programmatūras<br />

projektēšanas metodei ir savi plusi un mīnusi. Svarīgs faktors projektēšanas metodes<br />

izvēlē ir lietojumu plašums, kam šī metode var tikt piemērota. Datu plūsmu orientēta<br />

projektēšana ir piemērojama plašam lietojumu jomu lokam. Tā ir lietderīga gandrīz<br />

visām sistēmām, kur informācija rodas secīgi un nepastāv īpaša datu struktūru formāla<br />

hierarhija.<br />

Arhitektūras projektēšanas process<br />

Datu plūsmu orientēta projektēšana ir arhitektūras projektēšanas metode, kura ļauj ērti<br />

pāriet <strong>no</strong> programmas struktūras analītiskā modeļa uz projektējuma aprakstu. Šī<br />

pāreja <strong>no</strong> informācijas plūsmas uz moduļu struktūru ir veicama 5 soļos:<br />

1. informācijas plūsmas tipa konstatēšana;<br />

2. plūsmu robežu identificēšana;<br />

3. datu plūsmu diagrammas (DPD) attēlošana <strong>par</strong> programmas struktūru;<br />

4. vadības hierarhijas definēšana;<br />

5. izveidojušās struktūras uzlabošana, izmantojot dažādus projektēšanas paņēmienus<br />

un heiristikas.<br />

Pārveidošanas (transform) plūsma:<br />

Sistēmas pamatmodelī (datu plūsmas modeļa 0. līmenis) informācijai ir jāienāk un<br />

jāiznāk <strong>no</strong> programmatūras "ārējās pasaules" formā. Informācija, kas ienāk sistēmā pa<br />

ārējo datu pārveidošanas ceļiem uz iekšējo formu, ir ienākošā (incoming) plūsma.<br />

Ienākošie dati tiek izlaisti caur pārveidošanas centru (transform center) un sāk<br />

virzīties pa ceļiem uz sistēmas ārpusi. Šī plūsma saucas <strong>par</strong> izejošo (outgoing)<br />

plūsmu. Ja kādā datu plūsmu diagrammas daļā saskatāmi pieminētie elementi, tā ir<br />

pārveidošanas plūsma.<br />

Transakciju (transaction) plūsma:<br />

Sistēmas pamatmodelis demonstrē pārveidošanas plūsmu, tāpēc visas datu plūsmas<br />

varētu ietilpināt šajā kategorijā.Tomēr nereti informācijas plūsmu raksturo viens datu<br />

vienums(item), ko sauc <strong>par</strong> transakciju, un kas izraisa citu datu plūsmu pa kādu <strong>no</strong><br />

daudziem iespējamiem ceļiem. Transakciju pāreja ir līdzīga pārveidošanas pārejai.<br />

Galvenās atšķirības ir pārējā <strong>no</strong> DPD uz programmatūras struktūru:<br />

1. solis - Apskata sistēmas pamatmodeli<br />

2. solis - Apskata un detalizē datu plūsmu diagrammas<br />

3. solis - Noskaidro, vai DPD fragmentam ir pārveidošanas vai transakciju plūsmu<br />

raksturiezīmes<br />

4. solis - Izolē transakciju centru, <strong>no</strong>sakot ienākošo un izejošo plūsmu robežas<br />

5. solis - Attēlo DFD <strong>par</strong> programmas struktūru, kas atbild <strong>par</strong> vadības plūsmas<br />

organizēšanu<br />

6. solis - Caurskata DFD procesus ("burbuļus") un attēlo tos <strong>par</strong> atbilstošiem<br />

moduļiem<br />

7. solis - Detalizē pirmās iterācijas programmas struktūru, izmantojot projektēšanas<br />

heiristikas, lai uzlabotu programmatūras kvalitāti<br />

Projektējuma pēcapstrāde<br />

Veiksmīgas pārveidošanas vai transakciju attēlošanas (mapping) beigās <strong>par</strong>asti seko

papildus dokumentēšana, kas ir daļa <strong>no</strong> arhitektūras projektēšanas procesa. Pēc tam,<br />

kad struktūra ir izveidota un detalizēta, ir jāveic šādi uzdevumi:<br />

jāizstrādā apstrādes apraksts katram modulim;<br />

jāizstrādā saskarņu apraksts katram modulim;<br />

jādefinē lokālo un globālo datu struktūras;<br />

jāatzīmē visi projektējuma ierobežojumi;<br />

jāveic projektējuma apskate (review);<br />

jāapsver optimizācija (ja nepieciešama un pamatojama).<br />

14.2. <strong>Konspekts</strong> 2<br />

Sistēmas projektēšana - pāreja <strong>no</strong> DFD uz arhitektūras projektējumu<br />

<strong>Izmantoti</strong>e materiāli:<br />

Roger S. Pressman. “Software Engineering. A Practioners Approach” – McGraw-Hill.<br />

Inc., 1997, 13. <strong>no</strong>daļa (lpp.375-391)<br />

Lekcijas plāns<br />

Arhitektoniskā projektēšana<br />

Transformācijas plūsma<br />

Transakciju plūsma<br />

Projektēšanas piemērs<br />

Arhitektoniskā projektēšana<br />

Datu plūsmu-orientēta projektēšana ir arhitektoniskās projektēšanas metode, kura ļauj<br />

ērti pāriet <strong>no</strong> analīzes modeļa uz programmas struktūras projektējuma aprakstu. Pāreja<br />

<strong>no</strong> informācijas plūsmas (reprezentētas kā datu plūsmu diagramma) uz programmas<br />

struktūru <strong>no</strong>sacīti sastāv <strong>no</strong> 5 soļiem:<br />

(1) <strong>no</strong>saka informācijas plūsmas tipu;<br />

(2) identificē plūsmas robežas;<br />

(3) datu plūsmu diagrammu attēlo <strong>par</strong> programmas struktūru;<br />

(4) ar „faktorēšanas” metodi definē vadības hierarhiju;<br />

(5) rezultējošo struktūra pilnveido, izmantojot dažādus projektēšanas paņēmienus un<br />

heiristiskas metodes.<br />

Transformācijas plūsma<br />

Fundamentālajā sistēmas modelī (datu plūsmas diagrammas 0. līmenis) informācija<br />

ieiet un iziet <strong>no</strong> sistēmas "ārējās pasaules" formā (skat. 1.att.). Informācija ieiet<br />

sistēmā pa ceļiem, kas pārveido ārējos datus iekšējā formā, tāpēc to sauc <strong>par</strong> ienākošo<br />

plūsmu. Sistēmas kodolā <strong>no</strong>tiek pārveidošana jeb transformācija. Ieejas dati tiek<br />

izlaisti caur transformācijas centru un sāk virzīties uz sistēmas ārpusi. Datus, kuri iziet<br />

pa šiem ceļiem, sauc <strong>par</strong> izejošo plūsmu. Kopējā plūsma rit secīgi un tā iet pa vienu<br />

vai dažiem "taisniem" ceļiem. Kad kādam datu plūsmas diagrammas segmentam<br />

piemīt šādas raksturiezīmes, mums ir transformācijas plūsma.<br />

Transakciju plūsma<br />

Fundamentālais sistēmas modelis vienmēr satur transformācijas plūsmu, tādējādi tā<br />

iespējams raksturot ikvienu datu plūsmu. Tomēr informācijas plūsmu nereti var<br />

raksturot, izmantojot vienu datu vienumu, ko sauc <strong>par</strong> transakciju un kura izraisa

pārējās datu plūsmas. Transakciju plūsma <strong>par</strong>ādās, kad datu plūsmu diagramma<br />

pieņem 2.att. redzamo formu.<br />

1. attēls. Informācijas plūsma<br />

Transakciju plūsmu raksturo datu kustība pa ieejas ceļiem, pārveidojot ārējās pasaules<br />

informāciju <strong>par</strong> transakciju. Transakcija tiek aprēķināta, <strong>par</strong> pamatu ņemot tās vērtību,<br />

tiek uzsākta plūsma pa vienu <strong>no</strong> darbības ceļiem (action paths). Informācijas plūsmas<br />

centru, kurš izstaro darbības ceļus, sauc <strong>par</strong> transakcijas centru.<br />

2. attēls. Transakciju plūsma<br />

Transformāciju attēlošana (Tranform mapping)<br />

Transformāciju attēlošana ir projektēšanas soļi, kuri ļauj DFD ar transformācijas<br />

plūsmas raksturiezīmēm attēlot kā iepriekš definētu sagatavi programmas struktūrām.<br />

Piemērs.<br />

Sistēmas apraksts<br />

Lai ilustrētu projektēšanas procesu, aprakstīsim SafeHome drošības sistēmas izstrādi.<br />

SafeHome sistēma ļauj mājas saimniekam konfigurēt drošības sistēmu, kad tā ir<br />

instalēta, pārvaldīt drošības sistēmai pievie<strong>no</strong>tus sensorus un darboties ar

papildtastatūru un funkcionālo tastatatūru, ko satur SafeHome vadības panelis (3.<br />

attēls)<br />

3. attēls. SafeHome vadības panelis<br />

Veicot instalāciju, SafeHome vadības panelis tiek izmantots sistēmas konfigurēšanai.<br />

Katram sensoram tiek piešķirts numurs un tips, tiek uzstādīta galvenā <strong>par</strong>ole sistēmas<br />

ieslēgšanai un izslēgšanai, kā arī tiek ievadīts telefona numurs, kas tiks uzgriezts, ja<br />

sistēma <strong>no</strong>strādās.<br />

Kad tiek atpazīts sensora <strong>no</strong>tikums, sistēma rada skaņas signālu. Pēc konfigurācijā<br />

<strong>no</strong>teiktā laika intervāla sistēma uzgriež telefona numuru un ziņo <strong>par</strong> <strong>no</strong>tikuma vietu<br />

un dabu. Zvans tiek atkārtots ik pa 20 sekundēm, kamēr uz to netiek atbildēts.<br />

Visa veida mijiedarbība ar SafeHome tiek pārvaldīta <strong>no</strong> lietotāju-mijiedarbības<br />

apakšsistēmas, kura <strong>no</strong>lasa ievadu, ko <strong>no</strong>drošina papildtastatūra un funkcionālā<br />

tastatūra, attēlo paziņojumus un sistēmas statusu uz LCD ekrāna....<br />

0. līmeņa datu plūsmu diagramma SafeHome sistēmai ir <strong>par</strong>ādīta 4. attēlā.<br />

4. attēls. Konteksta līmeņa datu plūsmu diagramma<br />

Projektējuma soļi<br />

1. solis - caurskatīt fundamentālo sistēmas modeli jeb 0. līmeņa DPD (5. att.).

5. attēls. 1. līmeņa datu plūsmu diagramma<br />

2. solis - caurskatīt un uzlabot sistēmas datu plūsmu diagrammu (6. att.).<br />

6. attēls. 2. līmeņa datu plūsmu diagramma<br />

3. solis - <strong>no</strong>teikt, vai DPD ir transformācijas vai transakcijas plūsmu raksturiezīmes<br />

(7. att.).<br />

4. solis - izolēt transformācijas centru, <strong>no</strong>rādot ienākošās un izejošās plūsmas robežas<br />

(7. att.).

7. attēls. 3. līmeņa datu plūsmu diagramma ar plūsmas robežām<br />

5. solis - veikt "pirmā-līmeņa faktorēšanu (factoring)" (8. att.).

8. attēls. Pirmā-līmeņa „faktorējums"<br />

6. solis - veikt "otrā-līmeņa faktorējumu" (9. att.).

9. attēls. Pirmā līmeņa faktorējums<br />

7. solis - uzlabot pirmo sistēmas struktūras iterāciju, izmantojot heiristisku<br />

projektēšanu programmatūras kvalitātes uzlabošanai (10. att.).<br />

10. attēls. "Pirmā slīpējuma" sistēmas struktūra

Transakciju attēlošana (mapping).<br />

Daudzos lietojumos viens datu vienums izraisa vienu vai vairākas informācijas<br />

plūsmas, kuras ietekmē funkciju, kuru satur šis datu vienums (11. att.).<br />

Transakciju attēlošanas soļi:<br />

1. solis - Caurskatīt fundamentālo sistēmas modeli.<br />

2. solis - Caurskatīt un uzlabot datu plūsmas diagrammu.<br />

3. solis – Noteikt, vai DPD ir transformācijas vai transakcijas plūsmas raksturiezīmes.<br />

4. solis - Identificēt transakcijas centru un plūsmas raksturiezīmes katram darbību<br />

ceļam.<br />

5. solis - Attēlot DPD <strong>par</strong> programmas struktūru, kas būs atbildīga <strong>par</strong> transakciju<br />

veikšanu.<br />

6. solis - Sadalīt un uzlabot transakciju struktūru un katra darbību ceļa struktūru.<br />

7. solis - Uzlabot pirmo programmas struktūras iterāciju, izmantojot projektēšanas<br />

heiristikas programmatūras kvalitātes uzlabošanai.<br />

11. attēls. Transakcijas attēlošana<br />

15.1. <strong>Konspekts</strong><br />

Konfigurācijas pārvaldība<br />

(Configuration Management)<br />

<strong>Izmantoti</strong>e materiāli:

Roger S. Pressman. “Software Engineering. A Practioners Approach” – McGraw-Hill.<br />

Inc., 1997, 9. <strong>no</strong>daļa (lpp.209-227)<br />

Lekcijas plāns<br />

Kas ir programmatūras konfigurācijas pārvaldība<br />

Bāzlīnijas<br />

Programmatūras konfigurācijas vienumi<br />

Programmatūras konfigurācijas pārvaldības process<br />

Programmatūras konfigurācijas objektu identifikācija<br />

Versiju kontrole<br />

Izmaiņu vadība<br />

Konfigurācijas audits<br />

Stāvokļa uzskaite<br />

Kas ir programmatūras konfigurācijas pārvaldība<br />

Programmatūras izstrādes procesa rezultātus var iedalīt 3 kategorijās:<br />

(1) programmas (koda līmenis, izpildāmās formas);<br />

(2) dokumentācija (tehniska, administratora, lietotāja);<br />

(3) dati, ko satur pati programma.<br />

Informācijas kopu, kas satur visus izstrādes procesa rezultātus, sauc <strong>par</strong><br />

programmatūras konfigurāciju.<br />

Laika gaitā konfigurācijas vienumu kļūst arvien vairāk un vairāk. Arī programmatūras<br />

izmaiņas dara savu. Kā vēsta programmatūras inženierijas Pirmais likums : "Nav<br />

svarīgi, kurā solī jūs atrodaties sistēmas dzīves ciklā, sistēma mainīsies un sistēmas<br />

tieksme mainīties augs līdzi dzīves ciklam".<br />

Bāzlīnijas<br />

Izmaiņas ir dzīves neizbēgama realitāte programmatūras izstrādē. Pasūtītāji vēlas<br />

mainīt prasības. Izstrādātāji vēlas mainīt tehnisko pieeju. Vadītāji vēlas mainīt<br />

projekta pieeju. Kāpēc Atbilde ir tiešām ļoti vienkārša. Laikam ejot uz priekšu, visas<br />

iesaistītās puses uzzina vairāk <strong>par</strong> to, ko viņi vēlas, kādu pieeju labāk izvēlēties u.tml..<br />

Šīs jaunās zināšanas ir galvenais izmaiņu virzītājs, un visbiežāk izmaiņas ir<br />

pamatotas, ko, protams, ir grūti pieņemt izstrādātājiem.<br />

Bāzlīnijas ir programmatūras konfigurācijas pārvaldības koncepcija, kas palīdz mums<br />

pārvaldīt izmaiņas bez <strong>no</strong>pietnām traucējumiem pamatoto izmaiņu realizācijai. IEEE<br />

Std. 610.12-1990 definē bāzlīnijas sekojoši: Specifikācija vai produkts, kurš formāli ir<br />

apskatīts un saskaņots, kurš tādējādi kalpo <strong>par</strong> pamatu turpmākai izstrādei un kurš var<br />

tikt mainīts, tikai izmantojot formālu vadības procedūru.<br />

Viens veids, kā ilustrēt bāzlīnijas, ir analoģija: Iedomājieties virtuves durvis lielā<br />

restorānā. Lai izvairītos <strong>no</strong> sadursmēm, viena durvju puse ir atzīmēta kā IEEJA, bet<br />

otra - kā IZEJA. Durvīm ir ierīkoti slēdži, kuri ļauj katrai durvju pusei vērties tikai<br />

savā virzienā. Ja oficiants pieņem pasūtījumu virtuvē, <strong>no</strong>liek to uz paplātes un tad<br />

saprot, ka ir paņēmis ne<strong>par</strong>eizo šķīvi, viņš var ātri, bez problēmām <strong>no</strong>mainīt šķīvjus<br />

pirms iziešanas <strong>no</strong> virtuves. Bet, ja oficiants jau ir paspējis iziet <strong>no</strong> virtuves un iedot<br />

ne<strong>par</strong>eizo šķīvi restorāna apmeklētājam, apmeklētājam aizrādot <strong>par</strong> kļūdu, oficiantam<br />

ir jāseko <strong>no</strong>teiktai procedūrai: (1) paskatīties pasūtījuma lapā, lai pārliecinātos <strong>par</strong><br />

kļūdu; (2) atvai<strong>no</strong>ties; (3) atgriezties virtuvē caur IEEJAs durvīm; (4) paskaidrot<br />

problēmu; un tā tālāk...

Bāzlīnijas ir analogs šķīvim, kurš ceļo <strong>no</strong> virtuves līdz restorāna apmeklētājam. Pirms<br />

programmatūras konfigurācijas vienums (item) kļūst <strong>par</strong> bāzlīniju, izmaiņas var <strong>no</strong>tikt<br />

ātri un neformāli. Savukārt, ja bāzlīnijas ir <strong>no</strong>dibinātas, mēs figurāli esam izgājuši ārā<br />

pa viena virziena durvīm, un turpmākās izmaiņas var <strong>no</strong>tikt tikai pēc <strong>no</strong>teiktas<br />

procedūras. Zemāk ir attēloti konfigurācijas pārvaldības izplatītākie vienumi (1.<br />

attēls) un to saistība ar projekta datubāzi (si<strong>no</strong>nīmi - projekta datne, repozitorijs) (2.<br />

attēls).<br />

1.attēls. Izplatītākas programmatūras bāzlīnijas.

2.attēls. "Bāzlīnijoti"programmatūras konfigurācijas vienumi un projekta datubāze.<br />

Programmatūras konfigurācijas vienumi<br />

Sekojoši konfigurācijas vienumi ir galvenie un veido vadlīniju kopu:<br />

1. Sistēmas specifikācija<br />

2. Programmatūras projekta plāns<br />

3. Programmatūras prasību specifikācija<br />

a. Grafiskie analīzes modeļi<br />

b. Procesu specifikācija<br />

c. Prototips(i)<br />

d. Matemātiskā specifikācija<br />

4. Sākotnēja lietotāju rokasgrāmata<br />

5. Projektējuma specifikācija<br />

a. Datu projektējuma apraksts<br />

b. Arhitektūras projektējuma apraksts<br />

c. Moduļu projektējuma apraksti<br />

d. Saskarņu projektējuma apraksti<br />

e. Objektu apraksti (objektu-orientētas izstrādes gadījumā)<br />

6. Programmatūras koda izdruka<br />

7. Testēšanas specifikācija<br />

a. Testa plāns un procedūra<br />

b. Testpiemēri un rezultāti<br />

8. Darbības un instalācijas rokasgrāmatas<br />

9. Strādājošā programmatūra<br />

a. Strādājošo moduļu kods<br />

b. Saistītie moduļi<br />

10. Datubāzes apraksts<br />

a. Shēma un failu struktūra<br />

b. Sākotnējs saturs<br />

11. Lietotāju rokasgrāmata<br />

12. Uzturēšanas dokumentācija<br />

a. Programmatūras problēmu ziņojumi<br />

b. Uzturēšanas pieprasījumi<br />

c. Izmaiņu pieprasījumi<br />

13. Programmatūras inženierijas standarti un procedūras<br />

Programmatūras konfigurācijas pārvaldības process<br />

Programmatūras konfigurācijas pārvaldība ir svarīga kvalitātes <strong>no</strong>drošināšanas<br />

sastāvdaļa. Tās galvenā atbildības sfēra ir izmaiņu vadība. Tomēr programmatūras<br />

konfigurācijas pārvaldība ir atbildīga arī <strong>par</strong> konfigurējamo vienumu identifikāciju un<br />

programmatūras versijām, programmatūras auditēšanu, lai pārliecinātos, ka tā ir<br />

izstrādāta <strong>par</strong>eizi, un visu konfigurācijas izmaiņu uzskaiti. Jebkura diskusija <strong>par</strong><br />

programmatūras konfigurācijas pārvaldību aptver sarežģītu jautājumu kopu:<br />

Kā organizācija identificē un pārvalda daudzas esošas programmas versijas (un to<br />

dokumentāciju), lai <strong>no</strong>drošinātu efektīvu izmaiņu pievie<strong>no</strong>šanu<br />

Kā organizācija vada izmaiņas pirms un pēc programmatūra ir piegādāta pasūtītājam<br />

Kurš ir atbildīgs <strong>par</strong> izmaiņu apstiprināšanu un prioritizēšanu<br />

Kā var pārliecināties, ka izmaiņas ir izpildītas <strong>par</strong>eizi<br />

Kāds mehānisms tiek lietots, lai ieviestu paveiktās izmaiņas

Šie jautājumi pieved pie 5 konfigurācijas pārvaldības uzdevumu definīcijas:<br />

identificēšana, versiju vadība, izmaiņu vadība, konfigurācijas auditēšana un stāvokļa<br />

uzskaite.<br />

Programmatūras konfigurācijas objektu identifikācija<br />

Lai vadītu un pārvaldītu programmatūras konfigurācijas vienumus, katram <strong>no</strong> tiem ir<br />

jābūt atsevišķi <strong>no</strong>sauktam un organizētam objektorientētā modelī. Identificējami ir 2<br />

veida objekti: pamatobjekti un agregātobjekti. Katram objektam ir <strong>no</strong>saukums,<br />

apraksts, resursu saraksts un "realizācija". Objekta <strong>no</strong>saukumam jāidentificē objektu<br />

nepārprotami (t.i. unikāli). Objekta apraksts ir informācija, kas identificē<br />

konfigurācijas pārvaldības vienuma tipu (dokuments, programma, dati), projekta<br />

identifikatoru un izmaiņu un/vai versijas informāciju.<br />

Katrs objekts laika gaitā mainās, tāpēc tā vēsture var tikt attēlota kā evolūcijas grafs<br />

(3. attēls).<br />

3. attēls. Konfigurācijas objekta evolūcijas grafs.<br />

Versiju vadība<br />

Versiju vadība ietver procedūras un rīkus dažādu konfigurācijas objektu versiju<br />

pārvaldībai. Konfigurācijas pārvaldība ļauj lietotājam iezīmēt alternatīvas sistēmas<br />

konfigurācijas, izvēloties attiecīgas versijas. Tas tiek <strong>no</strong>drošināts, sasaistot atribūtus<br />

katrai programmatūras versijai, un ļaujot izvēlēties konfigurāciju, aprakstot<br />

nepieciešamo atribūtu kopu. Ar "atribūtiem" ir domāts versijas numurs vai veikto<br />

izmaiņu apraksts, kas atšķir vienu programmatūras versiju <strong>no</strong> otras.<br />

Viena versiju reprezentācija ir evolūcijas grafs (3. attēls). Katrs grafa mezgls ir<br />

agregātobjekts, kas ir gatava programmatūras versija. Savukārt katra programmatūras<br />

versija ir konfigurācijas objektu vienumu kopa (programmatūras kods, dokumenti,<br />

dati) un katra versija var sastāvēt <strong>no</strong> dažādiem variantiem.

4. attēls. Versijas varianti<br />

Piemēram, iedomāsimies tādu programmas versiju, kurai ir komponentes 1, 2, 3, 4 un<br />

5 (4. attēls). Komponente 4 tiek izmantota tikai tad, ja programmatūra tiek instalēta uz<br />

datoriem, kuri izmanto krāsu monitorus, savukārt, uz mo<strong>no</strong>hromatiskiem monitoriem<br />

tiek lietota 5. komponente. Tādējādi var secināt, ka versijai ir 2 varianti:<br />

(1) komponentes 1,2,3 un 4;<br />

(2) komponentes 1,2,3 un 5.<br />

Lai instalētu <strong>par</strong>eizo programmatūras versijas variantu, katrai komponentei var<br />

piešķirt "atribūtu-kopu" - <strong>no</strong>sacījumus, kuri <strong>no</strong>saka, vai komponente ir lietojama<br />

instalējamā programmatūras versijā. Katram variantam var piešķirt vienu vai vairākus<br />

atribūtus. Piemēram, krāsas atribūtu var lietot, lai <strong>no</strong>teiktu, kuru komponenti<br />

nepieciešams iekļaut krāsu monitoru gadījumā.<br />

Izmaiņu vadība<br />

Lielam programmatūras izstrādes projektam nevadītas izmaiņas <strong>no</strong>ved pie haosa.<br />

Izmaiņu vadība iekļauj procedūras un rīkus, lai <strong>no</strong>drošinātu izmaiņu vadības<br />

mehānismu. Izmaiņu vadības process ir ilustrēts 5. attēlā.

5. attēls. Izmaiņu vadības process<br />

Izmaiņu pieprasījums tiek iesniegts un <strong>no</strong>vērtēts, lai aprēķinātu tehniskus plusus,<br />

potenciālus blakus efektus, vispārējo ietekmi uz citiem konfigurācijas objektiem un<br />

sistēmas funkcijām, kā arī tā realizācijas izmaksas. Novērtējuma rezultāti tiek<br />

pasniegti kā izmaiņu ziņojums, ko izmanto izmaiņu vadības padome (IVP) - cilvēks<br />

vai grupa, kuri pieņem gala lēmumu <strong>par</strong> izmaiņas statusu un prioritāti. Saskaņotām<br />

izmaiņām tiek veidots inženieriskais izmaiņu pieprasījums, kas raksturo izmaiņas,<br />

kuras jāveic, un apskates un auditēšanas kritērijus. Kad izmaiņas ir realizētas, izmaiņu<br />

vadības mehānisms tiek izmantots nākamās programmatūras versijas sagatavošanā.<br />

"Bloķēšanas" un "atbloķēšanas" procesi implementē divus svarīgus izmaiņu vadības<br />

elementus - piekļuves vadību un sinhronizācijas vadību (6. attēls). Piekļuves vadība<br />

pārvalda, kurš <strong>no</strong> programmatūras izstrādātājiem ir tiesīgs piekļūt un izmainīt <strong>no</strong>teiktu<br />

konfigurācijas objektu. Sinhronizācijas vadība palīdz pārliecināties, ka <strong>par</strong>alēlas<br />

izmaiņas, kuras veic divi darbinieki, nepārklāj viena otru.

6. attēls. Piekļuves un sinhronizācijas vadības procesi<br />

Konfigurācijas audits<br />

Identifikācija, versiju vadība un izmaiņu vadība palīdz programmatūras izstrādātājiem<br />

uzturēt kārtībā to, kas citādi būtu haoss. Tomēr pat visveiksmīgākais vadības<br />

mehānisms izseko izmaiņai tikai, līdz inženieriskais izmaiņu pieprasījums ir izveidots.<br />

Kā mēs varam būt pārliecināti, ka izmaiņas ir <strong>par</strong>eizi īste<strong>no</strong>tas Atbilde ir divēja: (1)<br />

izmantojot formālas tehniskas apskates un (2) veicot programmatūras konfigurācijas<br />

auditu.<br />

Programmatūras konfigurācijas audits papildina formālas tehniskas apskates,<br />

<strong>no</strong>vērtējot konfigurācijas objektu raksturiezīmes, kurām netiek pievērsta uzmanība<br />

apskašu laikā. Audits uzdod un atbild uz sekojošiem jautājumiem:<br />

1. Vai izmaiņu pieprasījumā iekļautās izmaiņas tika realizētas Vai tika veiktas<br />

kādas papildus izmaiņas<br />

2. Vai tika veikta formāla tehniska apskate, lai <strong>no</strong>vērtētu tehnisku <strong>par</strong>eizību<br />

3. Vai izstrādātāji strikti sekoja programmatūras izstrādes standartiem<br />

4. Vai izmaiņas tika iekļautas programmatūras konfigurācijas vienumos Vai<br />

izmaiņu datums un autors tika ierakstīti Vai konfigurācijas objekta atribūti<br />

atspoguļoti izmaiņās<br />

5. Vai izmaiņas bloķēšanā, atbloķēšanā un uzskaitīšanā ir sekots programmatūras<br />

konfigurācijas vadības procedūrām<br />

6. Vai visi konfigurācijas vienumi ir atbilstoši atjaunināti<br />

Stāvokļa uzskaite<br />

Konfigurācijas stāvokļa uzskaite (dažreiz saukta <strong>par</strong> stāvokļa grāmatvedību) ir<br />

programmatūras konfigurācijas vadības uzdevums, kurš atbild uz šādiem<br />

jautājumiem:<br />

1. Kas ir <strong>no</strong>ticis<br />

2. Kurš to izdarīja

3. Kad tas <strong>no</strong>ticis<br />

4. Ko tas vēl ietekmēs<br />

Informācijas plūsma šim procesam ir attēlota 5. attēlā.<br />

Konfigurācijas stāvokļa uzskaite spēlē vitālu lomu lielu programmatūras izstrādes<br />

projektu veiksmē. Kad projektā ir iesaistīti daudzi darbinieki, ļoti bieži gadās, ka<br />

"kreisā roka nezina, ko dara labā roka". Divi izstrādātāji var vienlaicīgi modificēt<br />

vienu un to pašu konfigurācijas vienumu. Tādējādi konfigurācijas stāvokļa uzskaite<br />

palīdz izvairīties <strong>no</strong> problēmām, uzlabojot komunikāciju starp iesaistītām pusēm.<br />

16.1. Dokumenti programmizstrādes gaitā<br />

16.2. Projekta uzsākšanas pārskats<br />

Unprintable file: I semestris/Kospekti/Sagataves/1.Projekta uzsaksana.doc<br />

16.3. Projekta biznesa sfēras apraksts<br />

Unprintable file: I semestris/Kospekti/Sagataves/2.Biznesa sferas apraksts.doc<br />

16.4. Projekta uzsākšanas rīkojums<br />

Unprintable file: I semestris/Kospekti/Sagataves/3.Projekta rikojums.doc<br />

16.5. Projekta sfēra<br />

Unprintable file: I semestris/Kospekti/Sagataves/4.Projekta sfera.doc<br />

16.6. Darba <strong>no</strong>stādnes<br />

Unprintable file: I semestris/Kospekti/Sagataves/5.Darba <strong>no</strong>stadne.doc<br />

16.7. Projekta plāns<br />

Unprintable file: I semestris/Kospekti/Sagataves/6.Projekta plans.doc<br />

16.8. Projekta kalendārais plāns<br />

Unprintable file: I semestris/Kospekti/Sagataves/7.Projekta kalendarais plans.mpp<br />

16.9. Programmatūras prasību specifikācijas sagatave<br />

Programmatūras prasību specifikācijas sagatave<br />

LVS standarts - Informācijas teh<strong>no</strong>loģija. Programmatūras prasību specifikācijas<br />

(PPS) ceļvedis (LVS 68:1996) - iesaka, izstrādājot projektējuma dokumentu, izmantot<br />

šādu sagatavi.

1. Ievads<br />

<strong>1.1.</strong> Nolūks<br />

1.2. Darbības sfēra<br />

1.3. Definīcijas, akronīmi un saīsinājumi<br />

1.4. Saistība ar citiem dokumentiem<br />

1.5. Pārskats<br />

2. Vispārējais apraksts<br />

2.1. Produkta perspektīva<br />

2.2. Produkta funkcijas<br />

2.3. Lietotāja raksturiezīmes<br />

2.4. Vispārējie ierobežojumi<br />

2.5. Pieņēmumi un atkarības<br />

3. Konkrētās prasības<br />

3.1. Funkcionālās prasības<br />

3.<strong>1.1.</strong> Funkcionālā prasība 1<br />

3.<strong>1.1.</strong>1. Ievads<br />

3.<strong>1.1.</strong>2. Ievade<br />

3.<strong>1.1.</strong>3. Apstrāde<br />

3.<strong>1.1.</strong>4. Izvade<br />

3.1.2. Funkcionālā prasība 2<br />

.....<br />

3.1.n. Funkcionālā prasība n<br />

3.2. Ārējās saskarnes prasības<br />

3.2.1. Lietotāja saskarne<br />

3.2.2. A<strong>par</strong>atūras saskarne<br />

3.2.3. Programmatūras saskarne<br />

3.2.4. Sakaru saskarne<br />

3.3. Veiktspējas prasības<br />

3.4. Projekta ierobežojumi<br />

3.4.1. Atbilstība standartiem<br />

3.4.2. A<strong>par</strong>atūras ierobežojumi<br />

.....<br />

3.5. Atribūti<br />

3.5.1. Drošība<br />

3.5.2. Uzturamība<br />

.....<br />

3.6. Citas prasības<br />

3.6.1. Datu bāze<br />

3.6.2. Operācijas<br />

3.6.3. Vietas adaptācija<br />

Atsauces<br />

Pielikumi<br />

Indekss<br />

16.10. Projektējuma dokumentācijas sagatave<br />

Projektējuma dokumentācijas sagatave

LVS standarts - Informācijas teh<strong>no</strong>loģija. Ieteicamā prakse programmatūras<br />

projektējuma aprakstīšanai (LVS 72:1996) - iesaka, izstrādājot projektējuma<br />

dokumentu, izmantot šādu sagatavi.<br />

1. Ievads...........................................................................................................................<br />

.....<br />

<strong>1.1.</strong> Nolūks.......................................................................................................................<br />

..<br />

1.2. Darbības<br />

sfēra..............................................................................................................<br />

1.3. Definīcijas un<br />

saīsinājumi..............................................................................................<br />

2. Saistība ar citiem<br />

dokumentiem...........................................................................................<br />

3. Dekompozīcijas<br />

apraksts.....................................................................................................<br />

3.1. Moduļu<br />

dekompozīcija..................................................................................................<br />

3.<strong>1.1.</strong> Pirmā moduļa apraksts...........................................................................................<br />

3.1.2. Otrā moduļa apraksts.............................................................................................<br />

3.2. Vienlaicīgo procesu<br />

dekompozīcija.................................................................................<br />

3.2.1. Pirmā procesa apraksts..........................................................................................<br />

3.2.2. Otrā procesa apraksts............................................................................................<br />

3.3. Datu<br />

dekompozīcija......................................................................................................<br />

3.3.1. Pirmās datu entītijas apraksts.................................................................................<br />

3.3.2. Otrās datu entītijas apraksts...................................................................................<br />

4. Atkarības<br />

apraksts..............................................................................................................<br />

4.1. Starpmoduļu<br />

atkarības..................................................................................................<br />

4.2. Starpprocesu<br />

atkarības.................................................................................................<br />

4.3. Datu<br />

atkarības..............................................................................................................<br />

5. Saskarnes<br />

apraksts............................................................................................................<br />

5.1. Moduļu<br />

saskarne..........................................................................................................<br />

5.<strong>1.1.</strong> Pirmā moduļa apraksts...........................................................................................<br />

5.1.2. Otrā moduļa apraksts.............................................................................................<br />

5.2. Procesu<br />

saskarne........................................................................................................<br />

5.2.1. Pirmā procesa apraksts..........................................................................................<br />

5.2.2. Otrā procesa apraksts............................................................................................<br />

6. Detalizētais<br />

projektējums.....................................................................................................

6.1. Moduļu detalizētais<br />

projektējums...................................................................................<br />

6.<strong>1.1.</strong> Pirmā moduļa<br />

detalizējums.....................................................................................<br />

6.1.2. Otrā moduļa detalizējums.......................................................................................<br />

6.2. Datu detalizētais<br />

projektējums.......................................................................................<br />

6.2.1. Pirmās datu entītijas<br />

detalizējums...........................................................................<br />

6.2.2. Otrās datu entītijas detalizējums.............................................................................<br />

Atsauces...........................................................................................................................<br />

....<br />

16.11. Kvalitātes plāns<br />

Unprintable file: I semestris/Kospekti/Sagataves/8.Kvalitates plans.doc<br />

16.12. Pagrieziena punktu pārskats<br />

Unprintable file: I semestris/Kospekti/Sagataves/9.Pagrieziena punktu <strong>par</strong>skats.doc<br />

16.13. Iknēdeļas statusa atskaite<br />

Unprintable file: I semestris/Kospekti/Sagataves/10.Iknedelas statusa atskaite.doc<br />

16.14. Mēneša progresa atskaite<br />

Unprintable file: I semestris/Kospekti/Sagataves/11.Menesa progresa atskaite.doc<br />

16.15. Projekta riski<br />

Unprintable file: I semestris/Kospekti/Sagataves/12.Projekta riski.doc<br />

16.16. Izmainu pieprasījums<br />

Unprintable file: I semestris/Kospekti/Sagataves/13.Izmainu pieprasijums.doc

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!