1.1. Konspekts Īss pārskats par kursu Izmantoti materiāli no Project Management For Informatio Systems, James Cadle & Donald Yeates, 3rd edition, 2001 Sistēma ir jāmaina ik pa 5 gadiem. Nāk jauna tehnika, programmēšanas valodas un iespējas. Programmatūras izstrādes metodoloģijas Ūdenskrituma modelis

Ūdenskrituma modeļa vēsture aizsākas agrajos 70s gados. Šī modeļa pirmā parādīšanas ir 1970 W Royce publikācija, kurā tika parādīta iespēja formalizēt izstrādes procesus. Ūdenskrituma modelī sistēmas izstrāde ir sadalīta vairākās secīgās aktivitātēs vai fāzēs, kuras katras aktivitātes rezultāts tiek izmantots par ieejas informāciju nākamajai aktivitātei. Mūsdienās par ūdenskrituma modeli sauc jebkuru izstrādes metodoloģiju ar secīgām aktivitātēm neatkarībā no fāžu skaita un specifikas. Šim modelim ir virkne pozitīvu īpašību. Katras aktivitātes beigās tiek pielietota saražoto produktu verifikācija un validācija, kas palīdz sasniegt zināmu kvalitāti. Gadījumos, kad pasūtītāja prasības ir labi zināmas un saprotamas, ūdenskrituma modelis ir īstajā vietā. ‘b’ modelis Viens no ūdenskrituma modeļa trūkumiem ir uzturēšanas fāzes neadekvāta pielietošana. Tā tiek uztverta kā atsevišķa fāze, it kā tai būtu atsevišķa ieejas un izejas informācija. Ūdenskrituma modelī netiek aprakstīta būtiskas uzturēšanas fāzes atšķirības no pārējām aktivitātēm. Jāpatur prātā, ka lielākā daļa darbietilpības, kura tiek patērēta programmatūras produkta dzīves cikla laikā, tiek patērēta uz uzturēšanas aktivitātēm.

‘b’ modeli izstrādāja N. Birrell un M. Ould, adresējot šo ūdenskrituma modeļa vāju vietu. Modelis ieguvis šādu nosaukumu tāpēc, ka tā diagramma ir līdzīga ‘b’ burtam. Modelis būtībā ierosina katru izmaiņu uzturēšanas procesā uzskatīt par atsevišķo izstrādi, kurai ari ir jāiet cauri noteiktām fāzēm un aktivitātēm.

‘V’ modelis Šajā modelī, kurš ir tikai vēl viena variācija par ūdenskrituma modeļa tēmu, veiksmes 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 parāda progresu sākot ar analīzi un projektēšanu līdz kodēšanai un pieaugošam sistēmas sadalījumam komponentēs. Labais V zars attēlo progresējošu sastāvdaļu salikšanu un testēšanu, beidzoties ar programmatūras produkta piegādi. Šī modeļa svarīgā īpašība ir dažādu fāžu savastarpējas atbilstības parādīšana. Piemēram, patstāvīgas programmas vai moduļi tiek testēti pret patstāvīgo moduļu projektējumiem, integrētā sistēmai tiek veikta sistēm-testēšana pret sistēmasp projektējumu un visbeidzot gala sistēmai gala lietotāji veic akcepttestēšanu pret sākotnējām prasībām, noformētām prasību specifikācijā. Šajā modelī ar šīs atbilstības palīdzību, parādās arī kvalitātes nodrošinošie elementi. ‘V’ modelis ir interesants projekta pārvaldniekam arī cita iemesla dēļ. Gadījumos, kad projektā tiek pieaicināti ārējie apakškontraktori, šis modelis nodrošina skaidru izstrādes darba uzdevumu definēšanu un nodevum pārbaudi. Pasoļu izstrādes modelis Arī pasoļu izstrādes modelis ir tikai kārtējais ūdenskrituma modeļa variants. Šo modeli pielieto gadījumos, kad projekta rezultāti tiek piegādāti pakāpeniski, katras fāzes beigās. Šis modelis padara testēšanas un piegādes procesus caurskatāmākus un vieglāk pārvaldāmu, jo gala lietotājs tiek iepazīstināts ar sistēmu jau projekta laikā. Dažreiz var šķist sarežģīti sadalīt sistēmu sastāvdaļās, kuru izstrāde un piegāde var būt neatkarīga. Parasti pēdējā piegāde satur visu iepriekš piegādāto sastāvdaļu integrāciju vienotā produktā, kuru nepieciešams pārtestēt no sākuma līdz galam. Pasoļu piegāde ir saistīta ar ieviešanas procesu, tāpēc jau pirms soļu definēšanas, ir jābūt noskaidrotām visām prasībām. Pasoļu izstrādes modelis nav ieteicams projektos, kuros prasības nav skaidri definētas vai zināmas.

Spirāles modelis Spirāles modelis atšķirās no ūdenskrituma modeļa, piedāvājot evolūcijas vai iteratīvu pieeju sistēmas izstrādei. Ūdenskrituma modelis fokusējas uz fāze-pēc-fāzes procesu

ar gala produktu no iepriekšējās fāzes, nonākot nākamajā. Šis piegājiens strādā labi gadījumos, kad prasības ir labi saprotamas un definētas, kā arī izstrādes vide ir pietiekami stabila. Ļoti bieži gadās situācijas, kad prasības nav zināmas gala lietotājiem, nav skaidri definējamas vai nav skaidrības par sistēmas pielietojumu praksē. Šajās situācijās var pielietot evolūcijas pieeju. Evolūcijas modelis paredz vairāku soļu ciklisku atkārtošanu, sniedzot arvien detalizētākas un skaidrākas prasības, kā arī atkārtojot dzīves ciklu vairākas reizes. Sākotnējā spirāles modeļa autors ir Barry Boehm. Tas ir attēlots zīmējumā zemāk.

Projekts sākas ar spirāles centru un attīstās uz ārpusi. Atrodoties centrā, prasības ir grūti saprotams, bet tiek arvien vairāk papildinātas, virzoties uz priekšu pa spirāli. Kopējās projekta izmaksas pieaug ar katru nākamo soli pa spirāli. Modelis ir sadalīts četros kvadrātos. Kreisajā augšējā kvadrātā tiek noteikti mērķi un identificētas alternatīvas un ierobežojumi. Augšējā labajā kvadrātā alternatības ir novērtētas un riski identificēti un izskatīti. Apakšējā labajā kvadrātā notiek izstrādes uzdevumu risināšana. Apakšējā kreisejā kvadrātā tiek plānota nākamā fāze vai iterācija. Bohema spirāles modelis piedāvā svarīgu koncepciju, kurā mērķu noteikšana, risku pārvaldība un plānošana ir ieļauti vispārējā ciklā. Programmatūras izstrādes projektos lietotie standarti Programmatūras izstrādes projektos tiek lietoti dažādi profesionālie standarti, piemēram, Sistēmas darbības koncepcija LVS 75:1996 PPS – programmatūras prasību specifikācija LVS 70(?):1996 Programmatūras projektējuma apraksts LVS 72:1996 Lietotāja ceļvedis LVS 66:1992

Ir vairākas metodes, kā nofiksēt pasūtītāja vajadzības: Sistēmas darbības koncepcija Programmatūras prasību specifikācija (funkcionālās un nefunkcionālās prasības) Projektētājs izvēlas realizācijas vidi un līdzekļus. Nereti projektētāja lomu uzņemas programmētājs. Programmatūras ieviešanas process ir ļoti sarežģīts – tas ir saistīts ar sistēmas iedzīvināšanu pasūtītāja organizācijā, personāla apmācību. Uzturēšanā notiek sistēmas kļūdu labošana un pasūtītāja atbalsts. Šajā posmā ir jācīnās ar izmaiņām. Vidēji sistēmas uzturēšana ilgst gadus, pēc kuriem sistēma parasti ir jāpārtaisa.

1.2. Standarbu ievērošana IT projektu pārvaldībā Kas ir daudzinātais IEEE/EIA J-STD-016 jeb kādus standartus lietot informācijas sistēmu izstrādē? Likumi un standarti: obligātība un brīvprātība Neviens citas valsts likums vai kādas citas virsnacionālas institūcijas direktīva Latvijā nevar būt spēkā, kamēr to nav apstiprinājusi Saeima. Savukārt, ikvienai personai jāievēro tās valsts likumi, kurā tā atrodas. Te valda obligātība. Citādi ir ar standartiem. Pretēji tam, kā bija PSRS, standarti paši par sevi ir tikai ieteikumi, kuru ievērošana vai neievērošana, arī Latvijā, ir brīvprātīga. Nevienam standartam nav likuma spēka. Standarta ievērošanu padarīt obligātu var vai nu paredzot šādu prasību līgumā, vai arī kādā normatīvā aktā, piemēram, likumā, Ministru Kabineta noteikumos, firmas prezidenta rīkojumā u.tml. Taču standartu neobligātā daba nebūt nenozīmē, ka tie būtu bez apdoma jāignorē. Parasti standartos akumulēta plaša pieredze un tie balansē starp to, ko gribas, un to, ko praktiski var sasniegt. Šādas pieredzes ignorēšana reti kad ved pie laba. Standarti kā kompromiss Kam vajadzīgi standarti, ja to ievērošana nav obligāta? Informācijas tehnoloģija un, it īpaši, programmēšana ir ļoti pateicīgs piemērs atbildei uz jautājumu. Akadēmiski izglītotiem datorprogrammu izstrādātājiem labi zināms (ir teorēmas, kurās tas pierādīts), ka nav nekādas iespējas noskaidrot, vai datorprogramma dara to, kas paredzēts, un nedara neko tādu, kas nav paredzēts. Mēs varam padarbināt programmu vienreiz ar vieniem datiem, otrreiz - ar citiem, trešoreiz utt., un katru reizi redzēt, ka notiek tiešām tas, ko mēs gribējām sagaidīt. Taču vēl ir tūkstošā, miljonā un vēl arī citas reizes, kad būs citi dati. Kas būs tad, uzzināsim tikai tad, kad šī reize būs pienākusi. Tā mēs varam testēt programmu līdz pasaules galam, bet kādreiz taču tā arī "jālaiž darbā". Tātad datorprogrammas pasūtītājs un lietotājs vienmēr varēs gribēt un prasīt, lai programma būtu labāk uztaisīta un vairāk pārbaudīta un atkļūdota. Bet vai viņi var arī gaidīt "pasaules galu" un apmaksāt šo teorētiski nebeidzamo darbu? No juridiskā viedokļa programmētājam ir faktiski neiespējami pārmest kļūdas programmā 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 nepareizas darbības rezultātā dažkārt var būt katastrofāli. Ko darīt? Ja nu lietotājs, cietis zaudējumus, iesūdzēs programmētāju tiesā, ko darīt tiesnesim (kurš vairumā gadījumu nav programmēšanas speciālists un viņam tādam arī nav jābūt)? Viņš jautās ekspertiem, vai programmētājs varēja garantēti nepieļaut kļūdu un zaudējuma rašanos. Eksperti godprātīgi atbildēs, ka tas ir teorētiski neiespējami. Tad tiesnesis jautās, vai programmētājs ir darījis visu saprātīgi nepieciešamo, lai nepieļautu zaudējumus. Kas ir saprātīgi nepieciešamais? Tas ir Standarts! Standarts(-i) ir pašreizējā tehnoloģijas attīstības līmenī nepieciešamais, kompromiss starp gribēto un praktiski iespējamo, vienošanās starp pasūtītāju un izpildītāju, balstoties uz pasaulē uzkrāto pieredzi. Ja programmētājs būs disciplinēti izpildījis visas norunāto standartu prasības, tiesnesis būs spiests viņu attaisnot un zaudējumus atzīt par stihisku nelaimi. Toties līgumā norunāto standartu neievērošanas gadījumā pilnīgi pamatoti tiktu notiesāts izstrādātājs. Starp citu, arī ierēdnis, kas būs pasūtījis programmas pie sava "čoma", nenoslēdzot detalizētu līgumu par disciplinētu standartu ievērošanu, var smagi un pelnīti ciest no sava priekšnieka. Informācijas tehnoloģijas valsts standartu sistēma Vai Latvijai nepieciešami pašai savi informācijas tehnoloģijas standarti? Pareizāk laikam būtu vaicāt, vai Latvijai vispār pietiktu resursu liela daudzuma standartu izstrādei. Arī mūsu virzība uz integrāciju Eiropā prasa harmonizāciju ar starptautiskiem standartiem. Tāpēc izstrādājami tikai tādi standarti, kas nepieciešami Latvijas kā latviešu valsts eksistencei. Skaidrs, ka tie gandrīz vienīgi skars latviešu valodas lietošanas iespēju nodrošināšanu un unifikāciju. Pārējie standarti būs vai nu ISO un Eiropas Savienības standartu tulkojumi, vai arī, ja tie izrādītos retāk vai šaurāk lietojami, tiks iecelti valsts standarta rangā pat bez tulkošanas. Ir vērts piezīmēt, ka ikvienas valsts teritorijā starptautiskiem standartiem ir tikai ieteikumu raksturs, bet spēkā ir tikai tie, kas iecelti valsts standarta rangā. Tomēr, kā jau minējām, pat pēdējiem nav likuma spēka. Standartizācijas procesu Latvijā administrē Ekonomikas ministrijas pārraudzībā esošā SIA "Latvijas Standarts". Šī institūcija pārstāv Latvijas Republiku starptautiskajās standartizācijas organizācijās ISO (Starptautiskā Standartizācijas organizācija) un CEN (Eiropas Standartizācijas organizācija), glabā un izplata standartu tekstus, kā arī organizē valsts standartu izstrādi vai starptautisko standartu adaptāciju. Katrā tautsaimniecības nozarē, kurā notiek kādas standartizācijas darbības, parasti nodibina vienu standartizācijas tehnisko komiteju. Informācijas tehnoloģijas nozarē tāda ir 1995.gada maijā dibinātā Informācijas tehnoloģijas Standartizācijas tehniskā komiteja (ITSTK). Šī komiteja skaidrības labad savā nolikumā ierakstījusi, ka tās darbība aptver precīzi tos pašus jautājumus, kas ir ISO/IEC Pirmās apvienotās tehniskās komitejas (ISO/IEC Joint Technical Committee One) kompetencē. Kā zināms, šīs komitejas aptvertā nozare saucas "information technology". Tomēr vēlreiz jāpasvītro, ka visas minētās un neminētās standartizācijas un terminoloģiskās aktivitātes nerada visiem obligātus likumus. Tikai valsts var noteikt, kuri standarti ievērojami obligāti, kā tā to ir darījusi, izdodot pazīstamos Ministru Kabineta Noteikumus [1]. Pašreizējais stāvoklis Iespējamas Latvijas IT standartu izstrādes stratēģijas ir jau pasniegtas un aprakstītas 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 vairums standartu plaši lietoti netiek. Daudzos gadījumos būs jāapmierinās ar t.s. pirmās lappuses (cover page) metodi, kad standarta pirmā lappuse satur anotāciju latviski, bet viss pārējais teksts ir atstāts kādā no Eiropas standartizācijas organizāciju darba valodām - angļu, franču vai vācu, parasti - angļu. Vairums standartu būtu jāadaptē vispār bez jebkādas tulkošanas, kad Informācijas tehnoloģijas standartizācijas tehniskā komiteja (ITSTK) iesaka apstiprināt un nacionālā standartizācijas institūcija SIA "Latvijas Standarts" izziņo, ka tādi un tādi Eiropas standarti ir apstiprināti par valsts standartiem. Tomēr ITSTK ir stingri noteikusi, ka standarta adaptēšanas obligāts priekšnosacījums, neatkarīgi no metodes izvēles, ir standarta oriģinālā teksta brīva (ne obligāti bezmaksas) pieejamība Latvijā, bet terminoloģijas standarti gan ir jātulko visi. Programminženierijas standarti Katrai nozarei ilgstoši pastāvot, neizbēgami rodas šīs nozares pieredze un prakse. Standartos tiek apkopota attiecīgās nozares labākā prakse. Šos standartus izstrādā (parasti) starptautiskas organizācijas, kurās piedalās izcilākie attiecīgās nozares speciālisti. Standartu lietošana ir izplatīts paņēmiens kā panākt stabilitāti izstrādājamā produkta kvalitātē, tādējādi standartu ievērošanai jākļūst par neatņemamu prasību ikreiz, kad tiek slēgti piegādātāja - pasūtītāja līgumi par produkta piegādi. Viss nupat pieminētais pilnā mērā attiecas arī uz programminženierijas nozari. Jāpiebilst, ka standartu esamība neatrisina programminženierijas kvalitātes un produktivitātes problēmas. Standartu veiksmīga pielietošana iespējama tikai organizācijā, kurā ir atbilstoši apmācīts personāls un uzkrāta pieredze. Personāla ziņā ir prast pielietot atbilstoši situācijai tos ieteikumus, kurus standarti satur. Ieteikumi programmatūras dokumentācijas komplektam Turpmāk dota informācija par materiāliem (Latvijas valsts un starptautiskiem standartiem), kuri reglamentē programmatūras produktu izstrādes procesu un apraksta dokumentu veidu un dokumentos ietveramo informāciju, kura ir jāsagatavo programmatūras produktu izstrādes, uzturēšanas un darbināšanas (ekspluatēšanas) vajadzībām. Īpaši svarīgi šos noteikumus ievērot ir tādu nozīmīgu programmatūru izstrādē kā valsts nozīmes informācijas sistēmas. Izstrādāti priekšlikumi t.s. minimālā, ieteicamā un pilnā dokumentu komplekta sastāvam, kā arī raksturota minēto dokumentu nozīme. Visi ieteikumi ir veidoti, izmantojot starptautiskos, Latvijas valsts un citos standartos doto informāciju. Balstoties uz programmatūras projektu izstrādes laikā novērotās pieredzes, minēti apsvērumi, kā konkrētā projektā izvēlēties izstrādājamo dokumentu komplektu. Pēc šīs informācijas vēlams vadīties arī zemākas nozīmes programmatūru gadījumā, ja to pasūta valsts vai pašvaldību institūcijas. Ieteikumi domāti programmatūras produkta lietotājorganizācijas vai pasūtītājorganizācijas visu līmeņu vadītājiem un darbiniekiem, lai nodrošinātu standartiem atbilstošu informāciju par nepieciešamo programmatūras produkta dokumentāciju un tās saturu. Šeit apkopota īsa informācija par tiem dokumentu veidiem, kuri var tikt sagatavoti programmatūras izstrādes gaitā. Ņemot vērā šo dokumentu lomu programmatūras izstrādē un lietošanā, kā arī standartos apkopotos programmēšanas prakses ieteikumus, šie dokumenti ir sagrupēti trīs grupās - minimālais, ieteicamais un pilnais dokumentu komplekts. Šie dokumentu saraksti var tikt izmantoti, pasūtītājam un izpildītājam vienojoties par konkrētai programmatūrai sagatavojamiem dokumentiem. Papildus informācija, kas nepieciešama, lai izvēlētos 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 noteikti darba apjomi, termiņi, savstarpējais darbu sadalījums, kā arī citi izstrādei būtiski momenti. Informācija izmantojama, lai noteiktu prasības izstrādātāja piegādātai dokumentācijai, kā arī lai pārbaudītu šīs dokumentācijas atbilstību prasībām. Definīcijas Izmantotas definīcijas un pamatjēdzieni (ISO 12119 un EIA/IEEE J-STD-016): Apskate (review) - programmatūras elementa(-u) vai projekta stāvokļa novērtēšana, lai noskaidrotu pretrunas ar plānotajiem rezultātiem un ieteiktu uzlabojumus. Šī novērtēšana ir formalizēts process piemēram, pārvaldības apskates process, tehniskās apskates process, programmatūras inspekcijas process vai caurskates (walkthrough) process. Auditēšana (audit) - neatkarīga programmatūras produkta vai procesa novērtēšana, lai noskaidrotu atbilstību standartiem, vadlīnijām (guidelines), specifikācijām un procedūrām. Datu bāze - savstarpēji saistītu datu kopums, kas datorā tiek uzglabāts kopā vienā vai vairākās datnēs. Ievaddati (input data) - dati, ko programmatūra saņem no ārēja avota. Izvaddati (output data) - dati, ko programmatūra nodod ārējam saņēmējam (mērķim). Kritiska programmatūra (critical software) - programmatūra, kuras kļūme dotu triecienu drošībai vai varētu būt cēlonis lieliem finansiāliem vai sociāliem zaudējumiem. Lietotāja dokumentācija - pilns dokumentācija komplekts drukātā vai elektroniskā formā, kas nodrošina programmatūras lietošanu un vienlaikus ir programmatūras produkta sastāvdaļa. Nododamais dokuments jeb nodevums (deliverable) - ikviens dokuments, ko sagatavo projekta izstrādāšanas laikā projekta vajadzībām, un nodod pasūtītājam kārtējā darba etapa vai visa projekta noslēgumā. Pieļaujamā vērtība - vērtība, kādu var pieņemt ievaddati, sistēmas iekšējie dati vai izvaddati programmatūras normāla darba režīma laikā. Prasību dokumentācija (arī prasību specifikācija) - dokuments, kas satur jebkādu rekomendāciju, prasību vai priekšrakstu kopumu, kurš programmatūrai ir jāapmierina. Produkta apraksts - dokuments, kurā aprakstītas programmatūras īpašības ar nolūku palīdzēt potenciāliem lietotājiem novērtēt produkta atbilstību savām prasībām. Produkta atbalsts (product support) - nodrošināšana ar informāciju, palīdzību vai apmācīšanu, lai instalētu programmatūru un sagatavotu to darbināšanai tai paredzētajā apkārtnē un lai padarītu pieejamas lietotājam paredzētās iespējas. Programmatūras dzīves cikls - ietver visu posmu, sākot no tā, ka ir radusies ideja kādu programmatūru izstrādāt, un beidzot ar brīdi, kad tiek izbeigta šīs programmatūras lietošana. Programmatūras pakotne (produkts) (software package) - pabeigts un dokumentēts programmu kopums, ko piegādā lietotājam noteiktu funkciju izpildīšanai. Programmatūras projektējuma apraksts (Software Design Description) - programmatūras sistēmas dokumentēts attēlojums, kas tiek radīts, lai atvieglotu izstrādājamās programmatūras analīzi, plānošanu, īstenošanu un lēmumu pieņemšanu. Tas ir programmatūras sistēmas uzmetums vai modelis, kuru izmanto turpmākā izstrādes gaitā. Programmatūras uzturēšana (software maintenance) - programmatūras ekspluatācijas 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 gadījumā. Programmatūras uzturēšanas rokasgrāmata - dokuments, kurš nodrošina visu informāciju, kas nepieciešama programmatūras uzturēšanai. Programmatūras vienums (software item) - pirmkods, objektkods, vadības dati vai šo vienumu kopums. Projekta iekšējais dokuments - dokuments, ko sagatavo projekta izstrādāšanas laikā projekta vajadzībām, bet nenodod pasūtītājam. Saskarne (interface) - aparatūras vai programmatūras komponenti, kas sasaista divus vai vairākus citus komponentus, vai arī lietotāju un programmatūru, lai nodotu informāciju no viena komponenta otram, vai arī no lietotāja programmatūrai un otrādi. Validācija (validation) - programmatūras novērtēšana programmatūras izstrādāšanas procesa beigās, lai pārliecinātos par atbilstību programmatūras prasībām. Verifikācija (verification) - process, kurā nosaka, vai produkts dotajā programmatūras izstrādes fāzē izpilda vai neizpilda iepriekšējo fāzu izvirzītās prasības. Programmatūras izstrādi reglamentējošie standarti un noteikumi Izstrādājot valsts institūciju rīcībā esošas sistēmas, kas paredzētas likumos un Ministru kabineta noteikumos minētas informācijas apstrādei un glabāšanai, kā, piemēram, Nodokļu maksātāju reģistrācijas un nodokļu uzskaites sistēma, jebkurā izstrādes vai uzturēšanas stadijā jāievēro atbilstība prasībām, kuras ir noteiktas valsts nozīmes datorizētām informācijas sistēmām [1]. Īpaši svarīgi ir ievērot punktu 13.10., kas skan šādi: "sistēmu veidojot, jānodrošina tās uzturēšana un pēctecība, kā arī dokumentācijas atbilstība valsts standartiem, ērta lasāmība un pieejamība". Izstrādājot vai pasūtot programmatūru, ieteicams vadīties pēc šādiem Latvijas Valsts un starptautiskajiem standartiem: 1. Valsts standarti, kas nosaka latviešu valodas lietošanu un kultūras īpatnības: 2. Informācijas tehnoloģija, kodētas simbolu kopas. 8 bitu kodēto grafisko simbolu kopa Baltijas jūras reģiona valstīm (LVS 8-92) 3. Informācijas tehnoloģija, datoru tastatūras. Latviešu tastatūra datoriem (LVS 23-93) 4. Informācijas tehnoloģija, valodas lietošana datoros. Latviešu valoda datoriem (LVS 24-93) 2. Valsts standarti, kas nosaka programmatūras dokumentēšanu dažādās tās attīstības stadijās: 1. Informācijas tehnoloģija. Programmatūras lietotāja dokumentācija (LVS 66:1996) 2. Informācijas tehnoloģija. Programmatūras prasību specifikācijas (PPS) ceļvedis (LVS 68:1996) 3. Informācijas tehnoloģija. Programmatūras testēšanas dokumentācija (LVS 70:1996) 4. Informācijas tehnoloģija. Ieteicamā prakse programmatūras projektējuma aprakstīšanai (LVS 72:1996) 5. Informācijas tehnoloģija. Sistēmas darbības koncepcijas apraksts (LVS 75:1996) 3. Valsts standarti, kas nosaka programmatūras izstrādes procesa dokumentēšanu dažādās tās attīstības stadijās: 1. Informācijas tehnoloģija. Programmatūras projekta pārvaldības plāns (LVS 67:1996) 2. Informācijas tehnoloģija. Programmatūras konfigurācijas pārvaldības plāns (LVS 69:1996) 3. Informācijas tehnoloģija. Programmatūras verifikācijas un validācijas plāns (LVS

71:1996) 4. Valsts standarti, kas nosaka programmatūras kvalitātes nodrošināšanas pasākumu veikšanu: 1. Informācijas tehnoloģija. Programmatūras kvalitātes nodrošināšanas plāns (LVS 65:1996) 2. Informācijas tehnoloģija. Programmatūras vienībtestēšana (LVS 73:1996) 3. Informācijas tehnoloģija. Programmatūras apskates un auditēšanas (LVS 74:1996) 5. Starptautiskais standarts, kas nosaka visa programmatūras dzīves cikla procesus, nepieciešamo dokumentāciju un tās saturu: 1. Standard for Information Technology. Software Life Cycle Processes. Software Development. Acquirer-Supplier Agreement (EIA/IEEE J-STD-016) 6. Starptautiskais standarts, kas nosaka programmatūras dzīves cikla procesus: 1. Information technology - Software life cycle processes (ISO/IEC 12207) 7. Starptautiskais standarts, kas nosaka prasības programmatūras produktam, kā arī to, kā veikt produkta testēšanu atbilstoši šīm prasībām: 1. Information technology. Software packages. Quality requirements and testing. (ISO/IEC 12119) 1. PIEZĪME. Jāņem vērā, ka IEEE standartu kopa (std.610.12-1990 - std. 1219-1992) un Latvijas valsts standarti (LVS 65:1996- LVS 74:1996) atspoguļo vienu vienotu pieeju programmatūras izstrādes un dokumentēšanas procesam, bet standarti EIA/IEEE J-STD-016 un LVS 75:1996 otru, nedaudz atšķirīgu. Tādēļ programmatūras izstrādes procesa sākumā nepieciešams vienoties, kura no šīm koncepcijām tiks ņemta par pamatu. Šādā gadījumā otras grupas standartus var izmantot atsevišķu jautājumu vai dokumentu detalizēšanai. Ieteicams lietot EIA/IEEE J-STD-016, jo tas ir jaunāks, kaut gan nav tulkots latviski. Standartu pieejamība Latvijas nacionālos jeb valsts standartus saskaņā ar nolikumu drīkst izplatīt tikai SIA "Latvijas Standarts", kura adrese ir šāda: Kr.Valdemāra ielā 157, LV-1013, Rīgā, tel. 7 362 250 (standartu bibliotēka). Bibliotēkā atrodami ISO/IEC un CEN standartu teksti, kas apstiprināti aptuveni pēc 1995. gada, kad Latvija iestājās minētajās organizācijās. Tur atrodami arī daudzi, bet ne visi agrāk apstiprinātie ISO/IEC standarti. Agrāku gadu ISO/IEC u.c. standarti atrodami arī Latvijas Patentu Tehniskajā bibliotēkā (Šķūņu ielā 17; LV-1050, Rīgā, fakss 7 210 767, tel. 7 227 310). IEEE standartus var pasūtīt, piemēram, pa faksu 1.908.981.9667 Tiešsaistes (on-line) informācija par IEEE standartiem iegūstama globālā tīmeklī: http://stdsbbs.ieee.org/ Pasta adrese: IEEE Customer Service The Institute of Electrical and Electronics Engineers, Inc. 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, U.S.A. Ar visiem minētiem tekstiem var iepazīties (bet ne kopēt, jo to nepieļauj autortiesību ierobežojumi) arī Rīgas Informācijas tehnoloģijas institūtā. Programmatūras lietošanai un uzturēšanai nepieciešamā dokumentācija Standarti un metodiskie materiāli, kas regulē jebkuras programmatūras izstrādi, operē ar tādu jēdzienu kā programmatūras dzīves cikls, kas ietver visu posmu sākot no tā, ka 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 no tā, vai šo dzīves ciklu uzskata kā sastāvošu no dažādiem etapiem vai dažādiem procesiem, tā neatņemamas, visciešāk ar lietotāju saistītās sastāvdaļas ir programmatūras darbināšana jeb ekspluatācija (operation) un uzturēšana (maintenance). Reāli programmatūras darbināšana sākas ar brīdi, kad tā tiek oficiāli nodota pasūtītājam. Iespējamie dokumentācijas komplekti Standarts ISO/IEC 12119 nosaka, ka programmatūras produktam, kurš tiek izplatīts vai nodots pasūtītājam, ir jāsatur programma (un dati, ja tādi nepieciešami), kā arī jābūt apgādātam ar dokumentāciju, kura ietver produkta aprakstu un lietotāja dokumentāciju. Tas var būt pietiekami gadījumos, kad lietotājs programmatūras produktu tikai izmanto, bet neveic nekādu tā labošanu, modificēšanu u. tml. Šādā gadījumā lietotāja rīcība ierobežojas tikai ar programmatūras darbināšanu, kā arī tās gaitā atklāto kļūdu un neatbilstību fiksēšanu. To novēršanas kārtība ir atkarīga no programmatūras pasūtītāja un piegādātāja (izstrādātāja vai pārdevēja) savstarpējām attiecībām, kuras iepriekš norunātas un dokumentētas atbilstošā veidā (ar līgumu, līguma pielikumu u.tml.). Pieredze rāda, ka programmatūras ilgstošas lietošanas laikā ir nepieciešams veikt tās būtiskas modifikācijas, kā pārvietošanu uz citu aparatūru, pārveidošanu atbilstoši mainītām pasūtītāja vajadzībām utt. Piemēram, ja programmatūras darbība lielā mērā ir atkarīga no spēkā esošās likumdošanas, ir sagaidāms, ka tās uzturēšanas laikā nāksies izdarīt daudzus pārveidojumus. Šādos gadījumos programmatūras uzturēšana, neatkarīgi no tā, kas to veic, ir iespējama tikai tad, ja papildus iepriekš minētai dokumentācijai programmatūras produkta izstrādes laikā ir sagatavota vēl virkne būtisku dokumentu. 1.tabulā ir dots visu programmatūras lietošanai un uzturēšanai nepieciešamo dokumentu saraksts, kā arī dotas rekomendācijas t.s. minimālam, ieteicamam un pilnam dokumentu komplektam. Tabula 1. Programmatūras uzturēšanai nepieciešamā dokumentācija.

Dokumenta nosaukums Komplekts Rekomendējošie materiāli dokumenta izstrādei Min Ieteic Pilns Programmatūras lietošanai nepieciešamā dokumentācija Programmatūras produkta apraksts + + ISO/IEC 12119; EIA/IEEE J-STD-016 (I.2.1.) Programmatūras versijas apraksts + + EIA/IEEE J-STD-016 (I.2.2.)

Programmatūras lietotāja dokumentācija + + + LVS 66:1996; ISO/IEC 12119; EIA/IEEE J-STD-016

Programmatūras instalēšanas apraksts* + + + EIA/IEEE J-STD-016 (E.2.3.) Programmatūras izpildkodi + + + EIA/IEEE J-STD-016 (I.2.1.) Programmatūras uzturēšanai papildus nepieciešamā dokumentācija Programmatūras darbības koncepcijas apraksts + + LVS 75:1996; EIA/IEEE J-STD-016 (F.2.1.)

Programmatūras prasību specifikācija + + + LVS 68:1996;EIA/IEEE J-STD-016 (F.2.2., F.2.3., F.2.4.)

Programmatūras projektējuma apraksts + + LVS 72:1996; EIA/IEEE J-STD-016 (G.2.1., G.2.2., G.2.4.)

Datu bāzu projektējuma apraksts* + + + EIA/IEEE J-STD-016 (G.2.3.) Programmatūras pirmkodi + + + EIA/IEEE J-STD-016 (G.2.1.) Programmatūras uzturēšanas rokasgrāmatas + EIA/IEEE J-STD-016 (5.13.8.)

Programmatūras uzturēšanas plāns + ISO/IEC 12007 Programmatūras uzturēšanas procedūra + ISO/IEC 12007

Dokumenti, kuri ietverami attiecīgā komplekta sastāvā, atzīmēti ar "+"ailē Komplekts (Min, Ieteic un Pilns attiecīgi). Analizējot šos dokumentu komplektus, jāņem vērā nākamajā punktā dotā informācija. Minimālais komplekts ietver tos dokumentus, bez kuriem faktiski nav iespējama ne programmatūras lietošana, ne uzturēšana, t.i., tos dokumentus, bez kuriem programmatūra nav uzskatāma par pabeigtu un nevar tikt pieņemta. Ieteicamajā komplektā iekļauti tie dokumenti, kuri nodrošina normālu programmatūras lietošanu un neliela apjoma pārveidojumu (pārprogrammēšanas) veikšanu tās uzturēšanas laikā. Protams, t.s. ieteicamais komplekts nav vienīgais iespējamais un konkrētā gadījumā, ja to prasa projekta īpatnības, no tā var nedaudz atkāpties uz vienu vai otru pusi. Pilnajā komplektā norādītie dokumenti atspoguļo pilnu informāciju, kura ir izstrādātāja rīcībā par programmatūras produktu, un kura ir nepieciešama gan pašam izstrādātājam jaunu produkta versiju attīstīšanai, gan arī personālam, kurš veic programmatūras būtisku mainīšanu un pilnveidošanu tās uzturēšanas laikā. Dokumentācijas komplektu īss raksturojums Apvienojot 1.tabulā dotos dokumentus minimālā, ieteicamā un pilnā dokumentu komplekta sastāvā, tika ņemti vērā šādi apsvērumi: 1. standartos aprakstītais attiecīgo dokumentu sastāvā ietveramās informācijas raksturs; 2. programmatūras izstrādāšanas gaitā radusies pieredze, kas uzkrāta un apkopota starptautiskos standartos; 3. programmatūras izstrādes un kvalitātes pārvaldības funkciju izpildes laikā novērotā un uzkrātā pieredze. Šis dalījums faktiski atspoguļo informācijas novērtējumu - lai programmatūru lietotu, ir vajadzīgs vismaz tas, kas ietverts minimālā dokumentu komplekta sastāvā. Ja nepieciešams pa laikam drusku kaut ko mainīt vai labot darba gaitā atklātās kļūdas, tad jābūt pieejamai tai informācijai, kura ietverta ieteicamā komplekta sastāvā, bet ja nepieciešama nopietna modificēšana, tad var būt nepieciešama visa tā informācija, kas iekļaujama pilnā dokumentu sarakstā minētajos dokumentos. Šajā skatījumā nav svarīgi, kā rīcībā šie dokumenti atrodas, piemēram, nesagatavojot dokumentētā formā vismaz to informāciju, kura ir ietverta minimālā komplekta sastāvā, nevar būt runas par to, ka programma būtu pabeigta un to varētu pieņemt. Agri vai vēlu, tādu programmu nebūtu spējīgs lietot pat tās izstrādātājs. Turklāt arī šī informācija ir atkarīga no konkrētās programmatūras veida. Piemēram, ja programmatūra nestrādā ar datu bāzēm, 1.tabulas 2.3.1. punktā minētam dokumentam nav jēgas. Toties, lietojot datu bāzu sistēmas, ja bez programmu apraksta pieredzējis programmētājs vēl kaut kā var tās uzturēt, tad bez datu bāzu apraksta tas nekādi nav iespējams. 1.tabulā doto informāciju kopumā vēlreiz var raksturot šādi - tajā ir dots visu standartos minēto dokumentu saraksts, kuru saturā tiek ietverta informācija, kas nepieciešama programmatūras lietošanas un uzturēšanas gaitā. Tieši kāda ir šī informācija - tas ir atkarīgs no konkrētās programmatūras un no līgumā noteiktām pasūtītāja un izstrādātāja attiecībām. Jāņem vērā, ka tabulā izmantotie standartos minētie attiecīgo dokumentu NOSAUKUMI NAV OBLIGĀTI, toties standartos prasītā informācija - ir gan; tāpat nav obligāti katru no minētajiem materiāliem noformēt kā patstāvīgu dokumentu. Toties OBLIGĀTI ir abām pusēm (pasūtītājam un izpildītājam) vienoties par

paredzēto dokumentu komplektu, to konkrētiem nosaukumiem un par to, kur kāda veida informācija tiks izvietota, un šo VIENOŠANOS DOKUMENTĒT. Šīs vienošanās laikā pats svarīgākais ir novērtēt konkrētās programmatūras īpatnības un izvēlēties tām atbilstošākos dokumentus. Bez tabulā dotajām rekomendācijām, ir iespējama arī jebkura cita komplektācija, izņemot minimālās samazināšanu. Kā jau minēts augstāk, 1. tabulā nav atspoguļots tas, kura no minētās dokumentācijas tiek nodota pasūtītājam un kura paliek tikai programmatūras izstrādātāju rīcībā. Nododamās dokumentācijas komplekts ir atkarīgs, pirmkārt, no tā, kas veiks programmatūras uzturēšanu. Šo darbu sadali vēlams īpaši atrunāt līgumā, vai arī slēgt atsevišķu līgumu par programmatūras uzturēšanu. Jāņem vērā, ka veicamā darba apjoms un līdz ar to programmatūras uzturēšanai nepieciešamais personāls un izmaksas ir aptuveni vienādas gan tad, ja programmatūras uzturēšanu veic lietotājs, gan tad, ja to dara programmatūras izstrādātājs. Lietotāja gadījumā izmaksas un darbietilpība būs lielāka vēl par tik, cik vajadzīgs, lai apgūtu programmatūras darbību un pirmkodus līdz tādam līmenim, ka ir iespējams veikt to modificēšanu. Par nododamās dokumentācijas (deliverables) komplektu pasūtītājam un izstrādātājam jāvienojas atsevišķi, rakstiski dokumentējot šo vienošanos (piemēram, līguma pielikumā). Jāņem vērā, ka dokumentu sagatavošana, īpaši ja tie tiek gatavoti nodošanai lietotājam, ir darbietilpīga un līdz ar to arī dārga. Turklāt jāņem vērā, ka programmatūras uzturamība nebūt nepieaug proporcionāli tās dokumentācijas apjomam. Pārāk liels dokumentācijas apjoms izsauc pretēju efektu - to sagatavot un apgūt ir ļoti darbietilpīgi, var būt grūti lietot. Turklāt arī pieaug bīstamība, ka nav pilnībā izsekotas un atspoguļotas visas izmaiņas, kas tiek izdarītas programmatūras dzīves jebkurā etapā. Pēdējais moments ir sevišķi bīstams, jo padara dokumentāciju pretrunīgu. Vienkāršoti runājot, programmatūras lietošanā un tai atbilstošās dokumentācijas sagatavošanā var būt šādas raksturīgas situācijas. A. Programmatūra veic kādas noteiktas funkcijas, kuras praktiski nav nepieciešams mainīt. Turklāt starp programmatūras pasūtītāju un izstrādātāju ir noslēgts līgums par programmatūras uzturēšanu atbilstoši kuram programmatūras lietošanas laikā atklātās kļūdas labo izstrādātājs. Šādā gadījumā lietotājam tiešām praktiski pietiek ar lietotāja dokumentāciju (kurā var būt ietverts arī instalēšanas apraksts, ja tāds nepieciešams) un programmatūras izpildkodiem. Visa pārējā dokumentācija, kas nepieciešama kļūdu labošanai, atrodas pie programmatūras izstrādātājiem. Šāda situācija ir raksturīga arī komerciālu programmatūru gadījumos, kad izstrādātājs ir īpaši ieinteresēts aizsargāt autortiesības. Šādiem produktiem programmatūras pirmkodi parasti ir tikai izstrādātāja rīcībā. B. Programmatūra veic kādas noteiktas funkcijas, kuras laiku pa laikam var būt nepieciešams mainīt. Šādos gadījumos, protams, ir iespējams arī iepriekšējā punktā minētais sadarbības variants. Ja programmatūras uzturēšanu pilnībā vai daļēji pārņem pasūtītājs, tādā gadījumā ir rūpīgi jāizanalizē, kāda apjoma izmaiņas veic viena vai otra puse un tā jānodrošina ar atbilstošo dokumentāciju. Katrā ziņā, lietotāja rīcībā ir nepieciešami programmatūras pirmkodi. Ieteikumi varētu būt šādi - sākot jau no programmatūras projektēšanas, liela uzmanība ir jāpievērš tādai prasībai, kā programmatūras modificējamība, un konstanti jāuzrauga tās īstenošana. Pasūtītājam (un līdz ar to turpmākam lietotājam) var būt lietderīgi pārņemt savā ziņā operatīvu kļūdu labošanu un lokālu izmaiņu izdarīšanu, kā, piemēram, izmaiņas, kas saistītas ar kāda maksājuma aprēķināšanas algoritma maiņu. Šo pienākumu sadalei ir raksturīgs, ka, jo vairāk funkciju veic izpildītājs, jo vairāk pasūtītājs ir no tā atkarīgs, turklāt ir nepieciešams zināms papildus laiks darba attiecību noformēšanai. Savukārt no

lietotāja programmatūras uzturēšana prasa, lai būtu nodrošināti atbilstošas kvalifikācijas speciālisti. Šiem speciālistiem darbs var būt tikai periodisks, turklāt, atšķirībā no izstrādātājiem, var būt darbietilpīgāks, jo profesionālam programmētājam apgūt cita izstrādātas programmas ir iespējams tikai ar zināmu papildus darba patēriņu. Tādējādi lielāka apmēra izmaiņu izdarīšanu var būt lietderīgi uzticēt izstrādātājam. Turklāt pēdējā gadījumā ne vienmēr tas būs sākotnējais programmatūras izstrādātājs. IETEIKUMS! Lai jebkurā programmatūras dzīves cikla posmā būtu iespējams izvēlēties kādu no sadarbības variantiem, svarīgi ir pašā izstrādes sākumā un turpmāk jebkuru nopietnu izmaiņu izdarīšanas laikā paredzēt, ka šādiem gadījumiem nepieciešamie dokumenti vispār tiks izstrādāti. Tie var tikt nodoti lietotāja rīcībā tūlīt, var būt līgumā paredzēti nosacījumi, ka tiek nodoti vēlāk zināmās situācijās, vai paredzēts vēl kāds cits piemērots variants. Pilnas projekta dokumentācijas raksturojums Iepriekšējā nodalījumā tika aplūkoti tikai tie standartu ieteiktie programmatūras produkta izstrādes dokumenti, kuri ir saistīti ar programmatūras lietošanu un uzturēšanu. Vienlaikus esam jau teikuši, ka pašā izstrādes sākumā un turpmāk jebkuru nopietnu izmaiņu izdarīšanas brīdī pats svarīgākais ir paredzēt, ka šādiem gadījumiem nepieciešamie dokumenti vispār tiks izstrādāti. Lai pārliecinātos, ka visā programmatūras attīstības gaitā tiek veikti pasākumi, kas nepieciešami, lai gala produkts atbilstu tam izvirzītajām prasībām, var būt nepieciešami vai vēlami vēl citi dokumenti, nekā minēti programmatūras lietošanai un uzturēšanai minētajā sarakstā. Daži no šiem dokumentiem var būt arī papildus noderīgi brīžos, kad tiek veiktas būtiskas modifikācijas. Tādēļ 2.tabulā tiek dots visu to dokumentu saraksts, kurus standarti iesaka izstrādāt programmatūras projekta dažādos etapos. Lai iegūtu pilnīgu kopskatu, šajā sarakstā ir iekļauti arī iepriekšējā nodaļā aplūkotie dokumenti. Līdzīgi kā 1.tabulā, dokumenti šeit ir iekļauti minimālā, ieteicamā un pilnā dokumentu komplekta sastāvā, kuri raksturo dokumentos iekļautās informācijas apjomu. Tabula 2. Programmatūras izstrādes dokumentācijas pilns saraksts.

Dokumenta nosaukums Komplekts Rekomendējošie materiāli dokumenta izstrādei Min Ieteic Pilns Projekta sagatavošanas un uzturēšanas dokumenti Sākotnējie projekta priekšlikumi (Preliminary Design Proposal) + + DATI firmas standarts

PKN.STD.PPPR.22.1.B.1995 Līgums ar pasūtītāju + + + Līguma izpildes kalendārais plāns* + + + Projekta dienasgrāmata + + Programmatūras izstrādes datne + + EIA/IEEE J-STD-016 Projekta plānošanas dokumenti Programmatūras (Sistēmas) izstrādes plāns + EIA/IEEE J-STD-016 Projekta pārvaldības plāns* + LVS 67:1996; IEEE 1058.1 Programmatūras konfigurācijas pārvaldības plāns* + + LVS 69:1996; IEEE 1042, IEEE 828

Projekta iekšējo pārbaužu plāns* + + Kvalitātes nodrošināšanas plāns* (Software Quality Assurance Plan) + + LVS 65:1996; IEEE 730.1

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

plāns Programmatūras (kvalifikācijas) testēšanas plāns + + + LVS 70:1996; EIA/IEEE J-STD-016, IEEE 829

Programmatūras pārcelšanas (transition) plāns + EIA/IEEE J-STD-016 Programmatūras instalēšanas plāns +* + + EIA/IEEE J-STD-016 (E.2.3.) Projekta specifikācijas Darbības koncepcijas apraksts (Operational Concept Description) + + LVS 75:1996; EIA/IEEE J-STD-016 (F.2.1.)

Sistēmas/apakšsistēmas (kopā ar aparatūru) prasību specifikācija + + + LVS 72:1996; EIA/IEEE J-STD-016 (F.2.2.)

Programmatūras prasību specifikācija (Software Requirements Specification) + + + LVS 72:1996; EIA/IEEE J-STD-016 (F.2.4.)

Saskarņu prasību specifikācija* + + + LVS 72:1996; EIA/IEEE J-STD-016 (F.2.3.) Programmatūras produkta specifikācija + + ISO/IEC 12119; EIA/IEEE J-STD-016 (I.2.1.) Programmatūras versijas apraksts + + EIA/IEEE J-STD-016 (I.2.2.) Projektējumu (design) dokumentācija Sistēmas/apakšsistēmas (kopā ar aparatūru) projektējuma apraksts + + LVS 72:1996; EIA/IEEE J-STD-016 (G.2.1.)

IEEE 1016

Programmatūras projektējuma apraksts + + LVS 72:1996; EIA/IEEE J-STD-016 (G.2.4.) IEEE 1016

Saskarņu projektējuma apraksts* + + LVS 72:1996; EIA/IEEE J-STD-016 (G.2.2.) IEEE 1016

Datu bāzu projektējuma apraksts* + + + LVS 72:1996; EIA/IEEE J-STD-016 (G.2.3.) IEEE 1016

Implementēšanas dokumentācija Programmatūras pirmkodi + + + EIA/IEEE J-STD-016 (G.2.1.) Programmatūras izpildkodi + + + EIA/IEEE J-STD-016 (I.2.1.) Lietotāja dokumentācija

Lietotāja rokasgrāmata + + + LVS 66:1996; ISO/IEC 12119; EIA/IEEE J-STD-016 (J.2.1.)

Datora programmēšanas rokasgrāmata** + EIA/IEEE J-STD-016 (I.2.3.) Programmaparatūras atbalsta rokasgrāmata** + EIA/IEEE J-STD-016 (I.2.4.) Programmatūras uzturēšanas rokasgrāmatas + EIA/IEEE J-STD-016 (5.13.8.) Programmatūras ievadizvades rokasgrāmata + EIA/IEEE J-STD-016 (J.2.2.) Datora darbināšanas rokasgrāmata + EIA/IEEE J-STD-016 (J.2.4.) Testēšanas dokumentācija

Programmatūras testēšanas apraksts + + + LVS 70:1996; LVS 73:1996; EIA/IEEE J-STD-016 (G.2.3.); IEEE 1008; IEEE 829

Testu projektējuma specifikācija + + LVS 70:1996; IEEE 829 Testpiemēru specifikācijas + + LVS 70:1996; IEEE 829 Testēšanas procedūras specifikācija + + LVS 70:1996; IEEE 829 Testēšanas žurnāls + + + LVS 70:1996; IEEE 829

Problēmu ziņojumi + + LVS 70:1996; IEEE 829; firmas problēmu reģistrācijas rīks

Testēšanas (kopsavilkuma) pārskats + + + LVS 70:1996; IEEE 829 Projekta iekšējo pārbaužu pārskatu dokumentācija Programmatūras izstrādes plāna apskates pārskats + LVS 74:1996

Programmatūras testēšanas plāna apskates pārskats + + + LVS 74:1996

Programmatūras instalēšanas plāna apskates pārskats + + + LVS 74:1996

Programmatūras pārcelšanas (transition) plāna apskates pārskats + LVS 74:1996

Programmatūras projekta pārvaldības plāna apskates pārskats + LVS 74:1996

Programmatūras verifikācijas un validācijas plāna apskates pārskats + LVS 74:1996

Programmatūras konfigurāciju pārvaldības plāna apskates pārskats + + LVS 74:1996

Programmatūras kvalitātes nodrošināšanas plāna apskates pārskats + + LVS 74:1996

Datorsistēmas darbības koncepcijas apskates pārskats + + LVS 74:1996

Programmatūras prasību apskates pārskats + + + LVS 74:1996 Programmatūras projektējuma apskates pārskats + + LVS 74:1996

Testēšanas gatavības apskates pārskats + LVS 74:1996 Testēšanas rezultātu apskates pārskats + + LVS 74:1996 Programmatūras lietojamības apskates pārskats + LVS 74:1996

Programmatūras uzturamības apskates pārskats + LVS 74:1996

Kritisku prasību apskates pārskats + 6 + LVS 74:199 Šajā tabulā doti visi dokumenti, kurus rekomendē gatavot programmatūras produkta izstrādes laikā. Tā kā standartu kopas, uz kurām šajā tabulā ir dotas atsauces, atspoguļo nedaudz atšķirīgu pieeju programmatūras produkta un projekta dokumentēšanai (sk. 1. piezīmi nodalījumā 6.2.), vienos standartos paredzētā informācija var būt iekļauta citu standartu noteiktā vienā vai vairākos atšķirīga nosaukuma dokumentos. Tādēļ jāņem vērā, ka vienā projektā nekad nebūs vajadzīgi visi šīs tabulas pilnā dokumentu komplekta ailē norādītie dokumenti. Piemēram, var tikt sagatavots vai nu Programmatūras izstrādes plāns atbilstoši standartam EIA/IEEE J-STD-016, vai arī Projekta pārvaldības plāns un/vai Programmatūras konfigurācijas pārvaldības plāns, Projekta iekšējo pārbaužu plāns un Kvalitātes nodrošināšanas plāns atbilstoši 2.tabulā norādītajiem IEEE standartiem. Tādējādi, pasūtītājam un izpildītājam vienojoties par izstrādājamo dokumentāciju, vispirms ir jāizvēlas, kura no standartu grupām tiks ņemta par pamatu. Tas neliedz otras grupas standartus izmantot atsevišķu jautājumu vai dokumentu detalizēšanai. Vēlreiz īpaši jāpasvītro tas, ka neviens no šiem standartiem nebūt neprasa, lai jebkurš no 2.tabulā dotiem dokumentiem tiešām tiktu sagatavots kā atsevišķs dokuments tieši ar norādīto nosaukumu. Standarti apraksta informācijas tipu un noteikti prasa, lai

projekta sākumā tiktu dokumentāli fiksēta vienošanās, kura informācija tiks sagatavota un kādos konkrēta nosaukuma dokumentos tā tiks izvietota. 2.tabulā, tāpat kā iepriekšējā, nav dotas norādes, kurš no šiem dokumentiem tiek izstrādāts tikai projekta iekšienē un kurš tiek nodots pasūtītājam. Par šiem jautājumiem pasūtītājam un izpildītājam katra konkrēta līguma gadījumā ir īpaši jāvienojas un šī vienošanās dokumentāli jāapstiprina. Nododamo dokumentu komplekts ir cieši saistīts ar programmatūras īpatnībām, abu pušu vienošanos par programmatūras uzturēšanu, autortiesību aizsardzību, kā arī citiem jautājumiem. Atsauces 1. LR MK Noteikumi Nr. 70 (pieņemti 19.03.1996.) Noteikumi par valsts nozīmes datorizēto informācijas sistēmu statusa piešķiršanas kārtību un tehniskās realizācijas prasībām. 2. A.Ādamsone, J.Borzovs, R.Čevere, M.Lučkina. Framework for Potential Latvian Software Engineering Standards._ In: Hele-Mai Haav, Bernhard Thalheim(Eds.) Databases and Information Systems: Proc. 2nd Int. Baltic Workshop, Tallinn, 1996, pp. 105-112. 3. J.Borzovs. Informācijas tehnoloģija Latvijā: likumi un standarti._ Rakstu krājums "Latvija ceļā uz informācijas sabiedrību", Latvijas Akadēmiskā bibliotēka, 1996, lpp. 35-40. 4. I.Mētra. IT Standardization Activities in Latvia._ Baltic IT Review, No. 3, 1996, pp.48-50. 5. J.Borzovs. Information Technology in Latvia: Laws and Standards._ Baltic IT Review, No. 3, 1996, pp.44-47.

2.1. Konspekts Programminženierija Lekcijas saturs: Kas ir sistēma? SDK Prasību uzkrāšana un analīze Prototipēšana Sistēmas projektēšana un analīze Kas ir sistēma? Def. Informācijas sistēma (IS) ir cilvēku, datu, procesu un informācijas tehnoloģiju kopums, kurš sadarbojas lai reģistrētu, uzkrātu un apstrādātu informāciju, kura nepieciešama organizācijas atbalstam. Def. Informācijas tehnoloģijas (IT) ir moderns termins, kurš apraksta datoru tehnoloģijas (aparatūras un programmatūras) kombināciju ar telekomunikāciju tehnoloģijām (datu, balss u.c. tīkli). Sistēmas iedalās 7 veidos: Transakciju apstrādes sistēmas (Transaction Processing Systems) – uzkrāj un apstrādā uzņēmuma transakciju datus.

Vadības informācijas sistēmas (Management Information Systems) – nodrošina vadībai atskaites par uzņēmuma transakciju apstrādi un operācijām. Lēmumu atbalsta sistēmas (Decision Support Systems) – palīdz identificēt lēmumu pieņemšanas iespējas vai nodrošina informāciju lēmumu pieņemšanai. Izpildes informācijas sistēmas (Executive Information Systems) Ekspertu sistēmas (Expert Systems) – uzkrāj darbinieku kompetenci un pieredzi Komunikāciju un sadarbības sistēmas (Communication & Collaboration Systems) – nodrošina efektīvu komunikāciju starp darbiniekiem, sadarbības partneriem, klientiem un piegādātājiem, lai uzlabot viņu sadarbības iespējas. Biroja automatizācijas sistēmas (Office Automation Systems) – atbalsta dažāda veida biroja darbu plūsmas. Informācijas sistēmas veic šādas funkcijas : datu uzkrāšana, aktualizācija, reģistrēšana, maiņa, likvidēšana, piekļuves nodrošināšana u.c. Mūsdienu informācijas sistēmas dzinējspēki ir šādi: Uzņēmējdarbības dzinējspēki ekonomikas globalizācija - jauns augošs starptautisks tirgus: pieprasījums pēc dažādu valodu, valūtu kursu, uzņēmējdarbības kultūru atbalsta; pieprasījums starptautisku datu konsolidācijas; pieprasījums pēc mutiskas un rakstiskas komunikācijas ar vadību un lietotājiem, kuri runā dažādās valodās. elektroniskas uzņēmējdarbības un komercijas aktualitāte; drošība un privātums; sadarbība un partnerība; zināšanu vērtību pārvaldība; procesu uzlabošana un kvalitātes pārvaldība. Tehnoloģiskie dzinējspēki datortīkli un internets (perspektīvākas tehnoloģijas- xHTML un XML, skriptu valodas, tīmekļa specifiskas programmēšanas valodas, Intranets, Extranets, portāli, tīmekļa pakalpojumi (Web services); mobilas un bezvadu tehnoloģijas (PDAs, Smart phones, Bluetooth) objektu tehnoloģijas (objektu orientēta analīze un projektēšana, atkalizmantošanas iespējas, Agile izstrādes metodoloģija, objektu orientētas programmēšanas valodas C, java, Smaltalk, Visual Basic, .NET); uzņēmumu lietojumprogrammatūra (klientu apkalpošanas sistēmas, piegādes tīkla pārvaldības sistēmas, personāla vadības sistēmas, finansu sistēmas, tirgvedības un pārdošanas sistēmas, operāciju vadības sistēmas, uzņēmuma resursu plānošanas u.c.);

1. attēls. Informācijas sistēmas izstrādes fāzes un tajās iesaistītie dalībnieki. Dinamiskas vai statiskas sistēmas (objekti mainās vai nemainās laikā) Izstrādes modeļi:

2. attēls. Secīgas un iteratīvas izstrādes modeļi. SDK Ar kādām metodēm SDK var dabūt gatavu? Trīs avoti: 1. tiesiskie jeb normatīvie akti

2. intervijas (grāmatas apraksts, kā to darīt) 3. iepriekšējā pieredze Prasību analīze - tehniskā realizējamība (vai to var īstenot?) - ekonomiskā lietderība Prasības izanalizē, reizēm atgriežas pie prasību precizēšanas. Prasību uzkrāšana un analīze Prasību uzkrāšana: Tiek izstrādāta sistēmas prasību specifikācija: - Izpildāmas funkcijas (funkcionālais modelis) - lietojamie jēdzieni un to sakarības (datu modelis) - sistēmas funkcionēšana (dinamiskais modelis) prasības programmatūrai - prasības tehniskai drošībai - citas specifikas prasības Prasību analīze: Tiek izstrādātas rekomendācijas sistēmas izveidei: - sistēmas koncepcija - tehniska realizējamība un variantu analīze - ekonomiska lietderība- vai ir ekonomiski izdevīgi sistēmu taisīt - izmaksas un termini - cik maksā sistēmas izstrāde un cik ātri to var izveidot - darbu organizācija. Darbu organizācijas plāns, projekta vadība. Prototipēšana Prototipēšana - izstrādes metodoloģijas veids. Sākumā tiek izstrādāts sistēmas prototips, tas tiek parādīt sistēmas pasūtītajam, lai precizētu prasības. Papildus prasības tiek uzskaitītas un pēc to realizācijas pasūtītājam atrāda nākamo prototipu. Parasti līgumā tiek atrunāts iterāciju skaits, lai nerastos domstarpības. Prototipēšanā ļoti bieži tiek izmantoti jau eksistējošie moduļi vai koda bibliotēkas. Prototipu izstrāde notiek ātri un vienā iterācijā netiek izstrādāta visa sistēma, bet gan tās daļa. Tādējādi klients ātri ierauga topošo sistēmu un pārliecinās par tās sastāvdaļu piemērotību un nepieciešamību. Prototipēšanu izmanto gadījumos, kad (1) izstrādes komandai trūkst pieredzes līdzīga veida sistēmu izstrādē; (2) izstrādes vai sistēmas ārējā vide ir nestabila vai nenoteikta; (3) ir būtiskas problēmas lēmumu pieņemšanā. Sistēmas projektēšana un analīze Projektēšana: Tiek izstrādātas sistēmas projekts (projektējuma apraksts): - izpildāmas funkcijas (meņu) - ER modelis un datu struktūras - Sistēmas funkcionēšanas algoritms

- Lietotāju saskarsme (ekrānu formas un atskaites) - Standartprogrammatūras, datortehnikas, tīklu un citu elementu izvēle. Analīze: - Tiek akceptēts sistēmas projekts (pieprasījuma apraksts): - Standartprogrammatūras, tikli un datortehnikas - Instalācija un aprobācija - Simulēšana - reakcijas laiki, drošības situācijas Programmēšanas vides izvēle

2.2. Kā top informācijas sistēmas I Kā top informācijas sistēmas Ivars Solovjovs, DatorPasaule 12 '99 Īss ieskats informācijas sistēmu izstrādes projektu ikdienā Projekti un to vadība Droši var apgalvot, ka projekti un to vadība pastāv jau kopš civilizācijas pirmsākumiem. Vai tā būtu ēģiptiešu piramīdas celtniecība, vai romiešu kara kampaņas organizēšana, visos šajos gadījumos cilvēks ir risinājis problēmu, kā no izejas situācijas A nokļūt vēlamajā situācijā B. Gadsimtu gaitā šī pieredze ir pilnveidojusies un 20. gadsimtā kļuvusi par zinātnisku disciplīnu un vienu no vadības zinātņu stūrakmeņiem. Projekts ir uzskatāms par citu dimensiju tradicionālajam veidam, kā tiek veiktas aktivitātes kādā organizācijā. Ja ilglaicīgi un vienveidīgi tipveida darbi tiek pildīti statisku, funkcionālu struktūrvienību ietvaros, tad vienreizēja netipiska uzdevuma izpilde tiek organizēta un vadīta kā projekts, tā izpildei uz laiku apvienojot dažādu struktūrvienību resursus vienotā projekta grupā, lai sasniegtu konkrētus projekta mērķus. Jauna veida produkcijas ražošanas uzsākšanu, uzņēmuma struktūras izmaiņu vai jaunas datorsistēmas ieviešanu uzskata par tipiskām aktivitātēm, kuras ir organizējamas kā projekti. IT projekti un programminženierija Jaunas informācijas sistēmas (IS) izveide organizācijā bieži vien ir saistīta ar kardinālām izmaiņām pašā organizācijā un tās biznesa procesos, tāpēc sekmīga IS izveide nav iespējama bez projektu vadības metožu izmantošanas, kuras, bagātinātas ar specifisko IT projektu pieredzi, radīja jaunu disciplīnu, kas kopš 70. gadu sākuma ir pazīstama kā programminženierija (software engineering). Par spīti zinātnieku un praktiķu pūliņiem, kā arī uzkrātai pieredzei šajā jomā, "sudraba lode" līdz šim tā arī vēl nav atrasta un centieni pilnveidot IS un programmatūras izstrādes metodes joprojām turpinās. Taču ir izkristalizējušies virkne principu un paņēmienu, bez kuriem sekmīga IS izstrādes projektu realizācija nav iespējama. Amatnieciskā un rūpnieciskā IS izstrāde Datoru un citu informācijas tehnoloģiju pieejamība, kā arī bieži kultivētais mīts par programmēšanu kā mākslu rada ilūziju, ka IS izstrāde ir vienkārša un īpašus vadīšanas pūliņus neprasa, jo ir pašregulējoša aktivitāte. IS izveide atbilstoši šim priekšstatam līdzinātos, teiksim, tam, kā tiek remontēts dzīvoklis, kad palīdz krāsotājs Pēteris, kurš, kā jau kārtīgs amatnieks, no 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, kā vajag, viņš pārkrāsos, jo gan jau jūs kaut kā vienosities. Ļaunākajā gadījumā, ja bieži rodas vēlēšanās mainīt krāsu, var pieņemt viņu pie sevis darbā, lai būtu visu laiku pie rokas. Šo piemēru var uzskatīt par tipiski amatniecisku pieeju, kura šajā situācijā ir absolūti dabiska un ekonomiski gandrīz vai vienīgi iespējamā. Pavisam cita situācija ir, ja mēs apskatām, piemēram, debesskrāpja vai tilta būvniecību, kur bez izsmeļoša ekonomiskā pamatojuma, precīza projekta, tāmes, apakšuzņēmēju iesaistīšanas un citu it kā birokrātisku procedūru ievērošanas sekmīgs rezultāts vienkārši nav iespējams. Šāda mēroga un nozīmes objektu būvniecībā tiek izmantotas industriālas metodes, kuras būtiski atšķiras no amatnieciskajām. Tieši tāpat ir ar informācijas sistēmu izstrādi, jo var izmantot abas pieejas – gan amatniecisko (ja ir runa par vienkāršu programmiņu, ar kuru tiktu galā viens cilvēks divās nedēļās), gan arī rūpnieciskās (industriālās) IS izstrādes metodes (ja tiek izstrādāta valstiskas nozīmes vai uzņēmuma kritisku funkciju nodrošinoša sistēma, kurā tiek iesaistīti 10 un vairāk cilvēku). Runājot līdzībās, jāsaka, ka galvenais ir nemēģināt būvēt debesskrāpi, paļaujoties tikai uz amatnieku zelta rokām. Kāpēc IS izstrādē ir nepieciešami standarti Kā jau tika minēts, IS izstrādes projekti ļoti bieži ir lieli, un tādos nevar iztikt bez lielāku uzdevumu sadalīšanas sīkākos, to veikšanu uzticot daudziem izpildītājiem un pēc tam integrējot atsevišķi iegūtos rezultātus. Nav iespējams šos projektus īstenot arī bez koordinācijas nodrošināšanas starp atsevišķiem apakšprojektiem, plānu izpildes gaitas uzraudzības un plānu precizēšanas, bez dažādu ražotāju IT produktu izmantošanas utt. Normāla sadarbība starp projektā iesaistītajiem dalībniekiem nevar notikt, ja tie nebalstās uz vienotiem metodoloģiskiem un tehnoloģiskiem principiem. Šo iemeslu dēļ, kā jau jebkurā industrializētā nozarē, standartu ievērošana kļūst par priekšnosacījumu, kaut arī ne garantiju veiksmīgam rezultātam. Kā galvenos IS izstrādes procesu reglamentējošos standartus var minēt šādus: • ISO 9000 grupas standarti, kas nosaka vispārējos organizācijas darbības principus un sakārtotību (ieskaitot arī ISO 9000-3 standartu, kurš reglamentē ISO 9000 standartu lietošanu programmatūras izstrādē); • Standartu kopa, ko veido gan ISO, gan IEEE standarti, kas reglamentē informācijas sistēmas dzīves ciklu, projekta procesus un to savstarpējo saistību, starpproduktu nomenklatūru, saturu un formu (programminženierijas standarti); Katrai organizācijai jāpiemēro standarti konkrētām vajadzībām, kuru ietvaros atbilstoši standartu nostādnēm ir jādefinē konkrētos apstākļos nepieciešamie procesi, aktivitātes, attiecīgo dokumentu konkrēts saturs un forma, kā arī vadlīnijas standartu izmantošanai organizācijā. Ar ko sākas IS izstrādes projekts IT izmantošana organizācijā un IS izstrāde nav pašmērķis, bet tikai līdzeklis (instruments) konkrētu biznesa mērķu sasniegšanai, tāpēc IS izstrāde ir uzskatāma par uzņēmuma (vai organizācijas) darbības uzlabošanas procesa sastāvdaļu. Pirms IS izveides sākuma, uzņēmumam ir jātiek skaidrībā, kādi ir organizācijas biznesa mērķi, kas un kā ir jāpārveido uzņēmumā, lai tos sasniegtu, kādas ir tās funkcijas, kuru atbalstam nepieciešams izmantot IT, kāda ir IS izveides un darbināšanas stratēģija (IS izveide pašu spēkiem vai produktu un pakalpojumu iepirkšana no ārpuses). Parasti šie jautājumi tiek atspoguļoti stratēģiskas dabas dokumentā (tā nosaukums varētu būt, piemēram, "Informācijas sistēmas stratēģiskais plāns"), kas tiek akceptēts visaugstākajā vadības līmenī. Šīs stratēģiskās plānošanas

aktivitātes attiecas ne tik daudz uz IS izstrādi, bet gan uz organizācijas biznesa procesa sakārtošanu, tāpēc konkrētu standartu, kas reglamentētu šo procesu, nav. IS izstrādes dzīves cikls Tāpat kā dzīva būtne, arī IS netop vienā mirklī, un tai ir savs dzīves cikls, kas tiek aprakstīts ar dzīves cikla modeli. Jau kopš 70. gadu sākuma par klasiskām sistēmas izstrādes dzīves cikla (system development life cycle –SDLC) sastāvdaļām tiek uzskatītas šādas fāzes (sk.1. zīm.):

• Prasības (sistēmu analīze, prasību specificēšana) – tiek apzinātas, izanalizētas un dokumentētas prasības (visdažādākās: sākot ar funkcionālajām un beidzot ar tehniskajām), kurām izstrādājamai IS ir jāatbilst; • Projektēšana – atbilstoši prasībām tiek projektēta sistēmas iekšējā uzbūve; • Kodēšana un vienību testēšana – atbilstoši projektētajam tiek izstrādāta (kodēta) programmatūra un veikta atsevišķu sistēmas sastāvdaļu (moduļu) autonoma testēšana; • Sistēmas integrācija – atsevišķās sistēmas daļas un komponenti tiek apvienoti vienā strādājošā sistēmā, kas pēc attiecīgas pārbaudes tiek palaista ražošanā; • Darbināšana un uzturēšana – regulārs darbs ar sistēmu, kā arī sistēmas modificēšana atbilstoši prasībām, kas parādās jau tās darbināšanas laikā; Tas ir tā saucamais vienkāršais (once-trough) ūdenskrituma modelis (waterfall), kas paredz lineāru atsevišķu fāžu secību. Katrā fāzē ir definēti konkrēti mērķi un aktivitātes, kā arī rezultāti, kurus izmanto nākamajā fāzē. Lai gan pastāv variācijas attiecībā uz fāžu nosaukumiem, kā arī atsevišķas fāzes dažkārt tiek dalītas vēl sīkāk, konkrētais modelis ir uzskatāms par klasisku. Pamatprincipi, uz kuriem balstās ūdenskrituma modelis, ir šādi: • Pirms projekta uzsākšanas, tas ir rūpīgi jāizplāno; • Jādefinē sistēmas ārējā uzvedība (atribūti), pirms uzsāk sistēmas iekšējās uzbūves konstruēšanu; • Jādokumentē katras aktivitātes rezultāti; • Pirms sistēmas kodēšanas (programmēšanas) tā ir jāprojektē; • Pēc sistēmas uzbūvēšanas tā ir jātestē. IS izstrādes dzīves cikla modeļa paveidi Ūdenskrituma modeļa (klasiskajā variantā) galvenais trūkums – pirms sistēmas izstrādes uzsākšanas ir jābūt precīzi definētām izstrādājamās sistēmas prasībām. Ņemot vērā to, ka sistēmas mēdz būt lielas un sarežģītas, kā arī risku, kas ir saistīts ar nepilnīgi definētām prasībām, praksē bieži vien tiek piemēroti no konkrētā modeļa atvasināti varianti. 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.).

Izstrādes scenārijs, atbilstoši kuram pēc pirmā būvējuma uz tā darbināšanas pieredzes pamata tiek papildinātas (precizētas) sistēmas prasības, ir evolucionārais modelis (sk. 3. zīm.).

Ņemot vērā moderno programmatūras rīku iespējas, dažkārt ir lietderīgi pirms izstrādes sākuma uzbūvēt sistēmas vienkāršotu prototipu, uz kura pamata tiek definētas izstrādājamās sistēmas prasības. Tas ir prototipēšanas modelis (sk. 4. zīm.). IS izstrādes dzīves cikla modeļu galveno iezīmju salīdzinājums.

Izstrādes stratēģija (modelis) Vai vispirms definē visas prasības?

Vai ir vairāki izstrādes cikli?

Vai tiek izplatīti (darbināti) starpbūvējumi?

Vienkāršā (once- trough) Jā Nē Nē Inkrementālā Jā Jā Iespējams Evolucionārā Nē Jā Jā Bez minētajiem vēl ir pazīstams spirāles modelis, kas attēlo sistēmas izstrādes procesu kā iteratīvu ciklu (spirāli), kurš sastāv no mērķa uzstādīšanas, risinājuma izvēles un alternatīvu analīzes, izstrādes, rezultātu salīdzināšanas ar sākotnējo uzdevumu, kā arī jauna mērķa uzstādīšanas utt. Lai gan visi šie modeļi savā būtībā nav pretrunīgi un viens otru papildina, tomēr viens no galvenajiem projekta lēmumiem ir izvēlēties konkrētai situācijai piemērotāko izstrādes stratēģiju. Noteikti būtu jāņem vērā tādi faktori kā problēmas sarežģītība, cik viegli ir definējamas prasības, prasību izmaiņu varbūtība, cik ātri nepieciešama pirmā (daļēja) sistēmas funkcionalitāte, finansu iespējas, izstrādei nepieciešamie cilvēkresursu ierobežojumi un citi faktori. Mazai sistēmai, kuras visu funkcionalitāti ir iespējams izstrādāt vienā paņēmienā (vai arī nav jēdzīga/iespējama daļas funkciju realizācija), visdrīzāk derēs vienkāršais vai prototipa modelis (ja puses atrod par ērtāku prasības definēt uz "fiziski aptaustāma" prototipa pamata). Savukārt lielas sistēmas, kā likums, tiek realizētas vairākās iterācijās (resursu ierobežojumu dēļ, kā arī lai mazinātu risku un papildu izdevumus, kas saistīti ar pārlieku liela projekta vadīšanu). Vissaprātīgākais šādā gadījumā ir katrā nākamajā iterācijā koriģēt/papildināt prasības atbilstoši iepriekšējās iterācijas rezultātiem (evolucionārais modelis). Taču bieži tiek piemērots arī inkrementālais scenārijs, kad prasības tiek iesaldētas jau izstrādes sākumā un pēc tam vairākās kārtās realizētas (ja prasības ir pietiekami stabilas un detalizētas un ir nepieciešama/iespējama daļas funkciju ātrāka realizācija, kā arī izstrāde tiek organizēta kā atsevišķs fiksētas cenas kontrakts uz detalizēta prasību specifikācijas dokumenta pamata).

3.1. Konspekts Sistēmas modelēšana

Izmantotie materiāli: Roger S. Pressman, Chapter 10. Sistēmas inženierija. lpp.235-248 Plāns: • Sistēmas modelēšana • Uzņēmuma modelēšana • Biznesa līmeņa datu modelēšana • Procesu modelēšana • Informācijas plūsmas modelēšana • Sistēmas arhitektūras modelēšana Sistēmas modelēšana Sistēmu izstrāde ir modelēšanas process. Neatkarīgi no tā, vai uzmanība tiek pievērsta pasaules redzējumam, vai detalizētākam redzējuma, inženieris izstrādā modeli, kurš: definē procesus, kuri apmierina šī redzējuma vajadzības; reprezentē procesu uzvedību un pieņēmumus, uz kuriem balstās procesu uzvedība; skaidri definē modeļa ieejas informāciju - eksogēno un endogēno ievadu; reprezentē visus savienojumus, ieskaitot izvadus, kuri nodrošinās inženiera labāko problēmas sfēras redzējumu. Lai uzbūvētu sistēmas modeli, inženierim ir jāņem vērā vairāki svarīgi faktori: 1. Pieņēmumi, kuri samazina iespējamo permutāciju un variāciju skaitu, tādā veidā nodrošinot modeļa iespēju adekvāti reaģēt uz problēmu. 2. Vienkāršošana nodrošina modeļa ātrāku izstrādi. 3. Ierobežojumi, kuri palīdz identificēt būvējamās sistēmas robežas. 4. Tehnoloģiskie ierobežojumi, kuri nosaka vadlīnijas būvējamās sistēmas modeļa realizācijai un implementēšanai. 5. Preferences, kuras nosaka vēlamo arhitektūras īpašības gan datiem, gan funkcijām, gan tehnoloģijām. Uzņēmuma modelēšana Veicot uzņēmuma modelēšanu, inženieri izstrādā trīsdimensiju skatījumu uz uzņēmuma biznesu. Pirmā dimensija pārvalda organizācijas struktūru un funkcijas, kuras tiek veiktas dotajās organizācijas struktūrās. Otrā dimensija palīdz atdalīt biznesa funkcijas no tām, kuras palīdz biznesa funkcijām eksistēt un realizēties. Visbeidzot trešā dimensija organizācijai un tās funkcijām pievieno mērķus un kritiskus veiksmes faktorus. Papildus tam, uzņēmuma modelēšanas procesā tiek izveidots biznesa līmeņa datu modelis, kurš definē datu objektus un to saistību ar citiem elementiem uzņēmuma modelī. Biznesa organizācija parasti tiek definēta kā klasiska biznesa vienību hierarhija (skat. Attēlu 1). Katra diagrammas aile raksturo organizācijas biznesa darbības sfēru. Protams, šo hierarhisko attēlu var detalizēt līdz pat mazām izstrādes komandām vai pat atsevišķiem darbiniekiem, taču modelēšanas mērķiem tas nav vajadzīgs. Tālāk tiek identificētas biznesa funkcijas un atbilstošie procesi, nepieciešami šo biznesa funkciju realizācijai. Biznesa funkciju definē kā biznesa sfēras nepieciešamo notiekošu aktivitāti. Biznesa funkciju parasti raksturo lietvārds. Biznesa procesam, savukārt, ir ieejas informācija, kuru pārveidojot tiek iegūta izejas informācija. Biznesa procesu parasti raksturo darbības vārds.

Attēls 1. Organizācijas hierarhiskā struktūra un to funkcijas. Biznesa līmeņa datu modelēšana Biznesa līmeņa datu modelēšana ir uzņēmuma modelēšana aktivitāte, kurā galvenā uzmanība tiek pievērsta datu objektiem (tā saucamajām entītēm), kuri ir nepieciešami biznesa funkcijas mērķu sasniegšanai. Biznesa līmenī tipiskie datu objekti iekļauj informācijas sniedzējus un informācijas patērētājus (piemēram, klients), lietas (piemēram, pārskati, atskaites), notikumus (piemēram, konference), organizācijas lomas (piemēram, vice-prezidents), organizācijas vienības (piemēram, pārdošanas un mārketinga departaments), vietas (piemēram, rūpnīca) vai informācijas struktūras (piemēram, darbinieku datne). Datu objektam ir virkne atribūtu, kuri raksturo tā kvalitāti, raksturojumu vai datus, kurus objekts satur. Piemēram, aplūkosim datu objekta piemēru - Klients. Lai detalizēti aprakstītu klientu, izmantosim šādus atribūtus: ______________________ Objekts: Klients Atribūti: Vārds Organizācijas nosaukums Amats Interesējošie produkti Pirkumu/pasūtījumu vēsture Pēdējā kontakta datums Kontakta statuss Kad ir skaidri datu objekti, tiek identificētas to savstarpējas attiecības. Attiecības identificē veidu, kā objekti sadarbojas viens ar otru. Piemēram, ir identificēti objekti Klients, Produkts A un Pārdevējs. Inženieris veido diagrammu, lai attēlotu šo objektu savstarpējas attiecības. Parasti attiecības var būt lasītas gan no viena objekta puses,

gan no otra objekta puses. Piemēram, Klients kontaktējas ar Pārdevēju, vai Pārdevējs palīdz Klientam.

Attēls 2. Biznesa līmeņa datu objektu attiecības Un visbeidzot ir svarīgi sastādīt griezskaņa (cross-relation) matricu, kurā tiktu uzskaitītas visas savastarpējas attiecības starp organizāciju un tās biznesa sfērām, biznesa mērķiem, biznesa funkcijām un procesiem, kā arī datu objektiem. Procesu modelēšana Darbs, kurš tiek veikts kādā organizācijā satur virkni biznesa funkciju, kurus noformē kā biznesprocesus. Izskatīsim procesu modelēšanu uz pārdošanas funkcijas piemēra. Pārdošana satur vairākus procesus: - Nodibināt kontaktu ar klientu; - Nodrošināt literatūru un citu informāciju par produktu; - Atbildēt uz interesējošiem jautājumiem; - Nodrošināt produktu; - Pieņemt pircēja pasūtījumu; - Pārbaudīt pasūtījuma pieejamību; - Sagatavot piegādi; - Saskaņot ar pasūtītāju pasūtījuma konfigurāciju, apmaksas un piegādes veidu; - Pārsūtīt pasūtījumu par izpildi atbildīgajam departamentam; - Turpināt sarunu ar klientu. Š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. Datu plūsmas modelēšana Datu plūsmas modelis tiek integrēts ar Procesu plūsmas modeli, lai attēlotu kādā veidā informācija ceļo līdz biznesprocesiem. Katram procesam tiek attēlota ieejas un izejas informācija, attēlojot informācijas pārveidošanas plūsmu kamēr tiek izpildīta kāda biznesa funkcija. Datu plūsmas piemēru skat. Attēlā 4.

Attēls 4. Datu plūsmas pievienošana procesa plūsmas modelim. Kad procesa un datu plūsmas modeļi ir izstrādāti, inženieris, sekojot biznesa procesu izpildei, mēģina identificēt iespēju optimizēt kādu posmu, ieejas un izejas informāciju, piemeklējot piemērotāko tehnoloģisko vai organizatorisko risinājumu. Uz šo modeļu bāzes vēlāk tek izstrādāta būvējamās sistēmas prasību specifikācija. Sistēmas arhitektūras modelēšana Katra sistēmas var būt modelēta kā informācijas pārveidošanas arhitektūra: "ievads-apstrāde-izvads". Sistēmas modeļa izstrādē tiek izmantota arhitektūras sagatave. 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) sistēmas uzturēšana un paštesti. Arhitektūras sagataves forma ir redzama attēlā 5.

Attēls 5. Arhitektūras sagataves forma. Tāpat kā pārējās modelēšanas tehnikas, arhitektūras sagataves ļauj analītiķim pielietot detalizācijas hierarhiju. Arhitektūras konteksta diagrammas (ACD) atrodas hierarhijā pašā augšā. Konteksta diagramma nosprauž robežas starp sistēmu un sistēmas ekspluatācijas vidi. Proti, arhitektūras konteksta diagramma definē visus sistēmas ārējos informācijas piegādātājus un izmantotājus, kā arī visas entītes, kuras sadarbojas ar ārējiem datu failiem, izmantojot interfeisus. Piemērā ir attēlota konveijera līnijas sortēšanas sistēma (skat. attēlu 6).

Attēlos 6. Konveijera līnijas sortēšanas sistēmas arhitektūras konteksta diagramma.. Vēlāk inženieris detalizē arhitektūras konteksta diagrammu, identificējot zem katras kantainas ailes apakšsistēmas, kuras nodrošina sistēmas funkcionēšanu. Apakšsistēmas var attēlot arhitektūras plūsmas diagrammā (AFD), kurš balstās uz arhitektūras konteksta diagrammu (skat. attēlu 7).

Attēls 7. Arhitektūras plūsmas diagramma (AFD). Pirmā arhitektūras plūsmas diagramma kļūst par augšējo virsotni kokā, kura lapas ir kantainas ailes, kuras, ejot arvien dziļāk, iegūst arvien lielāku detalizācijas pakāpi. Šis process ir redzams attēlā 8.

Attēls 8. Arhitektūras plūsmas diagrammas hierarhija

3.2. Datu plūsmu diagrammas piemērs Datu plūsmu diagrammas piemērs Izmantots kursa projekts: "Personāla darba uzdevumu uzskaites sistēma" R. Zviedris; M. Vārpa.

4.1. Konspekts ER - diagrammas

Apzīmējumi Entītija - klase, vienveidīgu objektu kopums. Datubāzē tas pārvērtīsies par vienu tabulu. Nosaukumā lieto lietvārdu. Piemēri. Personas: klients, darbinieks, students, pasniedzējs. Vietas: universitāte, auditorija, viesnīca, restorāns. Objekti: grāmata, mašīna, produkts, programmatūras licence, programmatūras rīks. Notikumi: apbalvošana, pieņemšana darbā, atlaišana no darba, ceļojums. Entītijas instance ir viena entītijas parādīšanās, piemēram, entītijas Students instance var būt Austris Ozoliņš.

Arthur Andersenvadība

Darbinieks SekretārePersonālavadītājs

Personālās informācijas redaktors

Klients

Atrašanās vietas redaktors

Elektroniskoziņu

redaktors

Darbiniekae-pastkaste

Dati par izmaiņāmkompānijās, grupāsun klasifikācijās

Dati pardarbinieku

Dati parprombūtni

Dati parprombūtni

Dati parprombūtni

Dati pardarbinieku

Dati pardarbinieku

Dati par"meklētāju"

Dati parmeklējamopersonu

Grupas

Kompānijas

Klasifikācijas

Dati parizmaiņāmkompānijās

Dati parizmaiņāmgrupās

Datipar

izmaiņāmklasfi-kācijās

Dati parkompānijām

Dati pargrupām

Dati parklasifi-kācijām

Jaunsieraksts

Personālāinformācija

Atrašanās vietasinformācija

Jaunsieraksts

Jaunsieraksts

Personālāsinformācijas

apskats

Atrašanās vietu informācijas

apskats

Klasificētainformācija

Klasificētainformācija

Personālavadītājs

Sekretāre KlientsGrāmatvedība

Informācija par darbieniekuInformācija par darbinieka atrašanās vietu

1. attēls. Entītija Students un tās instances tabulārajā reprezentācijā. Atribūts ir entītijas raksturojošs elements vai aprakstoša īpašība. Atribūta sinonīmi - elements, īpašība un lauks. Piemēram, Studentam var būt vārds, uzvārds, matu krāsa, svars u.tml. Saliktais atribūts ir tāds atribūts, kurš satur citus atribūtus. Atribūts, kurš atšķir kopas elementus ir galvenā atslēga (primary key), piemēram, studentus atšķir Studenta apliecības numurs, kurš visiem studentiem ir unikāls. Tā vietā varētu lietot arī Personas kodu, bet studentiem no dažādām valstīm tie būs dažāda garuma un izskata. Kandidātatslēga ir viena no vairākām atslēgām, kuras var kalpot kā galvenā atslēga (ir unikāla katrai entītijas instancei). Alternatīva atslēga ir kandidātatslēga, kura netiek izvēlēta kā galvenā atslēga. Sinonīms - sekundārā atslēga. Asociatīva entītija ir entītija, kura manto savu galveno atslēgu no vairāk nekā vienas citas entītijas (kurus sauc par vecākiem (parents)). Datu tips ir atribūta īpašība, kura identificē to datu tipu, kurus saturēs atribūts. Attiecība (relācija) - dabiska asociācija starp dažādām entītijām. Attiecība var reprezentēt notikumu vai citu atbilstību, kura sasaista entītijas. Piemēram, Studenta un Mācību programmas attiecība - students mācās pēc mācību programmas, savukārt mācību programmai reģistrē vienu vai vairākus studentus.

2. attēls. Attiecības piemērs. Attiecības mēdz būt dažāda veida, atkarībā no sasaistīto entītiju skaita. Modalitāte - minimālais instanču parādīšanās skaits, kardinalitāte - maksimālais instanču parādīšanās skaits. Nosaukums Modalitāte Kardinalitāte Grafiskā attēlošana

Tieši viens 1 1

Nulle vai viens 0 1

Viens vai vairāk 1 n (>1)

Nulle, viens vai vairāk 0 n (>1)

Vairāk par vienu n n ER modeļu realizācija ar tabulām Tabulu kolonas atbilst atribūtiem. Rindiņu skaits nav ierobežots. Mācību priekšmets Kods Nosaukums ... Y1 Programmēšana Y2 Diskrētā matemātika Y3 Projektu vadība ... ... Mācību priekšmeta galvenā atslēga ir Kods. Pasniedzējs Personas kods Vārds Uzvārds ... PK1- Juris Borzovs PK2- Jānis Bičevskis PK3- Guntis Arnicāns ... Pasniedzēja galvenā atslēga ir Personas kods. Students Personas kods Vārds Uzvārds Studiju programma ... PK1- Juris Bērziņš Datorzinātņu bakalaurs PK2- Aivis Ozoliņš Programmētājs PK3- Ieva Liepiņa Datorzinātņu bakalaurs ... Studenta galvenā atslēga ir personas kods. Priekšmets - Students Priekšmets Students Reģistrēšanas datums ... Y1 PK1 7.IX.03 Y2 PK2 2.II.04 Y3 PK3 5.IX.03 ...

Priekšmeta-Studenta tabulā tiek lietotas 2 ārējās atslēgas (foreign key) - mācību priekšmeta kods un studenta personas kods. Priekšmets - Pasniedzējs Priekšmets Pasniedzējs Semestris Kvalitāte ... Y1 PK1 II ļoti laba Y2 PK2 III ļoti laba Y3 PK3 III ļoti laba ... Ja IS pašos pamatos ieliek neveiksmīgu datu modeli, var sanākt pārtaisīt visu no sākuma. Konceptuālajā modelī var būt m:n attiecības. Realizācijas modelē vairs m:n nav, tur vēl ir arī kodējumi.

3. attēls. Piemērs. Datu modelēšanas fāzes. 1. Konceptuālais datu modelis - lai noteiktu projekta sfēru 2. Uz atslēgām balstītais datu modelis - likvidē nespecifiskas attiecības - pievieno asociatīvas entītijas - iekļauj galvenās un alternatīvas atslēgas - precizē kardinalitātes 3. Pilnīgi izskaidrojams datu modelis - iekļauti visi atlikušie atribūti - apakškopu veidošanas kritēriju izvēle 4. Normalizēts modelis

4.2. ER modeļa piemērs I ER modeļa piemērs Izmantots kursa projekts: "Datu mobilā uzskaite" A. Maruškins; D. Seluto.

Mediciniskie instrumenti

Starpgadijumi

Pacienti

Medikamenti

Atras mediciniskaspalidzibas izsauksanas

apmaksasanas tarifs

Pilseta

Iela

Pasta indekss

Atras mediciniskas palidzibasautomasinu apkalpošanas

bazes

Darba laika aprakstisana

Atras mediciniskas palidzibaspersonals

Atras mediciniskas palidzibasbazes

Apdrosinasanaskompanijas

Atras mediciniskas palidzibasarsta pizimes

Nevrologiskassaslimsanas

Izsauktais arsts

Atras mediciniskas palidzibasmasinas

Pacienta arstejosais arsts

EKG defekti

Pacienta parvesana

Hroniskas saslimsanas

Kardiologiskassaslimsanas

Pulmonologiskassaslimsanas

Travmotologiskassaslimsanas

Manipulacijas

4.3. ER modeļa piemērs II ER modeļa piemērs Izmantots kursa projekts: "Personāla darba uzdevumu uzskaites sistēma" R. Zviedris; M. Vārpa.

4.4. Entītes un atribūti Entītes un atribūti. Piemērs. Izmantots kursa projekts: "Datu mobilā uzskaite" A. Maruškins; D. Seluto. Ātrās medicīniskās palīdzībās automašīnu bāzes 1) IDN 2) Ātrās medicīniskās palīdzības automašīnu bāzes identifikācijas numurs Ātrās medicīniskās palīdzības bāzes 1) IDN 2) Ātrās medicīniskās palīdzības bāzes identifikācijas

numurs 3) Ātrās medicīniskās palīdzības bāzes nodaļas identifikācijas numurs Ātrās medicīniskās palīdzības mašīnas 1) IDN 2) Ātrās medicīniskās palīdzības bāzes IDN 3) Mašīnās valsts numurs 4) Mašīnās kilometrāže Ātrās medicīniskās palīdzības personāls 1) IDN 2) Ātrās medicīniskās palīdzības ārsta identifikācijas numurs 3) Ātrās medicīniskās palīdzības medmāsas identifikācijas numurs 4) Ātrās medicīniskās palīdzības vādītāja identifikācijas numurs 5) Ātrās medicīniskās palīdzības bāzes IDN Darba laika aprakstīšāna 1) IDN 2) Ātrās medicīniskās palīdzības pesonāla IDN 3) Ātrās medicīniskās palīdzības bāzes IDN 4) Ātrās medicīniskās palīdzības mašīnas IDN 5) Darba sakuma

laiks 6) Darba beigas laiks 7) Mašīnas kilometrāzē darba dienas sakumā un beigā Pilsēta 1) IDN 2) Nosaukums Iela 1) IDN 2) Nosaukums Pasta indekss 1) IDN 2) Indekss Apdrošināšanas kompānijas 1) IDN 2) Nosaukums 3) Identifikācijas numurs 4) Pilsēta IDN 5) Iela IDN 6) Pasta indeks IDN 7) Adresa precizēšana Ātrās medicīniskās palīdzībās izsaukšanās apmaksāšanās tarifs 1) IDN 2) Izsauktais ārsts IDN 3) Tarifa veids Pacienta ārstējošais ārsts 1) IDN 2) Vārds, uzvārds 3) Identifikācijas numurs Izsauktāis ārsts 1) IDN 2) Ārsta tips 3) Ārsta veids

Pacienti 1) IDN 2) Vārds 3) Uzvārds 4) Dzimšanas datums 5) Vecums 6) Pilsēta IDN 7) Iela IDN 8) Pasta indeks IDN 9) Adresa precizēšana 10) Dzimums 11) Apdrošināšanas kompānijas IDN 12) Apdrošināšanas aģenta (Aa) vārds 13) Aa uzvārds 14) Aa dzimšanas data 15) Aa pilsēta IDN 16) Aa iela IDN 17) Aa pasta indekss IDN 18) Aa adresa precizēšana 19) Darba devēja (Dd) pilsēta IDN 20) Dd iela IDN 21) Dd pasta indekss IDN 22) Dd adresa precizēšana 23) Darba dienas identifikācijas numurs 24) Ātrās medicīniskās palīdzības mašīnas izsaukšanas laiks un datums 25) Ātrās medicīniskās palīdzības mašīnas izbraukšanas laiks un datums 26) Ātrās medicīniskās palīdzības mašīnas atbraukšanas laiks un datums 27) Ātrās medicīniskās palīdzības mašīnas aizbraukšanas laiks un datums

28) Ātrās medicīniskās palīdzības mašīnas tiekoša kilometrāža vertība 29) Darba laika aprakstīšanas IDN 30) Pirma starpposmu pieturas (Psp) pilsētas IDN 31) Psp ielas IDN 32) Psp pasta indeksa IDN 33) Psp adresa precizēšana 34) Otra starpposmu pietura (Osp) pilsētas IDN 35) Osp ielas IDN 36) Osp pasta indeksa IDN 37) Osp adresa precizēšana 38) Treša starpposmu pietura (Tsp) pilsētas IDN 39) Tsp ielas IDN 40) Tsp pasta indeksa IDN 41) Tsp adresa precizēšana 42) Ātrās medicīniskās palīdzības izsaukšanās apmaksāšanās tatrifs IDN Medikamenti 1) IDN 2) Grupa 3) Nosaukums 4) Ievada veids 5) Laiks 6) Pacients IDN Mediciniskie instrumenti 1) IDN 2) Grupa 3) Nosaukums 4) Ievada veids 5) Laiks

6) Pacients IDN Manipulācijas 1) IDN 2) Veids 3) Rezultāts 4) Rezultātu grafiks 5) Pacients IDN Starpgadijumi 1) IDN 2) Nosaukums 3) Laiks 4) Izpausmju veids 5) Pacients IDN Pacienta parvēšana 1) IDN 2) Apmaksāšanas veids 3) Steidzums 4) Reanimācijas veids 5) Pīrma medicīniska palidzība 6) Parvēšanas veids 7) Pacienta stavoklis arvēšanas laikā 8) Pacients IDN EKG defekti 1) IDN 2) Nosaukumi 3) Pacients IDN Hroniskās saslimšanas 1) IDN 2) Grupa 3) Nosaukums 4) Pacients IDN Kardioloģiskās saslimšanas 1) IDN 2) Nosaukums 3) Pacients IDN Pulmonoloģiskās saslimšanas

1) IDN 2) Nosaukums 3) Pacients IDN Travmotoloģiskās saslimšanas 1) IDN 2) Nosaukums 3) Sarežgetība 4) Izvietojums 5) Pacients IDN Nevroloģiskas saslimšanas 1) IDN 2) Grupa 3) Nosaukums 4) Pacients IDN

5.1. Konspekts Modelēšanas rīki Valdis Vītoliņš, e-pasaule 9 '2003 Ir grūti iedomāties biznesa jomu, kurā varētu kaut ko paveikt bez iepriekšējas plānošanas un analīzes. Tāpēc tiek izstrādāti dažādi modelēšanas rīki, kas atvieglo dažādu biznesa jomu modelēšanu. Var pieņemt, ka rīks atbalsta biznesa modelēšanu, ja: iespējams grafiskā veidā attēlot, kāds ir uzņēmums un kādas darbības tiek veiktas; dažādos veidos var attēlot arī uzņēmuma resursus, darbības kvalitāti, apkārtni, un jau ir metodika un/vai šabloni šo aspektu modelēšanai; uzņēmuma darbību var virtuāli simulēt un pat attēlot kā animāciju (vēlams). Šāda veida rīki veido nosacītu spektru no biznesa modelēšanas līdz programmatūras izstrādei. Biznesa modelēšanas rīkos lielāka uzmanība tiek pievērsta dažādu biznesa aspektu attēlošanai, metodikai, procesu simulācijai, kā arī vairāki rīki piedāvā savu metodiku biznesa analīzē. Metodikas atbilst Deminga/ISO vai Balanced Scorecard kvalitātes pārvaldības procesam, Portera Value Added Chain vai ir pilnīgi atšķirīgas kā Zahmana metodika (Zachman framework) un ARIS metodiku kompilācija. Diemžēl šīs metodikas ir zināmā mērā novecojušas, jo slikti atbilst mūsdienās izplatītajai biznesa transakciju pieejai (B2B un Web servisu izstrādē) un objektorientēto/sadalīto sistēmu izstrādei. Programmatūras izstrādes rīki atbalsta modelēšanas valodu Unified Modeling Language 2.0 (UML) (izņemot Timing diagrammu), kā arī veic programmatūras koda ģenerēšanu, reinženieriju (koda analīzi) un/vai koda sinhronizēšanu ar modeli. Tā kā programmatūras kodu klasiski ģenerē tikai no klašu diagrammām, citas diagrammas biznesa modelēšanā kalpo tikai aprakstam.

Pirms izmantot kādu rīku, jāizlemj, vai tas tiks lietots tikai biznesa cilvēku vajadzībām (uzņēmuma modelēšanai, darbības, kvalitātes, izmaksu un citu aspektu analīzei) vai arī "tehnisko" darbinieku vajadzībām - programmu izstrādei un ieviešanai. Microsoft Visio Professional 2002, Visual Studio .NET Enterprise Architect Visio ir rīks, kura spēcīgās grafiskās iespējas, pēc Microsoft pārņemšanas, ir papildinātas ar programmatūras izstrādes un modelēšanas iespējām. Šajā rīkā vairāk ir attīstītas programmatūras izstrādes iespējas. Biznesa modelēšanai to var izmantot, lietojot tā UML redaktora iespējas. Rīks ļauj veidot visas praksē izmantotās UML diagrammas, no kurām biznesa modelēšanā vērtīgākās ir klašu un aktivitāšu diagrammas. Visual Studio .NET Enterprise Architect ir tikai plašākas programmatūras koda pārvaldības iespējas.

1. attēls. Microsoft Visio Professional 2002 Popkin Software System Architect 8.8 Tas ir "spilgts" biznesa modelēšanas rīks, kas piedāvā īpašu Zahmana metodiku modeļu izveidē. Šajā metodikā tiek piedāvāts problēmu apskatīt no dažādiem aspektiem un dažādos līmeņos, iegūstot tabulu (divdimensiju matricu): Diemžēl šī metodika nesasaucas ar objektorientētu un sadalītu sistēmu izstrādi, jo tika izstrādāta vēl pirms šādas izstrādes izgudrošanas. Rīks ļauj veidot visas izplatītākās UML diagrammas un piedāvā savas modelēšanas valodas - IDEF0 (ir līdzība ar UML Use Case) un IFEF3 (UML Activity Diagram). Šīs modelēšanas valodas ir labi formalizētas, tāpēc IDEF3 (un Process Chart) ļauj arī simulēt un animēt procesus, kas būtiski palīdz procesu pārveidē un analīzē.

2. attēls. Popkin Software System Architect ar Zahmana piedāvāto modelēšanas metodiku (pa kreisi) un ar IDEF3 procesa diagrammu (pa labi) Rational Rose 2002 Modeler Edition Jaunākā versija gan ir Rose 2003, bet nekas, izņemot XP veida grafisko saskarni, tajā nav savādāks. Izplatītākais modelēšanas rīks ASV un arī pasaulē. UML standarta diagrammas tiek zīmētas, lietojot šo rīku. Pārsvars tirgū gan vairāk ir iegūts ar mārketingu, jo kā grafikas redaktors rīks ir vājš un lielas diagrammas zīmēt ir grūti (pēc noklusēšanas līnijas netiek veidotas taisnos 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 kodu. Rational Rose 2002 Modeler Edition neļauj no koda ģenerēt (vai sinhronizēt ar) diagrammu. Biznesa modelēšanai tas noder tikai kā konstruktors, un nekādas gatavas papildu iespējas (piemēram, Org diagrammai, biznesa apkārtnes aprakstīšanai, simulācijai) nepiedāvā. Sparx Systems Enterprise Architect 3.51 Rīks, kas ļauj veidot izplatītākās UML diagrammas un papildus vēl piedāvā savu pieeju biznesa modelēšanā. Biznesa modelēšanai piedāvā īpašu metodiku (atbilst Deminga/ISO procesu pārvaldībai un Portera Value Added Chain), bet nepiedāvā procesu simulāciju. Kā izstrādes rīks nodrošina arī koda ģenerēšanu un sinhronizēšanu ar diagrammu. Grafikas redaktors līdzīgs Rational Rose. Sparx Systems Enterprise Architect 3.51 ir viskompaktākais no visiem testētajiem rīkiem (programmas kataloga izmērs 17 MB!).

3. attēls. Sparx Systems Enterprise Architect 3.51. Casewise Corporate Modeler 8e Jaudīgs biznesa modelēšanas rīku komplekts, kas tomēr nenodrošina sasaisti ar programmu izstrādi. Līdzīgi kā System Architect, modelēšanā atbalsta Zahmana metodiku. Simulēto procesu analīzes metodika atbilst Balanced Scorecard. Šajā rīkā iespējams dažādos skatos (diagrammās) vairākkārt izmantot tos pašus projekta objektus (items), un īpašā matricā tiek parādītas konkrētās izmantošanas vietas. Tas ļauj simulēt un animēt Process Dynamic diagrammas. Rīks neļauj uzreiz zīmēt UML diagrammas, bet var izveidot savus šablonus. (Šādām diagrammām netiks veikta UML loģikas analīze, kas neļauj zīmēt nekorekti.) Rīks nodrošina Dynamics un Data Flow diagrammu konvertēšanu uz/no Rose Use Case diagrammām (saglabājot topoloģiju) un Dynamics diagrammu uz/no Visio blokshēmām (pat saglabājot grafisko izvietojumu!). QPR Software Plc QPR ProcessGuide 7.0, Infologistik GRADE 4.0 un IDS Sheer Aris 6.1 QPR ProcessGuide 7.0 ir biznesa modelēšanas rīks, kas piedāvā savu īpašu biznesa modelēšanas metodiku. Biznesa process tiek apskatīts kā Portera Value Added Chain, procesu (kvalitātes) pārvaldībā tiek izmantots Balanced Scorecard cikls. Rīkam ir sava modelēšanas valoda, kas ir pietiekami elastīga lai tajā iekļautu arī dažādus neformālus elementus (zīmējumus), bet arī pietiekami formāla, lai ļautu izveidoto procesu simulēt. Pēc simulācijas tiek piedāvāta dažādu datu analīze un attēlošana grafikos. Rīks noder tikai analīzei, jo programmatūras izstrādei tas nav paredzēts.

4. attēls. QPR Software Plc QPR ProcessQuide 7.0. GRADE 4.0 ir labākā cenas/jaudas attiecība, turklāt ar to var veidot patiesi lielas diagrammas. Šis rīks nepiedāvā īpašu metodiku, bet pilnībā var izmantot biznesa modelēšanai (ir arī organizatoriskā diagramma). Tas ir ar vecmodīgu Windows 3.1 saskarni un neatbalsta UML 2.0 diagrammas (rīka izstrādes laikā tika izstrādāta UML 1.3). IDS Cheer Aris 6.1 piedāvā īpašu metodiku kompilāciju (Value Added Chain, Deminga/ISO pārvaldības ciklu, Score Card), kā arī lielu diagrammu klāstu. Procesu simulācija iespējama eEPC diagrammām, un tiek izmantota activity-based cost metodika. Tas palīdz veidot dažādus skatījumus uz organizāciju un tās procesiem, bet slikti sasaucas ar programmatūras izstrādes paradigmām. To varētu izmantot biznesa cilvēki, bet zināmas problēmas būtu šo rīku lietot gan biznesa procesu aprakstīšanai, gan to nodrošināšanai, iztrādājot pārvaldības sistēmas. Vadoties pēc palīdzības (help), UML klašu diagrammu praktiski izveidot neizdevās. Citi rīki Vienā rakstā nav iespējams vispusīgi aplūkot visus vadošos biznesa modelēšanas rīkus. Tāpēc šajā numurā tika apskatīt Latvijā pieejamākie un pazīstamākie rīki. Gartnera grupas sagatavotu vadošo biznesa modelēšanas rīku apskatu var izlasīt http://www.gartner.com/gc/webletter/idsscheer/issue1/article1.html (pētījumu pasūtījusi IDS Scheer).

5.2. GRADE diagrammu piemēri GRADE diagrammu piemēri GRADE diagrammu piemēri atrodami - http://www.gradetools.com/grade40/examples.htm Workstation example

UML: class diagram

UML: use case diagram

UML: state diagram

GRADE: business process diagram Legend: Round rectangles - tasks (pieces of job) Arrows - events (messages) Hexagons - decisions Clocks - timers

GRADE: organization structure diagram Legend: Rectangles - organization units Round rectangles - positions Lined round rectangles - resources

GRADE: communicating objects diagram Top level diagram. Ministry of Planning and its environment

GRADE: process diagram (flowchart) Legend: Cyan - receive a message Gray - perform a simple action Yellow - take a decision Magenta - send a message Green - perform a procedure

GRADE: entity-relationship diagram You can generate database initialization scripts from these diagrams.

GRADE: data type diagram Example #1

5.3. Procesu aprakstīšanas programmas Procesu aprakstīšanas programmas Juris Nazarenko, E-pasaule

Publikācijā aplūkotas programmas, kuru būtiskākā funkcija ir aprakstīt biznesa procesus. Vispirms ir jāsaprot procesu aprakstīšanas būtība un pēc tam var novērtēt un salīdzināt vairākas programmas. Rakstā nav apskatīti jautājumi, kuri ir saistīti ar procesu orientāciju (process orientation) reālā uzņēmumā, bet gan aplūkota šādas programmatūras nozīme un specifiskās īpašības. Procesa orientācijas būtība

Modernajā ekonomikā ļoti liela uzmanība tiek veltīta klienta vajadzību apmierināšanai. Tas nozīmē, ka par katra uzņēmuma galveno uzdevumu kļūst nevis produkta vai pakalpojuma ražošana, bet gan to pārdošana klientam. Taču, uzņēmumam paplašinoties, tā vadība un darbinieki dažādu iemeslu dēļ sāk atšķirīgi skatīties uz vienām un tām pašām lietām un diezgan bieži klientam vairs nepiedāvā to, ko viņš vēlas. Šāda dīvaina situācija attēlota attēla augšējā daļā. Procesu orientācija Šādā situācijā vislabākis glābējlīdzeklis

procesu orientācija. Tas nozīmē, ka ar programmas palīdzību tiek atspoguļota sadarbība ar klientu, sākot no pirmās sarunas vai tikšanās līdz brīdim, kad klients saņem pasūtīto preci un norēķinās par to. Šī situācija atspoguļota attēla apakšējā daļā. Ir skaidri redzams, ka visi uzņēmuma darbinieki vienādi saprot procesa norisi un savu vietu šajā procesā. Taču vienmēr nepieciešams novērtēt un salīdzināt izmantojamās programmas. GRADE Modeler 4.0 (www.gradetools.com) Latvijas produkts, kuru izstrādāja Latvijas Universitātes speciālisti. Viens no raksturīgākajiem šīs programmas vērtējumiem - tai ir ļoti plašas iespējas. Lietojot šo programmu, var ļoti detalizēti dokumentēt procesu, noteikt katrai darbībai izpildītājus, veikt procesa simulāciju ("palaist" procesu reālā laikā) un analizēt procesu no dažādiem viedokļiem. Piemēram, var noteikt, cik ilgs būs viena produkta pārdošanas process, kādas ir viena procesa izmaksas, kā arī iespējams noteikt procesa vājās vietas un piedāvāt risinājumu situācijas uzlabošanai. Bez tam pastāv iespēja veikt dažādu datu eksportu un importu izmantojot atšķirīgus formātus (txt, ODBC). Kā priekšrocību var minēt to, ka aprakstīto procesu var publicēt intranetā jeb html formātā. Vēl viena šīs programmas priekšrocība ir tā, ka tai ir ļoti zema cena - ap Ls 300. Bet tas nenozīmē, ka programmai ir kaut kādas nepilnības, jo tā tiešām piedāvā ļoti plašas iespējas. Taču jāatzīmē arī šīs programmas divi galvenie trūkumi: • Pirmkārt, procesa aprakstīšanas laikā veidojas no biznesa viedokļa nepārskatāms gala attēls. Tas nozīmē, ka tad, ja ir vēlme izprast procesa norisi, to var izdarīt, bet

emocionāli (!) tas ir diezgan grūti, jo no tīri vizuālā viedokļa attēls nav pārāk pievilcīgs. • Otrkārt, šīs programmas lietošana ir sarežģīta - lai izmantotu kaut nelielu daļu no programmas iespējām, ir diezgan daudz laika jāvelta speciālistu apmācībai. Šī iemesla dēļ pat Latvijas Universitātes datorzinību maģistranti nevar sekmīgi izveidot maģistra darbu ar šīs programmas palīdzību. Secinājums - GRADE Modeler 4.0 lietot reālajā biznesā ir

diezgan apgrūtinoši, jo tā nerisina biznesa problēmas. Vācu kompānijas IDS Scheer programmu kopums ARIS (www.ids-scheer.com) IDS Scheer specializējas komplekso vadības risinājumu ieviešanā dažādu nozaru uzņēmumos. Ir atsevišķas programmas procesu aprakstīšanai, procesu simulēšanai, ABC metodoloģijas ieviešanai, sabalansētu vadības rādītāju pārvaldībai, kā arī atsevišķa programma procesu publicēšanai intranetā jeb html formātā. Protams, būtiskākā nozīme produktu nomenklatūrā ir procesu aprakstīšanas rīkam ARIS Toolset. Salīdzinājumā ar iepriekš aprakstīto produktu GRADE Modeler 4.0, ARIS Toolset ir ievērojami mazāk iespēju, tāpēc, lietojot šo programmu, arī iespējams paveikt krietni mazāk. Vācu kompānija šajā programmā ir atstājusi tikai reālam biznesam nepieciešamās iespējas - procesa aprakstīšanu. Kā būtisku šīs programmas priekšrocību var minēt to, ka ar iebūvētas programmēšanas valodas palīdzību no attēlotā procesa ir iespējams izdrukāt amata instrukciju katram darbiniekam, kas piedalās procesā. Turklāt šī instrukcija tiek izveidota literārā latviešu valodā. Programmas cena ir ap 3 000 ASV dolāru. ARIS Toolset būtiskākie trūkumi ir līdzīgi iepriekšminētās programmas trūkumiem: • Procesa attēlojums ir pasmags, bet tomēr ievērojami pievilcīgāks nekā ar programmu GRADE Modeler 4.0 iegūtais procesa attēlojums. • Lai strādātu ar šo programmu, ir nepieciešams iepazīties ar procesa dokumentēšanas noteikumiem, jo pretējā gadījumā nodokumentētu procesu nevarēs simulēt. QPR ProcessGuide

(www.qpr.com) Kā trešo no šāda veida programmām var apskatīt somu kompānijas QPR Software Plc. produktu QPR ProcessGuide (www.qpr.com). Arī šī kompānija piedāvā kompleksos risinājumus vadības metožu ieviešanai. Ir atsevišķas programmas gan procesu aprakstīšanai, gan ABC metodoloģijas ieviešanai, gan sabalansēto vadības rādītāju metodoloģijas ieviešanai, gan arī daudzas citas vadības programmas. Salīdzinājumā ar abām iepriekšminētajām

programmām procesu dokumentēšanas programmu QPR ProcessGuide var raksturot savādāk: 1) Šai programmai ir ļoti maz iespēju, jo tā ir domāta procesu dokumentēšanai un simulēšanai, tāpēc iemācīties strādāt ar to ir ļoti viegli. (Es personīgi sapratu visas programmas iespējas, noskatoties 15 minūšu garu videofilmu, kas ir pieejama QPR mājas lapā Internetā.) 2) Procesa attēlojums ir ļoti pievilcīgs no lietotāja viedokļa, kā arī vizuāli uz to ir

patīkami skatīties. 3) Pēc noklusēšanas procesu publicēšana notiek intranetā vai html formātā. Tas nozīmē, ka firmas darbinieki pārlūko procesu ar standarta Interneta pārlūkprogrammu (Internet Explorer). Ņemot vērā visu jau minēto, var teikt, ka šī programma palīdz risināt tikai biznesa vajadzības. Tas nozīmē, ka ar dokumentētiem procesiem var strādāt jebkurš firmas darbinieks neatkarīgi no viņa zināšanu līmeņa. Turklāt neviena no iepriekšminētajām programmām nenodrošina iespēju izveidot tik vienkāršu un pārskatāmu attēlu. Bez tam programma QPR ProcessGuide piedāvā datu importēšanas un eksportēšanas iespējas. Taču arī šai programmai ir savs trūkums - tā ir dārgāka par visām iepriekšminētajām, jo maksā 5 000 ASV dolāru. Secinājums Apkopojot informāciju par procesu aprakstīšanas programmu tirgu, var teikt, ka ir ap 1 400 procesu dokumentēšanas programmu, tāpēc ir iespējams izvēlēties sev visērtāko, izdevīgāko vai pat patīkamāko procesu dokumentēšanas programmu. Šīs programmas pārsvarā atšķiras : • ar procesa attēlošanas veidu; • ar papildu programmēšanas iespējām; • ar iespējām publicēt informāciju intranetā vai html formātā.

6.1. Konspekts Sistēmas objektu funkcionēšanas apraksti

MS no izvēlēm un formām. Kodu ģenerē automātiski. Konceptuālais modelis -> realizācijas modelis (kur atrisinātas m:n saites) Eksistē translatori no modeļa par DB (piemēram, Rational Rose) Strukturēta angļu valoda var kalpot par algoritma aprakstu Programmēšanas valoda, ar komentāriem, atkāpēm u.tml. nav viegli uztverams. Uzskata, ka 4. paaudzes programmēšanas valodas jau ir labi uztveramas. <mašīnkoda fragments??>

C ir stipri līdzīgs Asemblerim, uzskatāmība zema. Blokshēma

1. attēls. Blokshēmas elementi (pa kreisi) un piemērs (pa labi).. Shēmas atšķiras pēc sarežģītības. Shēmas, kuras sastāv no 3-9 elementiem ir vienkāršas. Lai shēmas būtu viegli lasāmas, tās ieteicams veidot dažādos detalizācijas līmeņos. Piemēram, 1.attēla shēmā darbības "Ieraksta apstrāde" detalizētu shēmu varētu iznest atsevišķā shēmā. Cits piemērs var būt datu apstrāde atšķirībā no ievadītas vērtības (sk. 2. attēlu). Piemērā attēlota shēma, kurā atkarībā no kursa vērtībām tiek izpildītas dažādas darbības. Šajā gadījumā darbību detalizēti apraksti arī var būt iznesti atsevišķās shēmās.

2. attēls. Kursa dažādu vērtību apstrāde. Strukturālā programmēšana Strukturālā programmēšanā atļautas tikai noteiktas konstrukcijas. Blokam ir viena ieeja un viena izeja. C valoda ir nestrukturāla, visi asembleri ir nestrukturāli. Strukturalitāte ne vienmēr nozīmē arī saprotamību. 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 uzvedību. Students - imatrikuēts, pārcelts 2. kursā, ... Datora stāvokļi - ieslēgts, izslēgts, sabojāts, ... Tātad, šie stāvokļi ir skats no funkcionēšanas viedokļa. Operatīvās atmiņas stāvokļi - cits skats. 2 256MB ir praktiska bezgalība, ar tik daudziem stāvokļiem nevar tikt galā. Sistēma → automāts (neliels stāvokļu skaits, definētas stāvokļu pārejas). Tas var kalpot par labu sistēmas aprakstu.

3. attēls. Uzņemšana universitātē. Nedeterminēts automāts. Tabulārais STD pieraksts. Personas kods Vārds UzvārdsStāvoklisPK1 Jānis Osis 1 ... ... ... ... Viegli atlasīt, toties grūti uztaisīt saprātīgu SPD.

7.1. Konspekts Lietotāja saskarne

(no http://members.tripod.com/~bazman/checklist.html?button1=GUI+Testing+Checklist) Tēmas plāns Terminoloģija un vēsture Lietotāja saskarnes novērtēšana Lietotāju orientēta saskarne programmproduktiem Lietotāju saskarnes pārbaudes jautājumu saraksts Terminoloģija un vēsture (Izmantoti materiāli no http://www.liis.lv/mspamati/ECDL/1modulis/e1040207.htm ) Definīcija: lietotāja saskarne

user interface; (lietotāja interefeis), Programmu un aparātu kopums, kas nodrošina informācijas apmaiņu starp lietotāju un datu apstrādes sistēmas aparatūras un programatūras komponentiem.

Lietotāja saskarne (interfeiss) ir veids kādā lietotājs var mijiedarboties ar datoru. Pirmajos IBM PC lietoja Disku Operētājsistēmu Sistēmu - DOS, kura izmantoja rakstzīmju orientētu lietotāja saskarni (lietotājs instrukcijas ievadīja teksta veidā). Rakstzīmju orientēta lietotāja saskarne (Character User Interface - CUI) ir lietotāja saskarne, kas atšķirībā no grafiskās lietotāja saskarnes komandu ievadīšanai datorā paredz izmantot tastatūru. (TTC datubāze) Tā, piemēram, lai kopētu datni no disketes uz cieto disku, jānorāda tās nosaukums atrašanās vieta un dublikāta atrašanās vieta:

Vēlāk vairākas firmas izstrādāja citas operētājsistēmas: firma Apple - operētājsistēmu Macinsosh System; firma IBM - operētājsistēmu OS/2; firma Microsoft - operētājsistēmu Windows. Šajās operētājsistēmās jau lietoja grafisko lietotāja saskarni. Grafiskā lietotāja saskarne ir (Graphical User Interface - GUI) ir displeja formatēšanas veids, kas ļauj lietotājam izvēlēties komandas, palaist programmas, kā arī apskatīt datņu sarakstus un citus objektus, norādot to piktogrāfiskos attēlus (ikonas). Izvēli var izdarīt, izmantojot tastatūru vai peli. Grafiskā lietotāja saskarne piedāvā vidi, kas nodrošina tiešu dialogu ar datoru. Grafisko lietotāja saskarni izmanto, piemēram, operētājsistēma Microsoft Windows. (TTC datubāze) GUI ir opererētājsistēmas papildu daļa, kas satur izvēlnes, norādes rīkus, programmu logus, ikonas un citus grafiskus elementus, kas veicina efektīvāku datora lietošanu. GUI atvieglo lietotāja mijiedarbība ar datoru. Tā, piemēram, lai kopētu datni no disketes uz cieto disku, izvēlas disketi un datnes ikonu pārvelk uz dublikāta atrašanās vietu:

Programmu logi var saturēt dažādus vadības objektus, piemēram, rīkjoslas, komandkartes un citu tekstuālu vai grafisku informāciju. Lai lietotājs saskarni varētu pielāgot savām vajadzībām, šo objektu novietojums, izmēri un forma var tikt mainīti. Lietotājs vienlaicīgi atvērt var vairāk kā vienas lietojumprogrammas logu un pēc tam viegli pāriet no vienas uz otru. Ieguvumi, lietojot GUI Sarežģītu instrukciju vienkāršošana, izmantojot ikonas un izvēlnes. Vieglāk organizēt darbu un pārvaldīt programmas un datnes. Visas programmas pēc izskata ir līdzīgas. Pārēja no vienas kādas ražotāja programmas uz cita ražotāja līdzīgu programmu ir vienkārša. Lietojumprogrammas darbojas līdzīgi datorā izmantotajai operētājsistēmai. Programmētāji var izveidot pēc izskata līdzīgas programmas. Lietotāja saskarnes novērtēšana Lietotāja saskarni var novērtēt pēc vairākiem principiem: cik ātri un ērti var iegūt vajadzīgo rezultātu iespēja intuitīvi (bez instrukciju lasīšanas) iegūt vajadzīgo rezultātu lietotā valoda, žargons, saprotamība, gramatiskas kļūdas ekrāna formu saprotamība programmas ātrdarbība programmas drošums pret lietotāja neloģiskām darbībām programmas spēja darboties daudzlietotāju režīmā krāsu un skaņas signālu izmantošana Izstrādājot lietotāju saskarni, kā svarīgākos var minēt sekojošus atribūtus: piemērotība uzdevumam (suitability for the task); pašaprakstāmība (self-descriptiveness); vadāmība (controllability); atbilstība lietotāja gaidītajam (conformity with user expectations); kļūdu piecietība (error tolerance); piemērotība individualizācijai (suitability for individualization); mācīšanās piemērotība (suitability for learning);

Lietotāju orientēta saskarne programmproduktiem (IBM stratēģijas Ease of Use) Lietotāju saskarnei ir jābūt orientētai. Šis faktors ir vitāli svarīgs ieviešot programmatūru. Ja lietotājiem programmatūras saskarne nav ērta, saprotama un vienkārši lietojama, tad, lai arī cik laba un kvalitatīva programmatūra nebūtu, to, iespējams, neviens neizmantos. Lai izstrādātu lietotāju orientētu saskarni, jāseko šādiem projektēšanas principi: - Nospraudiet biznesa mērķus. Nosakot mērķus un lietotāju cerības ir atslēga projektējuma uzsākšanai un lietotāju iesaistīšanai. - Saprotaties ar lietotājiem. Lietotāju iesaistīšana projektēšanas procesā ir viens no galvenajiem veiksmes faktoriem. Ja jūs vēlaties, lai lietotājs saprastu jūsu programmproduktu, jums ir sākumā jāsaprot lietotājs. - Sasniedziet konkurētspēju. Pārākuma sasniegšanai nepieciešams uzturēt konkurētspējīgu produktu. Kad jūs esat sapratis lietotāju uzdevumus, jums ir jātestē šos uzdevumus pret citu konkurentu alternatīvām un salīdzināt viņu un savus rezultātus. - Projektējiet vispārējo lietotāju pieredzi. Viss, ko redz un kam pieskārās lietotājs, ir projektēts kopā ar daudzdisciplīnu komanda. Tas iekļauj veidu, kā produkts tiek reklamēts, pasūtīts, iegādāts, iepakots, instalēts, administrēts, dokumentēts, atkļūdots un uzturēts. - Novērtējiet projektējumu. Lietotāju atsauksmes tiek iegūtas savlaicīgi un bieži, lietojot programmatūras prototipus, tādējādi šīs atsauksmes var virzīt programmprodukta projektēšanu un izstrādi pareizajā virzienā. - Pārvaldiet lietotāju pastāvīgu novērošanu. Produkta dzīves cikla laikā ir svarīgi novērot un uzklausīt lietotājus, tādējādi iegūstot atsauksmes turpmākai programmprodukta uzlabošanai, panākot labākus rezultātus. Lietotāju saskarnes pārbaudes jautājumu saraksts (no http://www.csst-technologies.com/guichk.htm) Šis saraksts ir izveidots, balstoties uz kļūdām, atrastām grafiskajās lietotāju saskarnēs. Šo sarakstu var izmantot kā sākumu lietotāju saskarnes testēšanā un apskatēs. Assure that the start-up icon for the application under consideration is unique from all other current applications. Assure the presence of a control menu in each window and dialog box. Assure the correctness of the Multiple Document Interface (MDI) of each window - Only the parent window should be modal (All child windows should be presented within the confines of the parent window). Assure that all windows have a consistent look and feel. Assure that all dialog boxes have a consistent look and feel. Assure that the child widows can be cascaded or tiled within the parent window. Assure that icons which represent minimized child windows can be arranged within the parent window. Assure the existence of the "File" menu. Assure the existence of the "Help" menu. Assure the existence of a "Window" Menu. Assure the existence and proper location of any other menus which are logically required by the application. Assure that the proper commands and options are in each menu. 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 invoke it where appropriate. In "tabbed" dialog boxes, assure that the tab names are not abbreviations. In "tabbed" dialog boxes, assure that the tabs can be accessed via appropriate hot key combinations. In "tabbed" dialoged boxes, assure that duplicate hot keys do not exist Assure that tabs are placed horizontally across the top (avoid placing tabs vertically on the sides as this makes the names hard to read). Assure the proper usage of the escape key (which is to roll back any changes that have been made). Assure that the cancel button functions the same as the escape key. Assure that the Cancel button becomes a Close button when changes have be made that cannot be rolled back. Assure that only command buttons which are used by a particular window, or in a particular dialog box, are present. When a command button is used sometimes and not at other times, assure that it is grayed out when it should not be used. Assure that OK and Cancel buttons are grouped separately from other command buttons. Assure that command button names are not abbreviations. Assure that command button names are not technical labels, but rather are names meaningful to system users. Assure that command buttons are all of similar size and shape. Assure that each command button can be accessed via a hot key combination (except the OK and CANCEL buttons which do not normally have hot keys). Assure that command buttons in the same window/dialog box do not have duplicate hot keys. Assure that each window/dialog box has a clearly marked default value (command button, or other object) which is invoked when the Enter key is pressed. Assure that focus is set to an object which makes sense according to the function of the window/dialog box. Assure that option button (AKA radio button) names are not abbreviations. Assure that option button names are not technical labels, but rather are names meaningful to system users. If hot keys are used to access option buttons, assure that duplicate hot keys do not exist in the same window/dialog box. Assure that option box names are not abbreviations. Assure that option box names are not technical labels, but rather are names meaningful to system users. If hot keys are used to access option boxes, assure that duplicate hot keys do not exist in the same window/dialog box. Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas. Assure that each demarcated area has a meaningful name that is not an abbreviation. Assure that the Tab key sequence which traverses the defined areas does so in a logical way. Assure that the parent window has a status bar. Assure that all user-related system messages are presented via the status bar. Assure consistency of mouse actions across windows.

Assure that the color red is not used to highlight active GUI objects (many individuals are red-green color blind). Assure that the user will have control of the desktop with respect to general color and highlighting (the application should not dictate the desktop background characteristics). Assure that the GUI does not have a cluttered appearance (GUIs should not be designed to look like a mainframe character user interfaces (CUIs) when replacing such data entry/retrieval screens) Lasiet vēl : http://hcibib.org/sam/ - Guidelines for design user interface software

7.2. Lietotāja saskarnes testēšanas kontrolsaraksts Lietotāja saskarnes testēšanas kontrolsaraksts CONTENTS: Section 1 - Windows Compliance Standards 1.1. Application 1.2. For Each Window in the Application 1.3. Text Boxes 1.4. Option (Radio Buttons) 1.5. Check Boxes 1.6. Command Buttons 1.7. Drop Down List Boxes 1.8. Combo Boxes 1.9. List Boxes Section 2 - Tester's Screen Validation Checklist 2.1. Aesthetic Conditions 2.2. Validation Conditions 2.3. Navigation Conditions 2.4. Usability Conditions 2.5. Data Integrity Conditions 2.6. Modes (Editable Read-only) Conditions 2.7. General Conditions 2.8. Specific Field Tests 2.8.1. Date Field Checks 2.8.2. Numeric Fields 2.8.3. Alpha Field Checks Section 3 - Validation Testing - Standard Actions 3.1. On every Screen 3.2. Shortcut keys / Hot Keys 3.3. Control Shortcut Keys Section 4 - Origin & Inspiration 4.1. Document origin 4.2. Sources of Inspiration & information 4.3. Contacting the author.

Section 1 - Windows Compliance Testing

1.1. Application Start Application by Double Clicking on its ICON. The Loading message should show the application name, version number, and a bigger pictorial representation of the icon (a 'splash' screen). No Login is necessary The main window of the application should have the same caption as the caption of the icon in Program Manager. Closing the application should result in an "Are you Sure" message box Attempt to start application Twice This should not be allowed - you should be returned to main Window Try to start the application twice as it is loading. On each window, if the application is busy, then the hour glass should be displayed. If there is no hour glass (e.g. alpha access enquiries) then some enquiry in progress message should be displayed. All screens should have a Help button, F1 should work doing the same. 1.2. For Each Window in the Application If Window has a Minimise Button, click it.

Window Should return to an icon on the bottom of the screen This icon should correspond to the Original Icon under Program Manager. Double Click the Icon to return the Window to its original size. The window caption for every application should have the name of the application and the window name - especially the error messages. These should be checked for spelling, English and clarity , especially on the top of the screen. Check does the title of the window makes sense. If the screen has an Control menu, then use all ungreyed options. (see below)

Check all text on window for Spelling/Tense and Grammar Use TAB to move focus around the Window. Use SHIFT+TAB to move focus backwards. Tab order should be left to right, and Up to Down within a group box on the screen. All controls

should get focus - indicated by dotted box, or cursor. Tabbing to an entry field with text in it should highlight the entire text in the field. The text in the Micro Help line should change - Check for spelling, clarity and non-updateable etc. If a field is disabled (greyed) then it should not get focus. It should not be possible to select them with either the mouse or by using TAB. Try this for every greyed control. Never updateable fields should be displayed with black text on a grey background with a black label. All text should be left-justified, followed by a colon tight to it. In a field that may or may not be updateable, the label text and contents changes from black to grey depending on the current status. List boxes are always white background with black text whether they are disabled or not. All others are grey. In general, do not use goto screens, use gosub, i.e. if a button causes another screen to be displayed, the screen should not hide the first screen, with the exception of tab in 2.0 When returning return to the first screen cleanly i.e. no other screens/applications should appear. In general, double-clicking is not essential. In general, everything can be done using both the mouse and the keyboard. All tab buttons should have a distinct letter. 1.3. Text Boxes

Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar. If it doesn't then the text in the box should be grey or non-updateable. Refer to previous page. Enter text into Box Try to overflow the text by typing to many characters - should be stopped Check the field width with capitals W. Enter invalid characters - Letters in amount fields, try strange characters like + , - * etc. in All fields. SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box. 1.4. Option (Radio Buttons)

Left and Right arrows should move 'ON' Selection. So should Up and Down.. Select with mouse by clicking. 1.5. Check Boxes

Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same.

1.6. Command Buttons

If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots. All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication. Click each button once with the mouse - This should activate Tab to each button - Press SPACE - This should activate Tab to each button - Press RETURN - This should activate The above are VERY IMPORTANT, and should be done for EVERY command Button. Tab to another type of control (not a command button). One button on the screen should be default (indicated by a thick black border). Pressing Return in ANY no command button control should activate it. If there is a Cancel Button on the screen , then pressing <Esc> should activate it. If pressing the Command button results in uncorrectable data e.g. closing an action step, there should be a message phrased positively with Yes/No answers where Yes results in the completion of the action. 1.7. Drop Down List Boxes

Pressing the Arrow should give list of options. This List may be scrollable. You should not be able to type text in the box. Pressing a letter should bring you to the first item in the list with that start with that letter. Pressing ‘Ctrl - F4’ should open/drop down the list box. Spacing should be compatible with the existing windows spacing (word etc.). Items should be in alphabetical order with the exception of blank/none which is at the top or the bottom of the list box. Drop down with the item selected should be display the list with the selected item on the top.

Make sure only one space appears, shouldn't have a blank line at the bottom. 1.8. Combo Boxes

Should allow text to be entered. Clicking Arrow should allow user to choose from list 1.9. List Boxes

Should allow a single selection to be chosen, by clicking with the mouse, or using the Up and Down Arrow keys. Pressing a letter should take you to the first item in the list starting with that letter. If there is a 'View' or 'Open' button beside the list box then double clicking on a line in the List Box, should act in the same way as selecting and item in the list box, then clicking the command button. Force the scroll bar to appear, make sure all the data can be seen in the box.

Section 2 - Screen Validation Checklist 2.1. Aesthetic Conditions: Is the general screen background the correct colour? Are the field prompts the correct colour? Are the field backgrounds the correct colour? In read-only mode, are the field prompts the correct colour? In read-only mode, are the field backgrounds the correct colour? Are all the screen prompts specified in the correct screen font? Is the text in all fields specified in the correct screen font? Are all the field prompts aligned perfectly on the screen? Are all the field edit boxes aligned perfectly on the screen? Are all groupboxes aligned correctly on the screen? Should the screen be resizable? Should the screen be minimisable? Are all the field prompts spelt correctly? Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified. Are all numeric fields right justified? This is the default unless otherwise specified. Is all the microhelp text spelt correctly on this screen? Is all the error message text spelt correctly on this screen? 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 into fields. The user must either enter an alternative valid value or leave the default value intact. Assure that all windows have a consistent look and feel. Assure that all dialog boxes have a consistent look and feel. 2.2. Validation Conditions: Does a failure of validation on every field cause a sensible user error message? Is the user required to fix entries which have failed validation tests? Have any fields got multiple validation rules and if so are all rules being applied? If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.? Is validation consistently applied at screen level unless specifically required at field level? For all numeric fields check whether negative numbers can and should be able to be entered. For all numeric fields check the minimum and maximum values and also some mid-range values allowable? For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size? Do all mandatory fields require user input? If any of the database columns don't allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.) 2.3. Navigation Conditions: Can the screen be accessed correctly from the menu? Can the screen be accessed correctly from the toolbar? Can the screen be accessed correctly by double clicking on a list control on the previous screen? Can all screens accessible via buttons on this screen be accessed correctly? Can all screens accessible by double clicking on a list control be accessed correctly? Is the screen modal. i.e. Is the user prevented from accessing other functions when this screen is active and is this correct? Can a number of instances of this screen be opened at the same time and is this correct? 2.4. Usability Conditions: Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified. Is all date entry required in the correct format? Have all pushbuttons on the screen been given appropriate Shortcut keys? Do the Shortcut keys work correctly? Have the menu options which apply to your screen got fast keys associated and should they have? Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified. Are all read-only fields avoided in the TAB sequence? 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 the mouse? Can the cursor be placed in read-only fields by clicking in the field with the mouse? Is the cursor positioned in the first input field or control when the screen is opened? Is there a default button specified on the screen? Does the default button work correctly? When an error message occurs does the focus return to the field in error when the user cancels it? When the user Alt+Tab's to another application does this have any impact on the screen upon return to The application? Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer 2.5. Data Integrity Conditions: Is the data saved when the window is closed by double clicking on the close box? Check the maximum field lengths to ensure that there are no truncated characters? Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact. Check maximum and minimum field values for numeric fields? If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers? If a set of radio buttons represent a fixed set of values such as A, B and C then what happens if a blank value is retrieved from the database? (In some situations rows can be created on the database by other functions which are not screen based and thus the required initial values can be incorrect.) If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values. 2.6. Modes (Editable Read-only) Conditions: Are the screen and field colours adjusted correctly for read-only mode? Should a read-only mode be provided for this screen? Are all fields and controls disabled in read-only mode? Can the screen be accessed from the previous screen/menu/toolbar in read-only mode? Can all screens available from this screen be accessed in read-only mode? Check that no validation is performed in read-only mode. 2.7. General Conditions: Assure the existence of the "Help" menu. Assure that the proper commands and options are in each menu. Assure that all buttons on all tool bars have a corresponding key commands. Assure that each menu command has an alternative(hot-key) key sequence which will invoke it where appropriate. In drop down list boxes, ensure that the names are not abbreviations / cut short In drop down list boxes, assure that the list and each entry in the list can be accessed via appropriate key / hot key combinations. Ensure that duplicate hot keys do not exist on each screen

Ensure the proper usage of the escape key (which is to undo any changes that have been made) and generates a caution message "Changes will be lost - Continue yes/no" Assure that the cancel button functions the same as the escape key. Assure that the Cancel button operates as a Close button when changes have be made that cannot be undone. Assure that only command buttons which are used by a particular window, or in a particular dialog box, are present. - i.e make sure they don't work on the screen behind the current screen. When a command button is used sometimes and not at other times, assure that it is grayed out when it should not be used. Assure that OK and Cancel buttons are grouped separately from other command buttons. Assure that command button names are not abbreviations. Assure that all field labels/names are not technical labels, but rather are names meaningful to system users. Assure that command buttons are all of similar size and shape, and same font & font size. Assure that each command button can be accessed via a hot key combination. Assure that command buttons in the same window/dialog box do not have duplicate hot keys. Assure that each window/dialog box has a clearly marked default value (command button, or other object) which is invoked when the Enter key is pressed - and NOT the Cancel or Close button Assure that focus is set to an object/button which makes sense according to the function of the window/dialog box. Assure that all option buttons (and radio buttons) names are not abbreviations. Assure that option button names are not technical labels, but rather are names meaningful to system users. If hot keys are used to access option buttons, assure that duplicate hot keys do not exist in the same window/dialog box. Assure that option box names are not abbreviations. Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas "Group Box" Assure that the Tab key sequence which traverses the screens does so in a logical way. Assure consistency of mouse actions across windows. Assure that the color red is not used to highlight active objects (many individuals are red-green color blind). Assure that the user will have control of the desktop with respect to general color and highlighting (the application should not dictate the desktop background characteristics). Assure that the screen/window does not have a cluttered appearance Ctrl + F6 opens next tab within tabbed window Shift + Ctrl + F6 opens previous tab within tabbed window Tabbing will open next tab within tabbed window if on last field of current tab Tabbing will go onto the 'Continue' button if on last field of last tab within tabbed window Tabbing will go onto the next editable field in the window 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 no need to scroll Errors on continue will cause user to be returned to the tab and the focus should be on the field causing the error. (i.e the tab is opened, highlighting the field with the error on it) Pressing continue while on the first tab of a tabbed window (assuming all fields filled correctly) will not open all the tabs. On open of tab focus will be on first editable field All fonts to be the same Alt+F4 will close the tabbed window and return you to main screen or previous screen (as appropriate), generating "changes will be lost" message if necessary. Microhelp text for every enabled field & button Ensure all fields are disabled in read-only mode Progress messages on load of tabbed screens Return operates continue If retrieve on load of tabbed window fails window should not open 2.8. Specific Field Tests 2.8.1. Date Field Checks Assure that leap years are validated correctly & do not cause errors/miscalculations Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations Assure that 00 and 13 are reported as errors Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations Assure that Feb. 30 is reported as an error Assure that century change is validated correctly & does not cause errors/ miscalculations Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations 2.8.2. Numeric Fields Assure that lowest and highest values are handled correctly Assure that invalid values are logged and reported Assure that valid values are handles by the correct procedure Assure that numeric fields with a blank in position 1 are processed or reported as an error Assure that fields with a blank in the last position are processed or reported as an error an error Assure that both + and - values are correctly processed Assure that division by zero does not occur Include value zero in all calculations Include at least one in-range value Include maximum and minimum range values Include out of range values above the maximum and below the minimum Assure that upper and lower values in ranges are handled correctly

2.8.3. Alpha Field Checks Use blank and non-blank data Include lowest and highest values Include invalid characters & symbols Include valid characters Include data items with first position blank Include data items with last position blank

Section 3 - Validation Testing - Standard Actions 3.1. Examples of Standard Actions - Substitute your specific commands Add View Change Delete Continue - (i.e. continue saving changes or additions) Add View Change Delete Cancel - (i.e. abandon changes or additions) Fill each field - Valid data Fill each field - Invalid data Different Check Box / Radio Box combinations Scroll Lists / Drop Down List Boxes Help Fill Lists and Scroll Tab Tab Sequence Shift Tab 3.2. Shortcut keys / Hot Keys Note: The following keys are used in some windows applications, and are included as a guide.

Key No Modifier Shift CTRL ALT

F1 Help Enter Help Mode

n\a n\a

F2 n\a n\a n\a n\a

F3 n\a n\a n\a n\a

F4 n\a n\a Close Document / Child window.

Close Application.

F5 n\a n\a n\a n\a

F6 n\a n\a n\a n\a

F7 n\a n\a n\a n\a

F8 Toggle extend mode, if supported.

Toggle Add mode, if supported.

n\a n\a

F9 n\a n\a n\a n\a

F10 Toggle menu bar activation.

n\a n\a n\a

F11, F12 n\a n\a n\a n\a

Tab Move to next active/editable field.

Move to previous active/editable field.

Move to next open Document or Child window. (Adding SHIFT reverses the order of movement).

Switch to previously used application. (Holding down the ALT key displays all open applications).

Alt Puts focus on first menu command (e.g. 'File').

n\a n\a n\a

3.3. Control Shortcut Keys

Key Function

CTRL + Z Undo

CTRL + X Cut

CTRL + C Copy

CTRL + V Paste

CTRL + N New

CTRL + O Open

CTRL + P Print

CTRL + S Save

CTRL + B Bold*

CTRL + I Italic*

CTRL + U Underline*

* These shortcuts are suggested for text formatting applications, in the context for which they make sense. Applications may use other modifiers for these operations.

8.1. Konspekts Darba organizācija programmēšanas grupā Projekta komanda un tās izvēle Programmatūras izstrādes projekta realizācijas komandas plānošana ir atbildīs solis. No projekta komandas komplektācijas ir atkarīga projekta turpmākā norise un veiksme. Novērtējot projektam nepieciešamo darbietilpību jau ir jāzina, kādi darbinieki piedalīsies sistēmanalīzē, projektēšanā, izstrādē, testēšanā, dokumentēšanā un ieviešanā. Izstrādes projektos parasti piedalās: projekta vadītājs; sistēmanalītiķi; projektētāji; programmētāji; testētāji; dokumentētāji; kvalitātes speciālisti; administrators. Taču šo lomu skaits var būtiski atšķirties atkarībā no projekta lieluma. Mazajos projektos viens un tas pats darbinieks var pildīt vairākus uzdevumus. Jo lielāks projekts, jo svarīgāka ir lomu atdalīšana un šaurāka specializācija. Tomēr šo IT organizācijas tieši projektā iesaistītie darbinieki nav vienīgie. Ne mazāk svarīgi atrast projekta sponsoru - ieinteresēto personu no Pasūtītāja puses, kā arī projekta pārraugu no IT organizācijas augstākās vadības. Ir vitāli svarīgi iesaistīt arī citus pasūtītāja pārstāvjus, kā biznescilvēkus, izstrādājamās sistēmas lietotājus un akcepttestēšanas dalībniekus. Plānojot projekta komandu ir vērtīgi ņemt vērā šādus faktorus: Vai projekta komanda ir sastrādājusies? Savstarpējas komunikācijas stingri apgrūtinātas Daļēji sastrādājusies komanda Pārsvarā sastrādājusies komanda Ļoti labi sastrādājusies komanda Kāda ir iesaistīto darbinieku pieredze līdzīgu projektu realizācijā? Nav Komandai tas ir pārsvarā nepazīstams uzdevums Ir atrodamas dažas nepazīstamas vietas Komandai šis ir vispārīgos vilcienos pazīstams uzdevums Šis ir pārsvarā pazīstams uzdevums Šis ir l abi zināms uzdevums

Kāda ir iesaistīto darbinieku pieredze IT jomā? Ārkārtīgi zema (<=3 mēnešiem) Ļoti zema (~5 mēneši) Zema (~9 mēneši) Normāla (~1 gads) Augsta (~2 gadi) Ļoti augsta (~4 gadi) Ārkārtīgi augsta (~6 gadi) Kādas ir izstrādātāju spējas? Ārkārtīgi zemas Ļoti zemas Zemas Normālas Augstas Ļoti augstas Ārkārtīgi augstas Augsta riska programmatūras izstrādē ir svarīgi iesaistīt pēc iespējas kompetentākus cilvēkresursus, kuri ir kopā strādājuši jau kādā projektā. Bieži vien, ja programmatūras pasūtītājs izsludina konkursu par iespēju izstrādāt informācijas sistēmu, konkursa nolikumā tiek uzskaitītas arī prasības pret izstrādes komandu, tai skaitā iesaistīto darbinieku izglītību, profesionālo pieredzi, sertifikāciju un tml. Projekta komandu pārvalda Projekta pārvaldnieks. Tas ir darbinieks, kurš lielo projektu gadījumā visbiežāk nav saistīts ne ar vienu citu lomu projektā un veic projekta komandas uzraudzību, resursu pārvaldību, projekta plānošanu un citas ar projekta pārvaldību saistītus uzdevumus. Hierarhisks pārvaldības modelis Tipisks projekta pārvaldības modelis ir hierarhija, kuras virsotnē atrodas projekta pārvaldnieks, kuram ir pakārtotas izstrādes komandu līderi, kuri, savukārt, ir saistīti tālāk ar izstrādātājiem. Lielo projektu gadījumā projektā var iesaistīt vairākus pārvaldības līmeņus. Mazo projektu gadījumā projekta organizatoriska struktūra parasti ir daudz vienkāršāka.

1. attēls. Pārvaldības modelis - hierarhija. Hierarhiskās struktūras pielietojuma piemērs var būt šāds - projektā var būt iesaistītas 4 apakšgrupas - Izstrādes grupa, Testētāju grupa, Dokumentētāju grupa un Kvalitātes pārvaldības grupa. Katra no šīm grupām tiek pārvaldīta neatkarīgi, strādā dažreiz sadarbojoties. Katru no šīm grupām vada līderis, kurš ir atbildīgs par grupas

sniegumu. Savukārt par projekta kopējiem rezultātiem ir atbildīgs projekta vadītājs, kurš saņem informāciju no grupu līderiem. Lielākajos projektos (50 un vairāk iesaistīto darbinieku) starp projekta pārvaldnieku un grupu līderiem var būt izveidots papildus līmenis - apakšprojektu vadītāji. Atkarībā no iespējas projektu neatkarīgi izstrādāt pa moduļiem, projekts var būt sadalīts vairākos apakšprojektos. Alternatīva hierarhiskajam projekta organizācijas modelim ir "Āzijas" jeb armijas modelis. Spēcīga motivācijas sistēma. Piemēri - mongoļu impērija, nacistu sistēma, padomju sistēma. Pārvaldības modelis - būvu cilvēku kompānija Vēl viens projekta organizatorisks modelis ir būvu cilvēku kompānija - lēmumu pieņemšana gandrīz neiespējama. Piemērs - Eiropa nespēj pieņemt lēmumu Irākas jautājumā, Balkānu jautājumā u.tml.

2. attēls. Pārvaldības modelis - būvu cilvēku kompānija. Administratīvais (pozitīvās un negatīvās puses) - skaidra atbildība, - kontekstu var nezināt, - jo augstāk hierarhija, jo lielāka slodze un atbildība, - "aklais lidotājs - programmētāji, kas nezina kontekstu Galvenā programmētāja brigāde (Chief Programmer's Team) Funkcijas : - Galvenais programmētājs - pats pieredzējušākais, labākais u.tml.; pats izstrādā svarīgākos gabalus. - Otrais pilots - zina to pašu un var uzņemties vadību; arī pats izstrādā. - Programmētāji - izstrādā. - Instrumentālists - izvēlas vidi, apgūst, pēc tam māca / konsultē - Dokumentētājs - atbild par sistēmas dokumentāciju - Bibliotekārs - pārzina versijas - Vadītājs (manager) - nodrošina resursus u.tml. Komanda uzstājas kā vienots organisms. Hierarhiskajā modelī vadītāji ātri pārstāj būt speciālisti (programmēšanas speciālisti). Galvenā programmētāja brigādē (GPB) saglabājas profesionalitāte, aug jauni līderi, taču jābūt saderīgiem raksturiem. Tomēr GPB ir kāds apjoma slieksnis, ko tā nespēj pārkāpt, t.i. apmēram 10-20000 gatavu koda rindiņu gadā ar visu dokumentāciju. Lielākām sistēmām hierarhija ir neizbēgama.

Prince organizācijas struktūra Pārvaldības modeļa nosaukums PRINCE ir saīsinājums no 'Projects in Controlled Environments' jeb projekti pārvaldāmā vidē. PRINCE ir strukturēta pieeja projektu pārvaldībai un to ir izstrādājusi Lielbritānijas valdība. PRINCE modelis jau sākumā tika paredzēts informācijas sistēmu izstrādes projektiem, taču lielākā daļa modeļa principu ir attiecināma uz plaša spektra projektu situācijām. PRINCE piedāvā vairākas priekšrocības, kuras padara programmatūras izstrādes projektus veiksmīgus: Definēta pārvaldības struktūra Plānošanas sistēma Pārvaldāmo procedūru kopa Fokusēšanās uz produktu plānošanas, t.i. nodevumu plānošanas. PRINCE pārvaldības struktūra. PRINCE pārvaldības hierarhijas galā atrodas pārvaldības aparāts, kurš nosaka vispārējus mērķus programmatūras izstrādes projekta organizācijai. Šis līmenis var atšķirties katrā organizācijā. Iespējams, ka svarīgākus lēmumus pieņems organizācijas vadība organizācijas valdes priekšsēdētāju sastāvā. Patstāvīgu projektu augstākā līmeņa vadība, kuru nosaka PRINCE sauc par projekta valdi. Projekta valde reprezentē trīs galvenās instances, svarīgas projektu pārvaldībā : izpild-vadītājs - persona, kuru ievel organizācijas augstākā vadība savu biznesa interešu aizstāvībai; galvenais lietotājs - reprezentē biznesa sfēras intereses, kuras ietekmē jaunas informācijas sistēmas ieviešana, un runā visu gala lietotāju vārdā; galvenais piegādātājs - reprezentē jaunas informācijas sistēmas izstrādātājus, tas var būt IT direktors vai programmatūras izstrādes pārvaldnieks.

Svarīgi ir tas, ka PRINCE modelis ir elastīgs, tādējādi organizatoriskā struktūra var variēt, lai labāk atbilstu projektu specifikai un vajadzībām. Piemēram, iespējama situācija, kurā izpild-vadītāja un galvenā lietotāja lomu no pasūtītāja puses pārstāv viena un tā pati persona. No otras puses, var gadīties situācija, kurā galveno lietotāja lomu pārstāv vairāki gala lietotāju pārstāvji. Galvenais ir iedibināt efektīvi strādājošu 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 pārvaldnieku atbilstības sfēra. Projekta pārvaldnieka lomai nav nepieciešami komentāri. Kas attiecās uz komandu pārvaldniekiem, PRINCE modelis paredz, ka projekts sava dzīves cikla laikā izies cauri vairākām fāzēm, kurās iespējami būs nepieciešams atsevišķs atbildīgais. Tā kā katrā no fāzēm var būt nepieciešamas specifiskas atšķirīgas zināšanas, komandu pārvaldnieka lomu var katrā no šīm fāzēm ieņemt cits darbinieks. Tādējādi var gadīties, ka projekta pārvaldnieks strādā projekta laikā ar vairākiem komandu pārvaldniekiem; vai projekta pārvaldnieks uzņemas arī komandu pārvaldnieka lomu; vai projekta pārvaldnieka lomu var katrā atsevišķā fāzē uzņemties komandas pārvaldnieks. Projekta nodrošinājuma līmenis atrodas starp projekta valdes un projekta pārvaldnieka līmeņiem. Tas iekļauj trīs galvenos aspektus - biznesa nodrošinājumu (jebkuru būtisko izmaiņu ietekmes novērtējums un kontrole), lietotāju nodrošinājumu (programmatūras gala lietotāju interešu pārstāvēšana, prasību realizācijas kontrole) un tehnisko nodrošinājumu (palīdzība tehnisko projekta stratēģiju definēšanā, kvalitātes kritēriju un citu tehnisko metožu un standartu ievērošanas kontrole). Projekta atbalsta līmenis atrodas starp projekta pārvaldnieku un komandu pārvaldniekiem. Projekta atbalsta komanda palīdz projekta pārvaldniekam plānu sastādīšanā, projekta atsekošanā un mērīšanā, projekta un komandu pārvaldības atskaišu sagatavošanā, kā arī veic lēmumu pieņemšanas procesa kontroli un projekta progresa uzraudzību. Lai projekts būtu veiksmīgs, ir vitāli svarīgi apzināties kurš ir pasūtītājs, kurš pieņem galvenos svarīgus lēmumus un kurš uzņemsies atbildību par projektā notiekošo. PRINCE nodrošina projekta pārvaldības metodi, kura piedāvā ērtu un efektīvu struktūru programmatūras projektu pārvaldībai.

8.2. Kā top informācijas sistēmas III Kā top informācijas sistēmas Izmantotie materiāli: Ivards Solovjovs, DatorPasaule, 2'2000, III daļa Projektu vadīšanas tehnika IS projekts parasti sastāv no daudzām savstarpēji saistītām aktivitātēm (dažkārt to ir simtiem), kurās tiek iesaistīti daudzi cilvēki (parasti 5 – 100), kā arī eksistē dažādi ierobežojumi (koplietošanas resursi, fiksēti atsevišķu notikumu termiņi un citi). Lai šo procesu varētu normāli plānot un vadīt, īpaši noderīga ir vispārpieņemtā projektu vadīšanas tehnika. Pazīstamākās no projekta plānošanas tehnikām (rīkiem) ir GANTT un PERT diagrammas. Pirmā akcentē atsevišķu darbu izpildes termiņus un nepieciešamos resursus, otrā – aktivitāšu un notikumu savstarpējo atkarību. Abu veidu diagrammas atbalsta arī plaši lietotā Microsoft Project programmatūra. 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: Darbu (aktivitāšu) sadalīšana sīkāk. Projekta mērķa dekompozīcija, atsevišķos darbos (aktivitātēs) iegūstot vairāklīmeņu hierarhisku, numurētu struktūru (work breakdown structure – WBS). Detalizācijas līmenis ir atkarīgs no abstrakcijas līmeņa, kādā projekts tiek aplūkots (piemēram, zemākā līmeņa aktivitāte var atbilst gan līgumā paredzētam darbu posmam, gan arī konkrētam darbiniekam uzdodamajam uzdevumam). Projekta darbu (aktivitāšu) secīga sakārtošana. Katram darbam tiek norādīti tie darbi, kuru pabeigšana ir priekšnosacījums tā uzsākšanai (predsessors), Tādējādi tiek definēta darbu izpildes loģiskā secība. Darbu (aktivitāšu) termiņu, resursietilpības un izmaksu vērtēšana. Katram darbam tiek novērtēti tā izpildei nepieciešamie resursi, kā arī termiņi (sk. nākamo sadaļu). Tā kā darba apjoms ir funkcija no laika un resursiem, tad atkarībā no tā, kas ir ierobežojošais faktors, var izvēlēties dažādus darbu izpildes variantus. Projekta plāna saskaņošana ar laika ierobežojumiem. Ja ierobežojošais faktors ir projekta izpildes gala termiņš, to var mēģināt samazināt, palielinot iesaistāmos resursus, mainot darbu izpildes secību (piemēram, atsevišķus darbus veicot paralēli) vai radikālā gadījumā samazinot izvirzīto mērķi (funkcionalitāti). Projekta plāna optimizēšana, izmantojot kritiskā ceļa metodi. Īpaša metode projekta plāna analīzei un optimizēšanai, nosakot to darbu virkni, kas summāri veido visgarāko laika posmu. Saīsinot vai citādi optimizējot darbus, kuri atrodas uz kritiskā ceļa, reizē tiek samazināts arī projekta kopējais garums. Projekta plāna saskaņošana ar resursu ierobežojumiem. Ja ierobežojošais faktors ir pieejamie resursi, darbu izpildes termiņi ir "jāsakrata" atbilstoši to pieejamībai. Protams, jāizvairās arī no resursu dīkstāves, kā arī straujiem resursu izmantošanas lēcieniem. Regulāra projekta darbu izpildes uzraudzīšana, projekta plāna modificēšana, kā arī citu koriģējošu pasākumu veikšana. Tas ir regulārs process visa projekta garumā, kura ietvaros, tiek sekots līdzi, kā tiek pildīti plānotie darbi. Termiņu kavējumu gadījumā vai nu tiek veiktas koriģējošas darbības (piemēram, izdalīti papildu resursi vai speciāli motivēti darbinieki), vai arī tiek mainīts projekta plāns atbilstoši faktiskajai situācijai. Šajā gadījumā papildus sākotnējam plānam parādās plāna bāzlīniju versijas. Jebkuras projekta plāna izmaiņas ir formāli akceptējamas attiecīgā līmeņa projekta vadības institūcijā. Resursu un termiņu novērtēšana – IS projektu kritiskais faktors Programmatūras izstrādei nepieciešamā darba apjoma un termiņu pareizs novērtējums

laikam ir uzskatāms par sekmīga projekta galveno priekšnosacījumu. Pat pieredzējuši izstrādātāji, paļaujoties tikai uz savu intuīciju, šajā ziņā mēdz kļūdīties pat par kārtu. Tāpēc nav brīnums, ka jau kopš programmatūras izstrādes pirmsākumiem, pamatojoties uz uzkrāto pieredzi, ir mēģināts izveidot precīzu kvantitatīvi algoritmisku modeli, kas būtu izmantojams programmatūras izstrādei nepieciešamā darba apjoma un termiņu prognozēšanai. Pašreiz plaši tiek izmantots COCOMO modelis (ir vairāki tā paveidi), kura pamatā ir funkcijpunkti. Tā ir nosacīta mērvienība, kas atbilst izstrādājamās programmatūras funkcionalitātei un kura tiek novērtēta, balstoties uz programmatūras funkcionāli skaitliskiem atribūtiem (ievades, izvades, vaicājumu, iekšējo datu failu, saskarņu skaits, to sarežģītības vērtējums). Tālāk tiek novērtēts, ar cik programmēšanas valodas nosacītām koda rindiņām dotā funkcionalitāte ir realizējama (atkarīgs no programmēšanas vides produktivitātes). Tad, ņemot vērā vairākus izstrādes procesu raksturojošus atribūtus (izstrādātāju pieredze, koda atkārtojama izmantošana, laika un citi ierobežojumi, prasību stabilitāte u.tml.), tiek novērtēts gan darba apjoms (cilvēkmēnešos), gan termiņi (mēnešos). Turklāt jāpiezīmē, ka mēneši un cilvēki nav savstarpēji aizvietojami (deviņi cilvēki vienā mēnesī nevar paveikt to, ko viens deviņos: jo vairāk cilvēku, jo lielāka darba daļa aiziet uz komunikāciju un koordinēšanu). Jāsaka, ka šādi iegūti vērtējumi ir tikai aptuveni, turklāt – jo precīzākas mūsu zināšanas par izstrādājamo sistēmu, jo precīzāka ir prognoze. Parastā prakse ir tāda, ka COCOMO metodi izmanto, balstoties uz programmatūras prasību specifikācijā pieejamo informāciju. Pieredze rāda, ka šādi iegūtās prognozes pietiekami precīzi sakrīt ar faktiskajiem skaitļiem. Nozīmīgs faktors prognozes precizitātes palielināšanai ir pieredzes uzkrāšana un formulās izmantojamo koeficientu koriģēšana, balstoties uz prognozēto un faktisko skaitļu salīdzināšanu. Projekta organizatoriskā struktūra Efektīva projekta vadība nav iespējama bez atbilstošas projekta organizatoriskās struktūras izveides. Tas nozīmē, ka jāizveido projekta vadības institūcijas, jānozīmē konkrētas amatpersonas, jāizstrādā un jāapstiprina attiecīgi nolikumi un amatinstrukcijas. Stratēģisku projekta jautājumu risināšanai būtu jāorganizē projekta valde (angliski šo institūciju mēdz saukt par steering comitee vai project board). Šie jautājumi ietver projekta stratēģisko uzdevumu formulēšanu un izpildes kontroli, projekta plānu apstiprināšanu, koriģēšanu un plānu izpildes kontroli, principiālu projekta lēmumu pieņemšanu, finansu un citu resursu nodrošināšanu, finansiālu jautājumu un konfliktsituāciju risināšanu, kā arī citus stratēģiskus jautājumus. Valdes sastāvu parasti veido uzņēmuma vadības pārstāvji, lietotāju vadības pārstāvji, uzņēmuma IT daļas vadītājs, galveno projekta izpildē iesaistīto organizāciju augstākās amatpersonas, kā arī projekta vadītāji (gan no pasūtītāja, gan izpildītāju puses). Lai risinātu konkrētus ar projekta izpildi saistītus jautājumus, parasti tiek izveidota izmaiņu vadības padome (IVP) vai vienkārši projekta vadības padome, kuras kompetencē ir projekta darbu izpildes organizēšana, prasību, projektējumu un citu dokumentu apstiprināšana, izmaiņu pieprasījumu un problēmziņojumu izskatīšana, izpildītāju darba koordinēšana, kā arī citu darba jautājumu risināšana. IVP sastāvā ir iekļaujami projektu vadītāji (gan no pasūtītāja, gan izpildītāju puses), lietotāju pārstāvji, izstrādātāju pārstāvji, uzņēmuma IT daļas pārstāvji, kā arī citi speciālisti. IVP sēdēm jānotiek regulāri (teiksim, reizi nedēļā) un jātiek attiecīgi protokolētām. Nepieciešamības gadījumā var izveidot arī IVP apakškomisijas, kurās tiek risināti ar

atsevišķu apakšsistēmu (kādu komponentu vai tematisko jomu) saistīti jautājumi (sk. 2. attēlu.)

Pr Vadibas Str.BMP (72898 bytes)

Izmaiņu pārvaldība Vēl viens nozīmīgs aspekts visa projekta dzīves cikla garumā ir izmaiņu pārvaldība. Lai cik precīzi mēs censtos specificēt izstrādājamo sistēmu un definēt izstrādātājam darba uzdevumu, laikā gaitā parādās jaunas prasības, izpētes rezultātā esošās ir jāmodificē, tāpēc ir jāmaina arī darba uzdevums izstrādātājam. Sistēmas darbināšanas laikā lietotāji var vēlēties kādas jaunas iespējas vai arī tiek konstatētas dažādas nepilnības sistēmas darbā. Šāda situācija ir normāla, un grūti iedomāties, ka kaut cik nopietnā projektā varētu būt citādi. Lai nerastos problēmas abu pušu starpā, ir ļoti svarīgi, lai eksistētu dokumentēts un savstarpēji saskaņots mehānisms un procedūra šādu jautājumu risināšanai. Parasti visas pasūtītāja vēlmes, kā arī konstatētās problēmas tiek fiksētas izmaiņu pieprasījumu un problēmziņojumu veidā ar speciālu veidlapu palīdzību. Visi ziņojumi tiek reģistrēti, izanalizēti un izskatīti izmaiņu vadības padomē un par katru no tiem tiek pieņemts attiecīgs lēmums (piemēram, precizēt, noraidīt, realizēt nākamajā versijā utt.). Šādu problēmziņojumu un izmaiņu pieprasījumu var būt pietiekami daudz, tāpēc bieži šis darbs tiek automatizēts ar speciālu programmu palīdzību. Kvalitātes nodrošināšana Ja runa ir par nopietnu projektu realizāciju (īpaši to, kuri ir saistīti ar informācijas sistēmu izstrādi un ieviešanu), kvalitātes pārvaldība ir viena no būtiskākajām aktivitātēm visā projekta dzīves ciklā. Kvalitātes pārvaldības galvenais uzdevums ir nodrošināt visu projekta norisē iesaistīto un gala rezultātā ieinteresēto pušu (esošo un potenciālo) prasību un vajadzību apmierināšanu. Kvalitātes jautājumu pārraudzīšanu konkrētā projektā parasti nodrošina speciāli nozīmēts cilvēks – projekta kvalitātes pārvaldnieks. Pirmais faktors kvalitatīva rezultāta nodrošināšanā ir sakārtots un kvalitatīvs pats darba process. Par standartiem, atbilstoši kuriem jāorganizē darbs, jau tika stāstīts. Iesaistot darbu veikšanā vai preču piegādē citas organizācijas, jābūt pārliecībai, ka arī šo organizāciju darba procesi ir sakārtoti. Mērķtiecīgi ir orientēties uz tiem pakalpojumu sniedzējiem un preču piegādātājiem, kuriem ir ISO9000 sertifikāts. Kā otrs faktors noteikti jāmin precīzs prasību un izmaiņu pieprasījumu pārvaldības darbs, kā arī konfigurācijas pārvaldības darbs. Praktiski tas nozīmē lietotāja prasību 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 vienumu precīzu uzskaiti, versiju kontroli utt. Trešais ļoti nozīmīgs kvalitātes nodrošināšanas faktors IS izstrādes projektos ir programmatūras testēšana. Tiek praktizēta dažādu veidu testēšana – autortestēšana, sistēmanalītiskā testēšana, vienību testēšana, integrācijas testēšana, kvalifikācijas testēšana u.c. Ceturtais faktors kvalitātes nodrošināšanā ir regulārie gan iekšējie, gan ārējie auditi, projekta apskates un citas vadīklas (controls) (atbilstoši ISO9000 terminoloģijai), kas nodrošina objektīvu informāciju par to, kādā mērā reālā situācija atbilst projekta mērķiem, lietotāja prasībām, standartiem un citiem reglamentējošiem dokumentiem. Īsas pamācības IS projektu veidošanā Apzinoties, ka šī tēma nav aptverama viena raksta ietvaros, nobeigumā dažas atziņas, kas varētu noderēt praktiskajā darbībā. 1. Nebūvējiet debesskrāpi, paļaujoties tikai uz amatnieku zelta rokām, jo nopietnu informācijas sistēmu izstrāde prasa industriālu pieeju un standartu izmantošanu. 2. Pirms uzsākat darbu pie IS projekta, tieciet skaidrībā par mērķiem, ko gribat sasniegt, un cik jūs esat gatavi investēt to sasniegšanā. 3. Brīnumu pasaulē nav, tāpēc nevajag cerēt, ka rezultāti būs uzreiz, neprasot piepūli. 4. Sistēmas tiek izstrādātas lietotājam, tāpēc viņam arī jābūt sistēmas saimniekam. 5. Visa pamatā – prasības (cik labi būs definētas prasības, tik labs būs arī rezultāts). 6. Koncentrējieties uz projekta vadību un procesa organizēšanu, jo tehnisko kompetenci izdevīgāk ir iepirkt no ārpuses. 7. Tas, kas nav uzrakstīts, neeksistē, tāpēc izstrādes process un rezultāti ir jādokumentē. 8. Izmaiņas sistēmā ir normāli, galvenais ir tās kontrolēt. 9. Nelaidiet izstrādātājus pie sistēmas darbināšanas. 10. Divas svešas acis redz labāk nekā simt savējo (apskates un auditi nav tukša laika kavēšana). 11. Ja nekas cits nelīdz, izmantojiet savu pieredzi un veselo saprātu, jo nekas no jau teiktā nav dogma.

8.3. Programmatūras izstrādes projekta vadītāja piezīmes Programmatūras izstrādes projekta vadītāja piezīmes E-pasaule, Vita Karnīte. Lai cik plaši būtu pieejami pētījumi par projektu vadību, ikviens programmatūras izstrādes projekta vadītājs savulaik ir pionieris un pirmatklājējs vadīšanas praksē, līdz ar pieredzi krājot arī secinājumus un ieteikumus. Rakstā apkopotas vairāku programmatūras izstrādes projektu vadītāju populārākās atziņas. Kas ir projekts Projekts = termiņš + sasniedzamais rezultāts + budžets.Projekts ir uzdevums ar noteiktiem parametriem – sākuma un beigu datumi, sasniedzamais rezultāts, budžets. Projekta vadītājs = zināšanas + entuziasms + pieredze.

Projekta vadītājs ir cilvēks, kam jāsasniedz konkrēts rezultāts noteiktā laikā, izmantojot resursus, ko var atļauties saskaņā ar atvēlēto budžetu. Vadītājs var izmantot savas zināšanas un spējas, piesaistīt citu cilvēku zināšanas un spējas, kā arī izvēlēties palīglīdzekļus. Ja projekts tiek realizēts veiksmīgi, tā vadītājs var pamatoti lepoties ar pakāpienu savā karjerā, turklāt sevišķi augstu tiek vērtēti tie vadītāji, kuri izveduši projektu no krīzes situācijas. Projektam ciešot neveiksmi, atbildība pilnībā jāuzņemas vadītājam. Ar projektu realizāciju savas dzīves laikā sastopas ikviens cilvēks, un patstāvīgi cilvēki ar laiku pierod arī sadzīvē domāt projektu vadības kategorijās – izvirza konkrētus mērķus, nosaka laiku, rēķinās ar konkrētiem līdzekļiem. Filozofiski uz to skatoties, visa cilvēka dzīve ir kā liels projekts ar daudziem apakšprojektiem, kas laika gaitā kļūst arvien sarežģītāki, piemēram: • skolā – kontroldarbs matemātikā jāuzraksta 45 minūtē, un atbildei jāsakrīt ar skolotāja rīcībā esošo; • augstskolā – programmēšanas kursam paredzēti trīs mēneši, atzīmei jābūt >8, budžetu veido stipendija un studiju kredīts; • darbā – programmatūras izstrādes termiņš ir divi gadi, tiek izstrādāta un ieviesta norēķinu sistēma, budžets – Ls 600 000. Vadība Prakse liecina, ka 80% no veicamā uzdevuma prasa 50% tam atvēlētā laika. Ja 80% no uzdevuma ir izdarīti 80% no atvēlētā laika, ļoti iespējams, ka termiņš tiks nokavēts. Plašāk pazīstamas un praksē arvien pārbaudītas sakarības, ar kurām vadītājs var rēķināties, ir tā sauktās sakarības 80:20, piemēram: • 80% labumu var nodrošināt ar 20% no prasību realizācijas, • 20% profesionālāko programmētāju rada 80% koda, • 20% vājāko programmētāju rada 80% no atklātajām kļūdām. Ja vadītājs nevar atbildēt uz kādu projekta īstenošanā radušos jautājumu, tad viņam jāzina, kā šo atbildi rast. Vadītājam jāspēj pieņemt jebkuru ar projektu saistītu lēmumu vai nu pašam, vai deleģējot lēmuma pieņemšanu speciālistam (piemēram, vai datu bāzei piekļūt ar ODBC vai OLE DB). Jebkurā gadījumā vadītājs ir atbildīgs par lēmuma sekām. Vadītājam, kas pats nav programmējis, ir ievērojami grūtāk vadīt programmatūras izstrādes projektu nekā cilvēkam, kas karjeru ir sācis kā programmētājs. Labi, ka projektā ir galvenais speciālists, kas pārzina tehnoloģisko pusi un spēj pieņemt lēmumus, taču šādos gadījumos pastāv projekta dubultās vadības risks un vadītājam jābūt gatavam strādāt arī tādos apstākļos. Ja projekta gaitā rodas problēma, vadītājam jādomā par tās atrisināšanu – viņam jāzina, kā mainīt sistēmu, lai šādas problēmas vairs nerastos, un jāspēj mainīt sistēmu. Vadītājam ir jāzina un arī jājūt vietas, kuras varēs precizēt programmatūras izstrādes gaitā. Nav vērts censties izstrādāt 100% atbilstošu projektējumu, jo praktiski nav tādu projektu, kurus praksē izdotos pilnībā izstrādāt pēc ūdenskrituma modeļa. Jo vairāk problēmu iespējams atrisināt sarunājoties, jo profesionālāks ir vadītājs. Un otrādi – jo profesionālāks ir vadītājs, jo vairāk jautājumu var nokārtot sarunu ceļā. Pasūtītājs Ja vien tas ir iespējams, piedāvājums un cenu aprēķins jāiesniedz pasūtītājam 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 izveidots pamats ilgstošai sadarbībai, var atļauties daļu problēmu risināt pa e-pastu vai telefonu. Paralēli formālajiem pasākumiem (piemēram, izmaiņu vadības padomes), svarīgi “uztaustīt” pasūtītāja procesus pārzinošu cilvēku vai cilvēkus, kam var uzdot jautājumus par dažādām situācijām. Ideāli, ja šis cilvēks ir arī oficiālā kontaktpersona par attiecīgajiem jautājumiem, jo var teikt, ka projekta panākumi ir proporcionāli tam, cik veiksmīgi izveidojas sadarbība ar šo cilvēku vai cilvēkiem. Pēc iespējas ātrāk vajag vizuāli parādīt pasūtītājam iespējamo rezultātu, sākotnēji kaut vai sarunas laikā to uzskicējot uz papīra. Mūsdienu rīki ļauj ātri un viegli uzzīmēt ekrānformas, pirms uzsāk programmēt. Deleģēšana Jāprot prognozēt darbinieka spēju veikt uzdevumu. Ja darbinieka spējas nav zināmas, tad, deleģējot tam uzdevumu, sākotnēji jāpieņem, ka darbinieks nepārzina konkrēto jomu, un uzdevums sīki un smalki jāizstāsta. Jāpārliecinās arī par deleģētā uzdevuma izpildi. Efektīvākais veids, kā pārliecināties, vai darbinieks sapratis uzdevumu, ir palūgt viņam atstāstīt, kā viņš to ir sapratis. Secinājumi Projektu vadība ir vairāku zinātņu apvienojums, un, izstrādājot programmatūras projektus, tās ir – datorzinātne, vadība, psiholoģija, ekonomika. Mūsdienās ģeniāli atklājumi visvairāk tiek izdarīti kombinētajās zinātnēs, piemēram, klasiskajā matemātikā jaunu un ģeniālu atklājumu ir maz, toties, apvienojot matemātiku ar fiziku un ķīmiju, tika radīti pirmie kvantu datori. Programmatūras izstrādes projektu vadība ir formalizēta pieeja apvienojumā ar mākslu, un speciālisti visā pasaulē strādā, lai šajā jomā procentuāli palielinātu formalizēto pieeju un samazinātu māksliniecisko. Pašlaik šī procentuālā attiecība programmatūras izstrādes projektu vadības praksē, manuprāt, ir 50 pret 50. Kamēr tā nav būtiski mainījusies, tikmēr labs programmatūras izstrādes projektu vadītājs joprojām būs datorspeciālists, psihologs, ekonomists un nedaudz arī burvju mākslinieks.

8.4. Efektīvas projekta komandas kontrolsaraksts Efektīvas projekta komandas kontrolsaraksts (no http://www.rspa.com/checklists/teams.html) The intent of this checklist is to assess the degree to which a software project team will work together effectively (SEPA 5/e, Chapter 3). It should be noted that many factors affect the qualty of a team. However, the following issues should be addressed by the project manager/team leader as the team is formed. For this checklist, the more questions that elicit a negative response, the higher the risk that the team will fail. Has the team worked together before? If so, were the results of past working experience favorable? Do members of the team have the correct mix of knowledge, training, and experience for the job to be done? Do members of the team come from the same technical "culture"? the same organization? Have the roles and responsibilities of each team member been clearly defined?

Have communication mechanisms for the team and with the outside world been clearly defined? Do the team members have respect for the project manager? the team technical leader? Is the working environment (e.g., offices, meeting rooms, tools) conducive tgood teamwork? Have team members been shielded from administrative record keeping? Have team members been provided with appropriate support staff?

9.1. Konspekts Tehniskā realizācija - centralizēts vai decentralizēts risinājums? 1. Nofiksētas: - funkcionālās prasības - nefunkcionālās prasības 2. Novērtēta ekonomiskā efektivitāte (parasti ekonomiskā efekta (tiešā) nav). Mēdz spiest konkurence. 3. Pieņemts lēmums par izstrādi. 4. Jāsāk izstrāde. Homogēnas un heterogēnas sistēmas Homogēna sistēma - ja ir viena un tā pati datu bāžu pārvaldības sistēma (DBPS) (sk. 1.attēls pa labi) Heterogēna sistēma - ja dažādas DBPS (sk. 1.attēls pa kreisi)

1. attēls. Homogēnās un heterogēnas sistēmas piemēri. Heterogēnu sistēmu galvenā problēma - savstarpēja integrācija. Centralizētas un decentralizētas sistēmas Centralizētas sistēmas - pamatā ir tikai viena datu bāze (sk. 2.attēls pa kreisi). Decentralizēta sistēma - sastāv no vairākām datu bāzēm (sk. 2.attēls pa labi).

2.attēls. Centralizētas un decentralizētas sistēmas Piemēri: CSDD - centralizēta DB (kaut arī izvietota divās vietās - pašvaldībās reģistrē dzīves vietas, bet tās netiek pie centrālās DB). LUIS - centralizēta sistēma. Audzēkņu reģistrs (skolās) - decentralizēta sistēma (skolās - Lotus Notes, centrā - ORACLE). Ģimenes ārsti - decentralizēta sistēma (MS SQL centrā, 7 slimokases, ārstniecības iestādes). Ja nav ātra interneta pieslēguma, tad gandrīz noteikti jātaisa decentralizēta sistēma. Arī gadījumos, kad dažādos līmeņos funkcijas būtiski atšķiras, decentralizēts risinājums ir piemērotāks. + –

Centralizētas sistēmas

vienkārša lietotājam, konfigurācijas vadība, konfidencialitāte, integritāte, izstrādes izmaksas

veiktspēja, izmaksas DB, pieejamība

Decentralizētas sistēmas pieejamība (drošības komponente)

konfidencialitāte integritāte izstrādes izmaksas

Ieskats vēsturē

3.attēls. Lieldatoru ēra (1980). Pēc lieldatoru ēras atnāca personālie datori - un tos ātri akceptēja, jo katrs dabūja savu datoru. Bet ātri vien sākās integrācijas problēmas, jo, piemēram, 3 grāmatvežiem bija jāapmainās ar datiem. Pēc tam izgudroja LAN tīklus, kas radīja sinhronizācijas problēmu.

4.attēls. LAN struktūra. Fox programmas, lai taisītu kopsavilkumus, visi dati bija jādabū vienoti, "jāpumpē" caur tīklu. Pēc tam parādījās klient-servera arhitektūra - pamatrēķini notiek uz servera, bet pa tīklu ceļo tikai pieprasījumi un rezultāti. Tātad esam loģiski turpat, pie lieldatoriska risinājuma. Rodas konflikti starp operatīviem pieprasījumiem un pieprasījumiem, kuru izpildei nepieciešami lieli resursi (piemēram, pilna pārbūve)

10.1. Konspekts Informācijas sistēmu drošība. Informācijas kodēšana Drošība → pieejamība (avalability) + integritāte (integrity) + konfidencialitāte (confidentiality) (saskaņā ar LVS, ISO standartiem un MK noteikumiem) Pieejamība - sistēmu var lietot tad, kad tas nepieciešams (tikai pilnvaroti lietotāji). Integritāte - iekšējā nepretrunība, informācijas pilnība un precizitāte. Konfidencialitāte - netiek klāt tie, kam tas nav paredzēts. Vai ir iespējama absolūti droša sistēma? Izstrādājot sistēmu, jāizvērtē informācija, cik lielā mērā tā ir jāaizsargā.

- publiska informācija - ierobežotas pieejamības informācija (ja draud ar morāliem vai ekonomiskiem zaudējumiem) - slepena informācija (saskaņā ar likumu) - sevišķi slepena informācija (datoru nedrīkst pievienot tīklam) Pieejamība atkarīga no - aparatūras un tīkla kvalitātes - programmatūras kvalitātes - rezervēšana (arī - kopēšana) - serveru klasteri (arī - spoguļošana) - dublēšana (aparātiska) - karstā rezerve - aukstā rezerve - u.c. Integritāte atkarīga no - programmatūras kvalitātes Sliktākais piemērs ar FOX, kas glabā indeksus operatīvajā atmiņā; izslēdzot un ieslēdzot datoru, viss nojūk un ir vai nu jāpārindeksē, vai arī jāatjauno no rezerves kopijām. Labs piemērs - ar WORD, kas glabā faila atvērtības pazīmi uz diska. Konfidencialitātes pārvarēšana - dabūt pieteikuma (login) vārdu, PIN kodu. Divdaļīgas paroles - maināmā publiskā daļa un nemaināma slepenā. Laba prakse - visas darbības uzglabāt auditācijas pierakstos (audit trial) nemaināmā protokola datnē - žurnālā (log) Visa informācija var tikt noklausīta pārraidot - informācija jāšifrē. Šifrēšanas atslēgas garums nepieciešams arvien garāks. Agrāk šifrētos datus pēc laika varēja viegli atšifrēt, mainīt un aizšifrēt atpakaļ. Laba risinājuma nav. Informācijas kodēšana Ieviesa personkodus. Kā izvēlas kodus? a) visus objektus sanumurē - kods ļoti racionāls, bet to grūti lietot; b) pozicionālie kodi - objektus sadala sanumurētās grupās, piešķir numurus grupas iekšienē (piemēram, studentu liecības DatZ 01 0017). b' ) domēnspecifiskie kodi, kas vēsturiski izveidojušies nozarē c) lietotāja saskarnei jābūt "draudzīgai" - krāsas, izvietojums, u.tml. - uzskatāmi kodi, kas ir mnemoniski Izvēlnē piedāvā mnemoniskos kodus, bet sistēmas iekšienē lieto kodifikatora esošo, kas parasti ir garš un cilvēkam neuztverams. ER realizācijas modelī parādās kodifikatoru kodi.

11.1. Konspekts Programmatūras prasību pamati (The Essential Software Requirements) Izmantotie materiāli: Karl E. Wieger. “Software Requirements” – Microsoft Press, 1999, lpp. 350 Lekcijas plāns Programmatūras prasību definīcijas Prasību līmeņi Darījumprasības (business requirements) Lietotāja prasības Funkcionālās prasības Nefunkcionālās prasības Kvalitātes atribūti ierobežojumi Biežākie neadekvāta prasību procesa rīki Piemērs MARIJA: „Sveiks, Fil! Šeit Marija no Personāla nodaļas. Mums ir radusies problēma ar darbinieku sistēmu, kuru tu mums esi programmējis. Viena no darbiniecēm ir tikko mainījusi uzvārdu uz Startailts, savukārt sistēma neatļauj šo izmaiņu. Vai tu mums palīdzēsi?” FILS: „Viņa ir apprecējusies ar Startailtu?” MARIJA: „Nē, viņa nav apprecējusies, viņa vienkārši ir mainījusi savu uzvārdu,” atbild Marija. „Tā jau arī ir tā problēma. Izskatās, ka mēs varam nomainīt uzvārdu tikai tad, ja mainās cilvēka ģimenes stāvoklis”. FILS: „Nu, jā. Es nekad neesmu iedomājies, ka kāds varētu mainīt tāpat vien savu vārdu vai uzvārdu. Es neatceros, ka jūs man būtu par to kaut ko teikusi, kad mēs runājām par sistēmas funkcijām. Tieši tāpēc jūs arī nevarat tagad izsaukt logu „Uzvārda, vārda maiņa” bez ģimenes stāvokļa maiņas,” saka Fils. MARIJA: „Es domāju, ka tu zini, ka cilvēkiem ar likumu ir atļauts mainīt vārdu un uzvārdu, kad viņi to vien vēlas. Lai nu kā, mums ar šo problēmu ir jātiek galā līdz nākamai nedēļai, vai arī grāmatvedei nebūs iespējas aprēķināt viņas algu. Vai tu vari izlabot šo kļūdu?” FILS: „Tā nav kļūda! Es nekad neesmu biju informēts par to, ka šāda iespēja ir vajadzīga. Es esmu aizņemts jaunas veiktspējas aprēķina sistēmas izstrādē. Cita starpā, man ir uzkrājušās arī citas izmaiņu prasības attiecībā uz darbinieku sistēmu... Jā, lūk, te ir vēl viena. Es tās abas varētu atrisināt līdz mēneša beigām, bet noteikti ne šonedēļ. Ļoti atvainojos. Nākamreiz, lūdzu, brīdiniet mani par šādām lietām agrāk un, lūdzu, dariet to rakstveidā”. MARIJA: „Ko man teikt grāmatvedei? Viņa kļūs patiesi dusmīga, ja nebūs iespējas aprēķināt šīs darbinieces algu.” FILS: „Marija, tā taču nav mana kļūda!” – protestē Fils. „Ja jūs man būtu no paša sākuma pateikusi, ka darbiniekiem jāvar mainīt uzvārdu un vārdu jebkurā laikā, tas pat nebūtu noticis. Jūs nevarat mani apvainot par nespēju lasīt jūsu domas”.. MARIJA, dusmīgi un neapmierināti – „Jā, nu labi, šī ir no tām lietām, kuras liek man ienīst datorsistēmas. Piezvani man, tiklīdz problēma būs novērsta”.

Ja kaut reizi esat pabijuši šīs sarunas klienta pusē, jūs zināsiet cik tas ir nepatīkami - lietot programmatūru, kas neļauj jums pildīt pamatfunkcijas. Jūs noteikti nebūtu arī apmierināti ar izstrādātāju, kurš atliek jūsu izmaiņu izpildi uz vēlāku laiku. No izstrādātāja puses, jūs zināt, cik nepatīkami ir pēkšņi pēc sistēmas ieviešanas atklāt trūkstošu funkcionalitāti, kuru lietotājs ir gaidījis. Tas ir arī nepatīkami, ja jūs traucē tādu izmaiņu pieprasījuma dēļ, kas izmaina sistēmu, kura strādā precīzi tā, kā to ir aprakstījis lietotājs. Daudzas programmatūras izstrādes problēmas ir izskaidrojamas ar trūkumiem prasību vākšanas, dokumentēšanas procesos un pieredzē. Runājot par Filu un Mariju, viņu problēma ir neoficiālas informācijas vākšana, nefiksēta vai šaubīga funkcionalitāte, neatklāti vai nepateikti pieņēmumi, neadekvāta prasību dokumentēšana un nejaušs izmaiņu procesa raksturs. Programmatūras prasību definēšana Viena no programminženierijas problēmām ir vienkāršu definīciju trūkums tiem terminiem, kurus mēs izmantojam mūsu darba aspektu aprakstam. Pasūtītāja "prasību" definīcija izstrādātājam izklausās pēc augstākā līmeņa koncepcijas. Savukārt izstrādātāja priekšstats par prasībām lietotājam var izklausīties pēc detalizēta projektējuma. Šīs ir dažādas perspektīvas un mainīgi precizitātes un detaļu līmeņi. IEEE Standard Glossary of Software Engineering Terminology (1997) definē prasības kā: (1) Nosacījums vai spēja, kura nepieciešama lietotājam problēmas risināšanai vai mērķu sasniegšanai. (2) Nosacījums vai spēja, kura var piemist sistēmai vai sistēmas komponentei, lai izpildītu līgumu, standartu, specifikāciju vai citu formāli obligātu dokumentu. (3) Dokumentēta (1) vai (2) formulēto nosacījumu vai spēju reprezentācija. Dažas „prasību” interpretācijas IEEE definīcija pārklāj gan lietotāja skatu uz prasībām (ārējo sistēmas uzvedību), gan izstrādātāja priekšstatu par to. Atslēgas koncepcija ietver sevī nepieciešamību dokumentēt prasības. Autors piedalījās vienā projektā, kurā iesaistītie programmētāji mainījās. Pasūtītājs bija novests līdz asarām katru reizi, kad jaunais prasību analītiķis nāca un sludināja „Mums ir jāaprunājas par prasībām”. Pasūtītāja reakcija uz to bija „Es jau esmu jūsu priekštečiem visu izstāstījis. Uztaisiet man sistēmu !” Bet realitātē prasības netika dokumentētas, līdz ar to katrs analītiķis visu sāka no pamatiem. Sludināt, ka jums ir uzkrātas „prasības”, ir pašapmāns, ja viss, kas jums ir – ir daži e-pasti un balss pasta ziņojumi, "post-it" lapiņas, sapulces protokoli un miglainas priekšnama sarunu atmiņas. Cita definīcija saka, ka prasības ir „lietotāja vajadzību konstatējums, kurš izraisa programmas vai sistēmas izstrādi” (Jones 1994). Prasību specificēšanas autoritāte Alans Daviss (1993) paplašina šo koncepciju līdz „lietotāju vajadzības vai nepieciešamas sistēmas pazīmes, funkcijas vai atribūti, kuras var just no ārpus

sistēmas pozīcijas”. Šīs definīcijas uzsver, ko produkts ietvers, nevis kā produkts tiks uzprojektēts un konstruēts. Nākamā definīcija iet dziļāk no lietotāju vajadzību spektra līdz sistēmas raksturīpašībām (Sommerville un Sawyer 1997): Prasības ir... specifikācija, kurā ir teikts kas ir jāievieš. Tie ir apraksti kā sistēmai ir jāuzvedas, kādas ir sistēmas īpašības un atribūti. Tās var kalpot arī kā ierobežojums sistēmas izstrādes procesā. Šīs atšķirīgās definīcijas norāda uz termina „prasības” neskaidrību un nepārprotamas izpratnes trūkumu. Īstas prasības patiesībā atrodas cilvēku galvās. Jebkura prasību dokumentēta forma (kā, piemēram, prasību specifikācija) ir tikai modelis vai reprezentācija (Lawrence 1998). Mums nepieciešams pārliecināties, ka visām projektā ieinteresētām pusēm ir līdzīga terminu izpratne, aprakstot prasības. Prasību līmeņi Formulēsim definīcijas, kas apraksta dažus ar prasību inženieriju saistītus terminus. Programmatūras prasības ietver trīs skaidrus līmeņus – darījumprasības, lietotāju prasības un funkcionālās prasības – kā arī dažādas nefunkcionālas prasības. Darījumprasības ir augstāka līmeņa organizācijas vai pasūtītāja mērķu reprezentācija, kuru realizāciju paredz sistēma. Šīs prasības tiek uzkrātas speciālā projekta vīzijas vai aptvēruma (scope) dokumentā. Lietotāju prasības apraksta lietotājiem nepieciešamus uzdevumus, kuri ir jārealizē sistēmā. Tās tiek ietvertas lietošanas piemēru vai scenāriju aprakstos. Funkcionālas prasības definē programmatūras funkcionalitāti, kura izstrādātājiem ir jārealizē, lai lietotāji varētu pildīt savus uzdevumus, turklāt apmierinot darījumprasības. Iezīme (feature) ir loģiski saistīto funkcionālo prasību kopa, kura nodrošina lietotājam iespēju un apmierina darījumprasības. 1. attēls parāda dažas no šīm komponentēm.

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 (Software Requirements Specification – SRS), kas pēc iespējas precīzāk un pilnīgāk apraksta sagaidāmo ārējo sistēmas uzvedību. PPS tiek izmantota izstrādē, testēšanā, kvalitātes nodrošināšanā, projekta pārvaldībā un saistītajās projekta funkcijās. Sarežģītam programmproduktam programmatūras funkcionālām prasībām jābūt sistēmas prasību apakškopai, ja tādas ir. Papildus funkcionālām prasībām, kas apraksta sistēmas uzvedību un tās veicamās operācijas, PPS satur arī nefunkcionālās prasības. Tām jāsatur standarti, noteikumi un vienošanās, kurām produktam ir jāatbilst, kā arī ārējo saskarņu aprakstus, veiktspējas prasības, projektējuma un ieviešanas noteikumus un kvalitātes atribūtus. Ierobežojumi tiek doti izstrādātājiem tad, kad sistēmas konstrukcijā iespējami varianti. Kvalitātes atribūti paplašina produkta funkcionalitātes aprakstu, papildinot to ar produkta raksturiezīmēm, kuras ir svarīgas lietotājiem vai izstrādātājiem. Dažādu prasību piemērs. Izstrādājamā sistēma – teksta redaktors.Darījumprasības varētu skanēt šādi - „Lietotājiem jābūt iespējai efektīvi izlabot dokumenta pareizrakstības kļūdas”. Gramatisko kļūdu labotājs varētu būt iezīme (feature), kura tiek iestrādāta programmā un kura apmierina darījumprasības. Sekojot lietotāju prasībām, prasības var tikt papildinātas ar šādu apgalvojumu (lietošanas piemēru): „Atrast dokumentā pareizrakstības kļūdas un izlemt, vai jāveic katras pārrakstīšanās aizvietošana ar vienu no piedāvātiem pareiziem variantiem”. Gramatisko kļūdu labotājam var būt daudz individuālo funkcionālo prasību, kuras nosaka operācijas, kā, piemēram, nepareizo vārdu meklēšana un izcelšana, piedāvāto pareizo variantu attēlošana un vispārējas aizvietošanas veikšana. Vadībai vai tirgvedības speciālistiem ir jādefinē programmatūras darījumprasības, kuras palīdzēs viņu organizācijai strādāt efektīvāk (informācijas sistēmām) vai veiksmīgi iekarot tirgu (komerciāliem programmatūras produktiem). Visām lietotāju prasībām ir jābūt saskaņotām ar darījumprasībām. Lietotāju prasības ļauj prasību analītiķim izsecināt lietotāju uzdevumu izpildei nepieciešamo funkcionalitāti. Izstrādātāji lieto funkcionālās prasības risinājumu projektēšanā un izstrādē, līdz ar to ieviešot nepieciešamo funkcionalitāti. Ievērojiet, ka prasības atbilstoši šīm definīcijām nesatur projektējuma un implementēšanas detaļas, projekta plānošanas vai testēšanas informāciju. Šiem aprakstiem jābūt atdalītiem no prasībām, lai prasību aktivitātes varētu koncentrēties uz izstrādājamās sistēmas izzināšanu. Projektos var gadīties arī citu veidu prasības, kā, piemēram, izstrādes vides prasības vai prasības pret produkta versiju attīstību. Kad sliktas prasības gadās ar labiem cilvēkiem Projekta komandas, kuras nevērīgi izturas pret prasību procesiem, apdraud pašas sevi. Nepilnības prasību inženierijā velk aiz sevis virkni risku, kuri apdraud projekta veiksmi, kur „veiksme” var būt definēta kā tāda produkta piegāde, kurš apmierina lietotāju ieceres par tā funkcionalitāti un kvalitāti, pie tam savlaicīgi un par norunāto cenu. Daži no šiem riskiem ir aprakstīti zemāk. No neatbilstoša prasību procesa izrietošie riski. 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 kvalitātes pazemināšanu. Neskaidras prasības noved līdz neefektīvi izmantotam laikam un pārstrādei. Pārāk liela slīpēšana un izskaistināšana no izstrādātāju un lietotāju puses pievieno produktam nevajadzīgas iezīmes. Minimālas prasības noved līdz svarīgu prasību trūkumam. Noteiktu lietotāju grupu prasību izlaišana rada pasūtītāju neapmierinātību. Nepilnīgi definētas prasības padara neiespējamu projekta precīzu plānošanu un izsekošanu.

12.1. Konspekts Programmatūras prasību pamati (The Essential Software Requirements) Izmantotie materiāli: Karl E. Wieger. “Software Requirements” – Microsoft Press, 1999, lpp. 15-35 Lekcijas plāns Teicamu prasību raksturojums Prasību specifikācijas raksturojums Prasību izstrāde un pārvaldība Prasības no pasūtītāja perspektīvas Kas ir pasūtītājs? Programmatūras pasūtītāju tiesības Programmatūras pasūtītāju pienākumi Kādas saistības izriet no prasību specifikācijas parakstīšanas? Teicamu prasību raksturojums Kādā veidā var atšķirt labas programmatūras prasību specifikācijas (PPS; angliski - Software Requirements Specification, SRS) no problemātiskām? Uzmanīga PPS apskate (review) no projektā iesaistītām pusēm, reprezentējot dažādus skatupunktus, ir labākais veids, lai pārbaudītu, vai prasības atbilst visiem nepieciešamiem raksturlielumiem. Ja, formulējot un apskatot prasības, patur prātā zemāk uzskaitītos raksturlielumus (characteristics), parasti izdodas uzlabot prasību dokumentus un izstrādāt labākus programmproduktus. Prasību pārskata raksturlielumi · Pabeigtība (Complete) Katrai prasībai ir pilnīgi jāapraksta piegādājamā funkcionalitāte. Tai jāsatur visu nepieciešamu informāciju, lai izstrādātājs varētu šo funkcionalitāti uzprojektēt un implementēt. · Pareizība (Correct) Katrai prasībai ir rūpīgi jāapraksta iestrādājamā funkcionalitāte. Pareizības etalons ir prasību avots, kā, piemēram, pasūtītāja vai augstāka līmeņa sistēmas prasību specifikācija. Programmatūras prasība, kas ir pretrunā ar atbilstošo sistēmas prasību,

ir nepareiza. Tikai lietotāju pārstāvji var novērtēt lietotāju prasību pareizību, tieši šī iemesla dēļ ir ļoti svarīgi iesaistīt gala lietotājus prasību apskatēs. Prasību apskatēs, kurās nepiedalās lietotāji, iesaistītie dalībnieki var prātot - „Tas nav saprotams, bet laikam jau ir tas, ko viņi gribēja”. Tā ir minēšana uz labu laimi. · Iespējamība (Feasible) Ir jābūt drošai iespējai katru prasību implementēt iecerētajā sistēmā un tās vidē, ņemot vērā noteiktos ierobežojumus. Lai izvairītos no neiespējamām prasībām, prasību vākšanas procesā ieteicams iesaistīt papildus tirgvedības vai prasību analītiķim arī programmatūras izstrādes komandas dalībnieku. Šis cilvēks var nodrošināt iespējamības pārbaudi – ko var un ko nevar tehniski realizēt, kā arī kuru prasību implementācija prasīs pārmērīgi lielus laika un materiālos resursus. · Nepieciešamība (Necessary) Katrai prasībai ir jādokumentē kaut kas lietotājam tiešām vajadzīgs vai arī kaut kas, kas ir nepieciešams ārējo sistēmu prasību vai standartu atbilstībai. Prasības rodas no zināmiem avotiem, daži no tiem ir ar lielāku autoritāti. Prasības atkārtoti jāsalīdzina ar informāciju no citiem avotiem, piemēram, no vairākiem lietošanas piemēriem (use case). · Prioritizējamība (Prioritized) Visas prasības, funkcionalitātes un lietošanas piemēri jāsakārto pa prioritātēm, lai novērtētu, cik svarīga ir šo prasību realizācija dotajā izstrādes versijā. Ja visām prasībām tiktu noteikta vienādi augsta prioritāte, projekta pārvaldniekam trūks brīvības, reaģējot uz jaunām prasībām, kuras nāks klāt izstrādes laikā, kā arī uz budžeta samazinājumu, laika pārtēriņu vai projekta personāla pietrūkumu. · Skaidrība (Unambiguous) Visiem prasību dokumenta lasītājiem ir jāvienojas par vienotu, konsekventu to interpretāciju. Dažreiz izteikumu izvēle var novest pie divdomības, tāpēc prasības ir svarīgi izklāstīt vienkāršā, kodolīgā valodā, kuru saprot lietotāji, nevis tikai datorspeciālisti. Jāievieš prasību dokumentu apskates procedūra, rakstot testa piemērus, izstrādājot prototipus un izgudrojot specifiskus izmantošanas scenārijus, lai efektīvi panāktu izteiksmes vienkāršību. · Verificējamība jeb pārbaudāmība (Verifiable) Jāizpēta visas prasības, lai redzētu, vai ir iespējas pārbaudīt to pareizību pēc produkta ieviešanas, veicot nelielu testu skaitu vai ar citu pārbaudes pieeju palīdzību, kā, piemēram, apskatēm vai demonstrāciju. Ja prasība ir nepārbaudāma, pierādīt to, ka tā ir pareizi iestrādāta, kļūst par viedokļa jautājumu un izslēdz objektīvu analīzi. Nepārbaudāmas ir arī pretrunīgās, nesaskanīgās, nepierādāmās vai neskaidrās prasības. Prasību specifikācijas raksturojums · Pabeigtība (Complete) Nedrīkst pietrūkt kādu prasību vai nepieciešamas informācijas. Trūkstošas prasības ir grūti pamanīt, jo tās ir neredzamas. Koncentrējoties uz lietotāju uzdevumiem vairāk nekā uz sistēmas funkcijām, var izvairīties no nepilnības. Ja zināms par noteiktas

informācijas trūkumu, jābūt apņēmībai šo trūkumu novēršanā vēl līdz konstruēšanas uzsākšanai. · Nepretrunība (Consistent) Neviena prasība nedrīkst nonākt pretrunā ar citām programmatūras vai augstāka līmeņa (sistēmas vai darījumu (business)) prasībām. Visām pretrunām starp prasībām ir jābūt atrisinātām pirms izstrādes procesa. Katras prasības pareizību var atklāt, tikai veicot mērķtiecīgu izpēti. · Maināmība (Modifiable) Ir jābūt iespējai pārskatīt PPS, ja tas ir nepieciešams, un uzturēt detalizētu prasību izmaiņu vēsturi. Tas prasa, lai katra prasība būtu unikāli apzīmēta (marķēta/numurēta) un atdalīta no citu prasību apraksta, lai uz to varētu viennozīmīgi un skaidri atsaukties. Katrai prasībai ir PPS jāparādās tikai vienu reizi, pretējā gadījumā, ieviešot izmaiņas, ir ļoti vienkārši pieļaut kļūdu, izmainot prasības tikai vienā vietā. PPS izmaiņu ieviešanu vienkāršos satura tabulas, indekss un šķērsatsauces. · Trasējamība (Traceable) Jābūt iespējai sasaistīt katru no programmatūras prasībām ar tās avotu un tās projektējuma elementiem, pirmkodu un testpiemēriem, kuri kalpo kā pārbaude prasību izpildes pareizībai. Trasējamas prasības ir unikāli apzīmētas (marķētas/numurētas) un ir izklāstītas strukturētā, „smalkgraudainā” veidā, pretēji neskaidrām, plašām rindkopām. Prasību izstrāde un pārvaldība Sajukums prasību terminoloģijā attiecas arī uz šīs disciplīnas nosaukumu. Daži autori sauc šo procesu „prasību inženierija” (requirements engineering), kamēr citi to sauc par prasību pārvaldību (requirements management). Mēs sadalīsim programmatūras prasību inženierijas procesus divās daļās – „prasību izstrāde” un „prasību pārvaldība”, kā ir parādīts 1. attēlā.

1.attēls. Hierarhiskā prasību inženierijas sfēras dekompozīcija. Prasību izstrāde var būt sīkāk sadalīta, ietverot prasību noskaidrošanu, analīzi, specificēšanu un pārbaudi. Šie apakšprocesi aptver visas aktivitātes, kas saistītas ar programmatūras prasību vākšanu, novērtēšanu un dokumentēšanu. Prasību izstrādes aktivitātes ir šādas. Sagaidāmo programmprodukta lietotāju identificēšana un grupēšana Katras lietotāju grupas vajadzību noskaidrošana

Patieso lietotāju uzdevumu un mērķu, kā arī darījumu (business) vajadzību šo uzdevumu veikšanai izzināšana No lietotājiem saņemtās informācijas analīze, atšķirot viņu uzdevumu vajadzības no funkcionālo prasību, darījumu noteikumu, kvalitātes atribūtu un ieteikto risinājumu viedokļa Sistēmas līmeņa prasību sadalīšana galvenajās apakšsistēmās un šo prasību piekārtošana katrai no programmatūras komponentēm Kvalitātes atribūtu svarīguma saprašana Implementēšanas prioritāšu apspriešana Ievākto lietotāju vajadzību pārvēršana rakstītajās specifikācijās un modeļos Prasību specifikāciju apskates ar mērķi pārliecināties, ka visas prasības tikušas pareizi saprastas un uzskaitītas, un izlabot visas problēmas pirms izstrādes uzsākšanas. Prasību pārvaldība nozīmē „nodibināt un uzturēt vienošanos ar pasūtītāju par programmatūras projekta prasībām”. Šī vienošanās tiek „iemiesota” rakstītajās prasību specifikācijas un modeļos. Pasūtītāja piekrišana ir tikai puse no prasību apstiprināšanas "vienādojuma". Izstrādātājiem arī tās ir jāapstiprina un jāiestrādā programmproduktā. Visbiežāk prasību pārvaldība ietver šādas aktivitātes. Prasību vadlīniju definēšana Ierosināto prasību izmaiņu apskates un to ietekmes novērtēšana pirms katras noteiktas prasības apstiprināšanas Apstiprināto prasību izmaiņu iekļaušana un vadība Projekta plānu un prasību aktualitātes uzraudzība Jaunu saistību apspriešana, kuras izriet no prasību izmaiņu ietekmes novērtējuma Individuālo prasību trasēšana uz atbilstošo projektējumu, pirmkodu un testpiemēriem Prasību statusa un izmaiņu aktivitāšu izsekošana visa projekta garumā 2. attēls parā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. Prasības no pasūtītāja perspektīvas Piemērs Džerards, "Contoso Pharmaceuticas" vecākais pārvaldnieks tiekas ar Sintiju, "Contoso" informācijas sistēmas izstrādes grupas jauno pārvaldnieci. „Mums ir nepieciešams izstrādāt ķīmisko vielu izsekošanas informācijas sistēmu "Contoso" vajadzībām,” iesāk Džerards. „Sistēmai jāļauj mums uzkrāt datus par ķīmiskām vielām, kuras atrodas fondā vai konkrētās laboratorijās. Tādējādi ķīmiķi varētu iegūt to, kas viņiem nepieciešams, no fondā jau esošām vielām tā vietā, lai pirktu katru reizi jaunas. Veselības un drošības departamentam arī būtu jādod iespēja veidot dažus pārskatus federālai valdībai par ķīmisko vielu izmantošanu. Vai jūsu grupa var to realizēt piecos mēnešos, lai sistēma strādātu mūsu pirmā finansu audita laikā?” „Es saprotu, Džerard, kāpēc šis projekts ir tik svarīgs”, saka Sintija. „Bet pirms es varu kaut ko pateikt par termiņiem, mums ir jāveic prasību analīze jūsu sistēmai”. Džerards samulsis - „Ko jūs ar to gribat pateikt? Es esmu tikko jums visu izstāstījis”. „Patiesībā jūs esat aprakstījis koncepciju un dažus projekta mērķus”, paskaidro Sintija. „Šīs ir augstākā līmeņa darījumprasības, kuras nedod man pietiekami daudz detaļu, lai pateiktu, kādu programmatūru jums nepieciešams izstrādāt un cik ātri to varētu paveikt. Man nepieciešams vismaz pāris reizes satikties ar ķīmiķiem, lai saprastu viņu prasības pret sistēmu. Tad mēs varēsim izdomāt vajadzīgo funkcionalitāti, lai apmierinātu gan jūsu mērķus, gan lietotāju vajadzības. Varbūt jums nemaz nevajag jaunu sistēmu, lai ekonomētu naudu uz ķīmiskām vielām”. Džerards nekad nebija saskāries ar šādu reakciju no programmatūras izstrādes cilvēka. „Ķīmiķi ir aizņemti cilvēki," viņš protestē. „Viņiem nav laika izklāstīt jums katru detaļu, pirms jūs varēsiet sākt programmēt. Vai jūsu cilvēki nevar paši izdomāt, ko izstrādāt?” Sintija mēģina paskaidrot viņas nepieciešamību prasību vākšanai tieši no cilvēkiem, kuri izmantos jauno sistēmu: „Ja mēs pēc vislabākās apziņas minēsim, ko vajag lietotājiem, mēs nevaram paveikt labu darbu. Mēs esam programmatūras izstrādātāji, nevis ķīmiķi. Mēs īsti pat nezinām, ko ķīmiķiem vajag, lai atsekotu ķīmiskās vielas laboratorijās. Mūsu pieredze saka, ka, iesākot darbu pirms problēmas saprašanas, neviens nav apmierināts ar rezultātiem”. „Labi, mums tam visam nav laika,” uzstāj Džerards. „Es jums esmu iedevis prasības. Tagad, lūdzu, vienkārši izstrādājiet sistēmu. Un informējiet mani par projekta gaitu”. Šāda veida sarunas programmatūras izstrādes jomā notiek regulāri. Pasūtītāji, kas pieprasa jaunu informācijas sistēmu, bieži nesaprot gala lietotāju iesaistīšanas svarīgumu. Tirgvedības speciālisti ar brīnišķīgu jaunas sistēmas koncepciju var iedomāties, ka viņi ļoti labi reprezentēs pasūtītāja intereses. Diemžēl patieso gala lietotāju intervēšanai aizstājēja nav. Viens pētījums, kurā tika apskatīti 8380 projekti, atklāja, ka divi galvenie projektu neveiksmes iemesli ir lietotāju neiesaistīšana un nepilnīgas prasības un specifikācijas.

Daļa no problēmas, kas saistīta ar prasībām, ceļas no sajukuma, aprakstot dažāda līmeņa prasības: darījumprasības, lietotāju un funkcionālās prasības. Džerards izklāstīja dažas darījumprasības, bet viņš nevarēja aprakstīt lietotāja prasības, jo nav sistēmas potenciālais lietotājs. Patiesie lietotāji var aprakstīt uzdevumus, kurus viņiem būs jāpilda ar sistēmas palīdzību, bet viņi nevar identificēt visas specifiskas funkcionālās prasības, kuras ir jāievieš šo uzdevumu izpildei. Kas ir pasūtītājs? Plašā nozīmē pasūtītājs ir persona vai organizācija, kura iegūst tiešu vai netiešu labumu no produkta. Programmatūras pasūtītāji ir projektā ieinteresētas puses, kuras pasūta, maksā, izvēlas vai izmanto programmatūras produktu, vai kuri saņem rezultātus no produkta izmantošanas. Džerards reprezentē tādu pasūtītāju, kurš projektu iniciē un apmaksā. Džerarda līmeņa pasūtītāji ir atbildīgi par darījumprasību precizēšanu. Viņi nodrošina augstākā līmeņa koncepciju un ar darījumiem saistītā virziena uzdošanu. Kā jau bija aprakstīts, darījumprasības apraksta mērķus, kurus pasūtītājs, organizācija vai citas ieinteresētās puses grib sasniegt, vai arī vērtības, kuras viņi vēlas saņemt no sistēmas. Darījumprasības nodrošina vadošo uzbūvi visa projekta garumā. Visa pārējā informācija, kura tiek uzskatīta par prasībām, tiek saskaņota ar darījumprasībām, tāpat kā katra iestrādāta funkcionalitāte. Tomēr darījumprasības nenodrošina pietiekamu detalizāciju, lai izstrādātājs zinātu, ko veidot. Nākamais prasību līmenis – lietotāju prasības. Tām ir jābūt iegūtām no cilvēkiem, kuri izmantos produktu pašu rokām. Šie lietotāji (bieži saukti par gala lietotājiem) tādējādi veido citu programmatūras pasūtītāju veidu. Lietotāji apraksta uzdevumus, kurus viņi pildīs ar programmatūras palīdzību, kā arī nefunkcionālus raksturlielumus, kuri ir svarīgi, lai produktu akceptētu. Tie pasūtītāji, kuri nodrošina darījumprasības, dažreiz liecinās lietotāju vietā, bet visbiežāk viņi ir pārāk tālu no patiesiem izstrādātāju uzdevumiem, lai izklāstītu precīzas prasības. Informācijas sistēmas, līguma vai individuāla lietojuma izstrādē darījumprasībām ir jānāk no personām, kurām ir nauda, kamēr lietotāju prasībām ir jānāk no personām, kuras "spaidīs produkta pogas". Diemžēl abu pasūtītāju veidu pārstāvji var uzskatīt, ka viņiem nav laika strādāt ar prasību analītiķiem, kuri vāc, analizē un dokumentē prasības. Dažreiz pasūtītāji sagaida no analītiķiem vai izstrādātājiem izpratni par to, kas ir vajadzīgs lietotājiem, bez ilgām diskusijām un dokumentēšanas. Ja vien tas būtu tik vienkārši. Ja jpasūtītājam ir nopietna attieksme pret projekta veiksmi, ir jāsaprot, ka laiks, kad programmētājiem pa durvju spraugu tika piegādātas miglainas prasības un picas kastes, ir beidzies. Komerciālo sistēmu izstrāde (gatavo programmproduktu pārdošanai), kurā pasūtītājs ir reizē arī lietotājs, ir nedaudz atšķirīga. Pasūtītāju aizstājējs, kā, piemēram, tirgvedības departaments, var mēģināt noteikt, kādu programmatūras produktu pircējs vēlēsies iegādāties. Tomēr arī komerciālo sistēmu izstrādē ir jāiesaista patiesus lietotājus prasību vākšanas procesā.

Programmatūras pasūtītāju tiesības Pasūtītājam ir tiesības: 1. Sagaidīt, ka analītiķis runās pasūtītāja valodā. 2. Sagaidīt, ka analītiķi apgūs organizācijas darījumus un sistēmas mērķus. 3. Sagaidīt, ka analītiķis fiksēs prasību vākšanas procesa laikā iegūto informāciju programmatūras prasību specifikācijā. 4. Sagaidīt no izstrādātājiem izskaidrojumu par prasību vākšanas darba rezultātiem. 5. Sagaidīt no izstrādātājiem cieņu un profesionālu attieksmi pret sadarbību visas saskarsmes laikā. 6. Sagaidīt no izstrādātājiem idejas un alternatīvus risinājumus gan prasībām, gan to ieviešanai. 7. Sagaidīt programmprodukta īpašību raksturojumu, kurš padarīs tā lietošanu vieglu un patīkamu. 8. Sagaidīt iespēju pielāgot prasības turpmākai esošo programmatūras komponenšu atkalizmantošanai. 9. Būt nodrošinātiem prasību izmaiņu gadījumos ar godīgu izmaksu un ietekmes novērtējumu, kā arī kompromisiem. 10. Saņemt sistēmu, kura apmierina funkcionālas un kvalitātes vajadzības tādā līmenī, kādā tās bija izklāstītas un akceptētas. Programmatūras pasūtītāju pienākumi Pasūtītājam ir pienākums: 1. Izglītot analītiķus savā darījumu sfērā un definēt darījumu žargonu. 2. Pavadīt pietiekamu laiku prasību izklāstīšanai, precizēt prasības un atkārtoti atjaunināt tās. 3. Būt konkrētam un precīzam prasību izskaidrošanas laikā. 4. Savlaicīgi (ātri) pieņemt lēmumus par prasībām, ja tas ir nepieciešams. 5. Cienīt izstrādātāja prasību izmaksu un iespējamības novērtējumu. 6. Noteikt individuālo prasību, sistēmas funkcionalitāšu un lietošanas piemēru prioritātes. 7. Veikt prasību dokumentācijas un prototipu apskates. 8. Informēt par projekta prasību izmaiņām, cik ātri vien iespējams. 9. Sekot projekta izstrādes organizācijas vadlīnijām, piesakot izmaiņu pieprasījumus. 10. Cienīt izstrādātāju lietotus prasību inženierijas procesus Kādas saistības izriet no prasību specifikācijas parakstīšanas? Viens no svarīgākiem pasākumiem pasūtītāja un izstrādātāja attiecībās ir panākt izstrādājamā produkta prasību apstiprinājumu. Daudzas organizācijas praktizē prasību specifikācijas parakstīšanu kā liecību prasību apstiprinājumam. Ir svarīgi, lai visi apstiprināšanas procesa dalībnieki zinātu, par ko viņi parakstās un kādas saistības tas uzliek. Viena problēma ir pasūtītāja pārstāvis, kurš uzskata prasību parakstīšanu par bezjēdzīgu rituālu: „Man bija dota lapa, uz kuras bija uzdrukāts mans vārds ar paraksta vietu. Es to parakstīju, jo citādi izstrādātāji neuzsāktu programmēšanu”. Šāda attieksme var novest līdz konfliktiem, kad pasūtītājs vēlas izmainīt vai papildināt

prasības, vai arī brīnās par to, kas ir piegādāts: „Protams, es parakstījos zem prasībām, bet man nebija laika tās izlasīt. Es jums uzticējos, bet jūs mani piemānījāt!” Tikpat problemātiska ir situācija, kad izstrādes vadītājs uzlūko parakstīšanas procesu par prasību negrozāmu iesaldēšanu. Kad parādās izmaiņu pieprasījumi, viņš uzrāda PPS un protestē pret tiem: „Bet jūs esat parakstījuši šīs prasības, tieši to mēs arī izstrādājām. Ja jūs gribējāt kaut ko citu, jums vajadzēja toreiz to teikt”. Abas šīs attieksmes ir pretrunā ar reālo dzīvi – ir neiespējami zināt absolūti visas prasības projekta sākumā, kā arī nedrīkst uzskatīt, ka prasības paliks pilnīgi nemainīgas laika gaitā. Prasību parakstīšana iezīmē prasību izstrādes procesa beigas. Tomēr dalībniekiem ir precīzi jāsaprot, ko nozīmē viņu paraksti uz prasību dokumenta. Vēl svarīgāk par parakstīšanas procesu ir nodibināt prasību apstiprināšanas vadlīniju kā fiksāciju kādā noteiktā laika brīdī. Tādējādi parakstu uz prasību specifikācijas ir jātulko kā „Es piekrītu, ka šis dokuments labākā veidā reprezentē mūsu programmatūras prasību izpratni šodien. Turpmākās izmaiņas var notikt tikai saskaņā ar projektā definēto izmaiņu procesu. Es saprotu, ka apstiprinātas izmaiņas var pieprasīt papildus izmaksas, resursus un laika grafika saskaņošanu”. Šī procesa izpratne palīdzēs situācijās, kad, projektam attīstoties, atklāsies jaunas, negaidītas izmaiņas vai izmainīsies pasūtītāja tirgus vai darījumu pieprasījums. Sākotnējo prasību parakstīšana palīdzēs veiksmīgi pārvaldīt turpmākās pasūtītāja-izstrādātāja attiecības.

12.2. Programmatūras prasību specifikācijas kontrolsaraksts Programmatūras prasību specifikācijas kontrolsaraksts (no http://www.rspa.com/checklists/reqspec.html) The Software Requirements Specification is the work product that is often produced as a consequence of the analysis activity. The checklist that follows will help you to assist the quality of this document. . For this checklist, the more questions that elicit a negative response, the higher the risk that the specification will not adequately serve its purpose. Do stated goals and objectives for software remain consistent with system goals and objectives? Have important interfaces to all system elements been described? Have all data objects been described? Have all attributes been identified? Do major functions remain within scope and has each been adequately described? Have functions been refined (elaborated) to an appropriate level of detail? Is information flow adequately defined for the problem domain? Are diagrams clear; can each stand alone without supplementary text? Is the behavior of the software consistent with the information it must process and the functions it must perform? Have events and states been identified? Are design constraints realistic? Have technological risks been fully defined? Have alternative software requirements been considered?

Have validation criteria been stated in detail; are they adequate to describe a successful system? Have inconsistencies, omissions or redundancy been identified and corrected? Is the customer contact complete? Has the user reviewed the Preliminary User's Manual or prototype? How are the Software Project Plan estimates affected? During the review of a requirements specification we attempt to uncover problems that may be hidden within the specification content. The following guidelines for a detailed specification review are suggested: Be on the lookout for persuasive connectors (e.g., certainly, therefore, clearly, obviously, it follows that), ask why? Watch out for vague terms (e.g., some, sometimes, often, usually, ordinarily, most, mostly); ask for clarification. When lists are given, but not completed, be sure all items are understood. Keys to look for: "etc., and so forth, and so on, such as." Be sure stated ranges don't contain unstated assumptions (e.g., Valid codes range from 10 to 100. Integer? Real? Hex?) Beware of vague verbs such as "handled, rejected, processed, skipped, eliminated." There are many ways they can be interpreted. Beware of ambiguous pronouns (e.g., The I/O module communicates with the data validation module and its control flag is set. Whose control flag?) Look for statements that imply certainty (e.g., always, every, all, none, never), then ask for proof. When a term is explicitly defined in one place, try substituting the definition for other occurrences of the term When a structure is described in words, draw a picture to aid in understanding. When a calculation is specified, work at least two examples.

13.1. Konspekts Prasību inženierijas labā prakse Izmantotie materiāli: Karl E. Wieger. “Software Requirements” – Microsoft Press, 1999, lpp. 37-52 Roger S. Pressman “Software Engineering. A Practioners Approach” - McGraw-Hill. Inc., 1997, 4. nodaļa, lpp. 253-259 Lekcijas plāns · Prasību inženierijas labā prakse. o Prioritātes o Skaidrojumi · Tehniski ekonomiskas pamatojums · Ekonomiskā lietderība · Tehniskā realizējamība Prasību inženierijas labā prakse Zemāk tabulā sniegti labās prakses padomi, kuri ietekmē projekta veiksmi. Padomi sakārtoti pēc to prioritātēm un sarežģītības.

Prioritāte Sarežģītība Augsta Vidēja Zema Augsta - Definēt prasību realizācijas

procedūru - Izstrādāt plānus uz prasību pamata - Pārrunāt saistības

- Identificēt lietošanas piemērus / scenārijus - Definēt kvalitātes atribūtus - Pielāgot PPS sagatavi - Definēt izmaiņu vadības procesu - Nodibināt izmaiņu vadības padomi - Pārbaudīt prasību dokumentus

- Vingrināt izstrādātājus lietojumprogrammatūras- Uzrakstīt vīziju un aptv- Identificēt lietotāju gru - Uzzīmēt konteksta dia- Identificēt prasību avot- Apzīmēt katru prasību- Nodibināt bāzlīnijas unprasību dokumentu versikontroli

Vidēja - Izglītot lietotājus un vadību par prasībām - Modelēt prasības - Veikt prasību riskus pārvaldību - Izmantot prasību pārvaldības rīkus - Izveidot prasību trasējamības matricu

- Vingrināt prasību analītiķus - Nodibināt fokusēšanas grupas - Izstrādāt prototipus - Analizēt iespējamību - Definēt pieņemšanas kritērijus - Veikt izmaiņu ietekmes analīzi - Izsekot katrai izmaiņai līdz visiem ietekmētiem darbproduktiem - Izvēlēties piemērotāko dzīves ciklu

- Izstrādāt zināšanu krāju- Izvēlēties produkta "če- Izveidot datu vārdnīcu- Novērot un fiksēt darījumlikumus (busines- Izstrādāt prasībām atbiltestpiemērus - Sekot līdzi prasību statu

Zema - Noturēt kopsanāksmes (Joint Application Development sessions) - Atkalizmantot prasības - Lietot kvalitātes funkciju izvietošanas (Quality Functions Deployment) pieeju - Mērīt prasību stabilitāti

- Analizēt lietotāju darba plūsmu - Pētīt problēmu ziņojumus - Uzrakstīt lietotāju rokasgrāmatu - Uzturēt prasību vēsturi - Dokumentēt prasību darbietilpību

Padomu izskaidrojums un sadalījums pa procesiem ZINĀŠANAS - Vingrināt prasību analītiķus. Visiem izstrādātājiem jābūt pamatzināšanām par prasību inženieriju, savukārt analītiķus nepieciešams vairāk izglītot šajā jomā. Analītiķiem ir jābūt labām verbālās un neverbālas komunikācijas iemaņām, labi organizētiem, zinošiem lietojumprogrammatūras jomā. - Izglītot lietotājus un vadību par prasībām. Visiem izstrādes projektos iesaistītiem darbiniekiem ir jāsaprot prasību inženierijas pamati un prasību svarīgumu un ietekmi uz projekta rezultātiem. - Vingrināt izstrādātājus problēmapgabala koncepcijās. Lai iesaistītie darbinieki labāk saprastu apgabalu, kuram tiks izstrādāta programmatūra, nepieciešams sarīkot semināru par pasūtītāja darbības jomu - darījumprocesiem, terminoloģiju, mērķiem. Tas var mazināt jucekli un komunikācijas problēmas. - Izstrādāt projekta terminu vārdnīcu. Lai mazinātu komunikācijas problēmas,

jāizstrādā terminu vārdnīca, kurā definē specializētus terminus problēmapgabala sfērā. Svarīgi iekļaut terminus ar vairākām nozīmēm. PRASĪBU IZZINĀŠANA - Uzrakstīt vīziju un aptvērumu (scope). Vīzijas un apjoma dokumentam jāsatur augstā līmeņa lietojumprogrammatūras prasības. Atbilstoši šai vīzijai tiek vēlāk izstrādāti visi lietošanas scenāriji un funkcionālās prasības. - Definēt prasību realizācijas procedūru. Prasību izzināšanas, analīzes, specificēšanas un pārbaudes soļiem jābūt definētiem un dokumentētiem vienotā procedūrā, kura kalpo analītiķiem par ceļvedi. - Identificēt lietotāju grupas. Lai neizlaistu nevienu lietotāju prasību izzināšanas procesā, lietotāji ir jāklasificē grupās. Jāidentificē katras grupas nozīmība un ietekme uz produktu. - Izvēlēties produkta čempionus. Jāizvēlas vismaz viens pārstāvis lietotāju grupā, kurš var precīzi definēt prasības. Tiem ir jāpiedalās dažādās aktivitātēs projekta gaitā un jāvar pieņemt lēmumi. - Nodibināt fokusa grupas. Fokusa grupas ir lietotāji, kuri var nepieņemt lēmumus, bet kuri pārzina funkcionālas un nefunkcionālas programmatūras produkta prasības. - Identificēt lietošanas piemērus/scenārijus. Par lietošanas piemēriem jeb scenārijiem kalpo lietotāju pārstāvju pienākumi, kuru atbalstam nepieciešams izstrādāt lietojumprogrammatūru. - Noturēt kopsanāksmes. Kopsanāksmes (Joint Application Development sessions)ir paplašināti veicinoši semināri, kuros iesaista analītiķus un pasūtītāja pārstāvjus, lai izstrādātu prasību dokumentu. Pasūtītāja iesaistīšana šajā intensīvajā darbā,kalpo par pamatu ciešām attiecībām prasību definēšanas un produkta izstrādes laikā. - Analizēt lietotāju darba plūsmu. Lai izprastu darba plūsmu, pasūtītāja pārstāvjus mēdz novērot, pildot savus pienākumus. Darba plūsmas dokumentēšana palīdz identificēt lietošanas scenārijus un funkcionālās prasības. - Definēt kvalitātes atribūtus. Kvalitātes atribūtu un nefunkcionālo prasību (veiktspēja, efektivitāte, uzticamība, lietojamība u.c.) pirmavots ir lietotāja ieceres. - Izpētīt problēmu ziņojumus. Problēmu un uzlabojumu ziņojumi kalpo par bagātu avotu produkta papildus funkcionalitātes idejām, kuras var būt par pamatu nākamām produkta versijām. - Atkalizmantot prasības. Ja pasūtītājam nepieciešamās funkcionālās prasības ir līdzīgas jau esošajam produktam, ir vērtīgi izmantot jau iegūtās prasības, kā arī meklēt iespēju izmantot jau gatavus programmatūras komponentus. PRASĪBU ANALĪZE - Uzzīmēt konteksta diagrammu. Konteksta diagramma ir vienkāršs modelis, kurš definē robežas un saskarnes starp izstrādājamo programmatūru un pasūtītāja esošām sistēmām. Tā identificē arī informācijas un resursu plūsmu pār saskarnēm. - Izstrādāt prototipus. Ja izstrādātāji vai lietotāji nav pārliecināti par prasībām, var piemērot lietotāju saskarņu prototipus - daļēju iespējamās funkcionalitātes realizāciju, kas kalpo turpmākai koncepcijas izstrādei. - Analizēt prasību iespējamību. Katrai prasībai ir jāizvērtē realizācijas un ieviešanas iespējamība, ņemot vērā izmaksas, veiktspēju un izstrādes vidi. Jānovērtē riski, kas var apdraudēt prasību realizācijas iespējamību, ietverot prasību konfliktus, atkarību no ā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ē lietošanas scenāriju, funkcionalitāšu un atsevišķo prasību realizācija. Ņemot par pamatu prioritātes, jāvienojas par to, kura programmatūras lietojuma versija saturēs kuru daļu realizēto prasību. - Modelēt prasības. Grafiskie prasību analīzes modeļi (datu plūsmas diagrammas, entītiju relāciju diagrammas, stāvokļu-pāreju diagrammas, dialogu kartes un objektu klašu un mijiedarbības diagrammas) var kalpot par vērtīgu papildinājumu PPS dokumentam. - Izveidot datu vārdnīcu. Datu vārdnīca ir centrālā krātuve visu datu vienumu un struktūru definīcijām. Tā nodrošina izstrādātājiem visu nepieciešamo informāciju, strādājot pie saistītiem programmatūras komponentiem. - Pielietot kvalitātes funkciju izvietošanu. Kvalitātes funkciju izvietošana (Quality Funkcion Deployment) ir augsti sistemātiska tehnika produktu funkcionalitāšu sasaistīšanai ar pasūtītāja vērtībām un mērķiem. Tā sniedz analītisku pieeju to funkcionalitāšu identificēšanai, kuras nodrošinās visaugstāko klienta apmierinātību. PRASĪBU SPECIFICĒŠANA - Izvēlēties PPS sagatavi. Organizācijā jābūt definētai programmatūras prasību specifikācijas dokumenta sagatavei, kura ļauj pielāgot šo sagatavi atkarībā no projekta vajadzībām, kā arī atvieglo prasību dokumentēšanu. - Identificēt prasību avotus. Lai pārliecinātos, ka visas ieinteresētās puses zina, kāpēc katra no funkcionālām prasībām ir iekļauta PPS, jāveic atgriezeniska prasību izsekošana, identificējot katras prasības avotu. - Apzīmēt katru prasību. Katrai PPS prasībai ir jābūt unikālam identifikatoram vai marķējumam, kas kalpo par palīgu prasību trasējamības un statusa izsekošanas procesos. - Novērot un fiksēt darījumu likumus. Darījumu likumi ir principi attiecībā uz programmatūru, kā piemēram, kurš un kādos gadījumos var veikt noteiktu funkciju. Šiem principiem jābūt dokumentētiem, lai vēlāk varētu veikt to izpildes pārbaudi. - Izveidot prasību trasējamības matricu. Katrai atsevišķai prasībai ir jābūt sasaistītai ar projektējuma elementu un kodu, kas to implementē, kā arī ar attiecīgo testu, kurš pārbauda tās realizāciju. Prasību trasējamības matrica var arī sasaistīt funkcionālās prasības ar augstākā līmeņa prasībām. PRASĪBU PĀRVALDĪBA - Definēt izmaiņu vadības procesu. Prasību izmaiņu pieteikšanai, analīzei un lēmumu pieņemšanai par prasību realizāciju ir jānotiek saskaņā ar iepriekš definētu izmaiņu vadības procedūru. - Nodibināt izmaiņu vadības padomi. Nodibinot nelielu ieinteresēto pušu grupu, kura saņem izmaiņu pieprasījumus, izvērtē, vai tie ir projekta aptvēruma ietvaros, un pieņem lēmumu par to akceptēšanu vai noraidīšanu, tiek panākta efektīva izmaiņuvadība - novērtēšana, saskaņošana vai noraidīšana, prioritizēšana un piesaistīšana versijām.

- Veikt izmaiņu ietekmes analīzi. Katrai pieteiktai izmaiņai nepieciešams novērtēt tās ietekmi uz projekta kalendāro plānu un citām prasībām. - Izsekot katras prasības ietekmei uz darbproduktiem. Kad izmaiņas ir akceptētas, tām ir jābūt saskaņotām ar prasību trasējamības matricu, lai noskaidrotu, vai nav kādas citas prasības, projektējuma komponenti, kods vai testpiemēri, kuriem atbilstoši jābūt izmainītiem. - Nodibināt bāzlīniju un veikt prasību dokumentu versiju vadību. Definēt prasību bāzlīniju, kas ir attiecīgā brīža saskaņoto prasību momentuzņēmums. Kad prasības ir nostiprinātas, tās var tikt mainītas, tikai izejot speciālu izmaiņu vadības procedūru. Vislabākā pieeja ir izmantot kādu no konfigurāciju pārvaldības rīkiem. - Uzturēt prasību vēsturi. Prasību versiju kontrole ietver vēstures uzturēšanu, t.i. fiksēt izmaiņu pieteicēju, datumu un laiku, iemeslu, prasību dokumenta rediģētāju, datumu un laiku, kā arī jaunu versijas numuru. - Sekot līdzi prasību statusam. Vislabākais veids, kā panākt prasību statusa izsekojamību, ir izveidot reģistru, kurā tiek uzturēta informācija par katras prasības atribūtiem, tai skaitā statusu (piemēram, pieteikta, apstiprināta, implementēta vai verificēta). - Mērīt prasību stabilitāti. Jānosaka nostiprināto (baselined) prasību skaitu un pieteikto un apstiprināto izmaiņu skaitu mēneša vai nedēļas laikā. Pārmērīgas prasību izmaiņas ir sarkanais karodziņš, kas liecina par problēmām projekta uzdevumu izpratnē, definēšanā vai citiem ietekmējošiem aspektiem. - Izmantot prasību pārvaldības rīkus. Komerciālie prasību pārvaldības rīki atvieglo prasību trasējamības un vadības procesu, kalpojot par palīgu komunikācijā starp analītiķiem, izstrādātājiem, testētājiem un, atsevišķos gadījumos, pasūtītājiem. PRASĪBU VERIFIKĀCIJA JEB PĀRBAUDE - Pārbaudīt (inspect) prasību dokumentus. Formāla prasību dokumenta pārbaude, ko veic dažādus skatījumus pārstāvoša speciālistu grupa (piemēram, analītiķis, pasūtītājs, projektētājs un testētājs) ir viena no augsti vērtējamām programmatūras kvalitātes nodrošināšanas aktivitātēm. Tā ļauj pārbaudīt dokumentu un identificēt kļūdas pirms nodošanas pasūtītājam. - Izstrādāt prasībām atbilstošos testpiemērus. Ņemot par pamatu lietošanas scenārijus, iespējams izstrādāt melnās kastes testpiemērus, lai dokumentētu sagaidāmo programmatūras uzvedību (rezultāts) pie specificētiem nosacījumiem (ieejas dati). Testpiemērus var izmantot arī prasību modeļu pareizības testēšanai (dialogu kartes, prototipu testēšanā). - Uzrakstīt lietotāju rokasgrāmatu. Lietotāju rokasgrāmatas sākotnējais variants, izstrādāts vēl pirms izstrādes, var kalpot par prasību specifikāciju vai papildinājumu tai. Laba rokasgrāmata iezīmē visu lietotājam redzamu funkcionalitāti labi saprotamā valodā.

- Definēt pieņemšanas jeb akceptēšanas kritērijus. Lai labāk izstrādātu pieņemšanas testus, ieteicams aptaujāt lietotājus, lai identificētu, kā viņi noskaidros, vai gatava programmatūra atbilst viņu prasībām. Šī informācija var tikt ietverta testpiemēros, lietošanas piemēros vai pieņemšanas testos. PROJEKTU PĀRVALDĪBA - Izvēlēties piemērotāko dzīves ciklu. Atkarībā no prasību detalizācijas un stabilitātes, organizācijai ir jāizvēlas piemērotākais dzīves cikls. Ūdenskrituma modelis ir piemērojams tajos gadījumos, kad prasības ir labi definētas jau projekta sākumā. Pretējā gadījumā jāpiemēro prototipēšanas metodika, pasoļu izstrāde vai kāds cits izstrādes dzīves cikla modelis. - Izstrādāt plānus uz prasību pamata. Darbietilpību un kalendāro plānu sākotnēji novērtē, ņemot par pamatu darījumprasības, vīziju un aptvērumu. Šie novērtējumi nav sevišķi precīzi, tāpēc tie ir jāpārvērtē, kad prasības kļūst skaidrākas. - Pārrunāt saistības. Kad projektam tiek pievienotas jaunas papildus prasības,jānovērtē, vai joprojām ir iespējams sasniegt kvalitātes saistības un iekļauties kalendārajā plānā. Ja tas nav iespējams, situācija ir jāpārrunā ar vadību, piedāvājot jaunus, reālistiskākus plānus. - Veikt prasību risku pārvaldību. Riskiem, kas saistīti ar prasībām, ir jābūt uzskaitītiem un dokumentētiem risku pārvaldības dokumentā. Ir jābūt skaidrai iespējai mazināt vai likvidēt šos riskus. - Dokumentēt prasību darbietilpību. Uzskaitot prasību izstrādei un pārvaldībai nepieciešamo darbietilpību un laiku, iespējams novērtēt, vai plānotās aktivitātes ir notikušas kā plānots, kā arī ļauj labāk plānot resursus nākamajos projektos. Tehniski ekonomiskais pamatojums Visi projekti ir iespējami - ar neierobežotiem resursiem un laiku ! Diemžēl, programmatūras izstrādē ļoti bieži gadās situācijas, kad resursi ir ierobežoti, bet nodošanas termiņi ir vairāk nereāli nekā iespējami. Tieši tāpēc ir ļoti svarīgi novērtēt projekta iespējamību pēc iespējas ātrāk. Atklājot nereālus plānus, var novērst mēnešu un pat gadu ilgu nepamatotu darbu, kā arī tūkstošu latu tēriņu. Iespējamības un risku analīze ir līdzīgi savā starpā. Ja projekta risks ir augsts, tad programmatūras pabeigšanas iespējamība samazinās. Tomēr, veicot produkta izstrādi, uzmanība tiek koncentrēta uz 4 galvenajām lietām: Ekonomiskais pamatojums. Tiek novērtētas izstrādes izmaksas pret ienākumiem vai citiem ieguvumiem no projekta realizācijas. Tehniskais pamatojums. Tiek izpētītas funkciju, veiktspējas un ierobežojumu, kuri var apdraudēt sistēmas izstrādes pabeigšanu. Tiesisks pamatojums. Tiek noteikti jebkuri likumpārkāpumi, traucējumi vai atbildība, kuri var iestāties vai izrietēt no sistēmas izstrādes. Alternatīvas. Tiek novērtētas alternatīvas pieejas sistēmas izstrādei. Tehniski ekonomiskais pamatojums nav obligāts, ja sistēmas izstrādes ekonomiskais attaisnojums ir acīmredzams, tehniskais risks ir zems, gaidāmas neliels skaits tiesisku problēmu un neeksistē saprātīgas alternatīvas. Tomēr, ja jebkurš no šiem faktoriem ir citādāks, tehniski ekonomiskais pamatojums ir jāveic.

Apsvērumi, saistīti ar tehniski ekonomisko pamatojumu ir šādi: Izstrādes risks. Vai sistēmas elements var būt izstrādāts, sasniedzot nepieciešamas funkcijas un veiktspēju, kā arī ņemot vērā noteiktus ierobežojumus? Resursu pieejamība. Vai zinoši darbinieki ir pieejami sistēmas vai sistēmas elementa izstrādei? Vai citi resursi (aparatūra, programmatūra) ir pieejami, lai veikt izstrādi? Tehnoloģija. Vai atbilstoša tehnoloģija ir sasniegusi līmeni, kurš nepieciešams, lai veiksmīgi atbalstītu un uzturētu sistēmas funkcijas? Tehniski ekonomiskais pamatojums var būt dokumentēts kā atsevišķa atskaite augstākai vadībai, kura iekļauj papildinājumus esošai sistēmas specifikācijai. Tomēr šī dokumenta forma var atšķirties. Dokumenta satura paraugs: I. Ievads A. Problēmas izklāstījums B. Ieviešanas vide C. Ierobežojumi II. Pārvaldības kopsavilkums un rekomendācijas A. Svarīgie konstatējumi B. Komentāri C. Rekomendācijas D. Ietekme III. Alternatīvas A. Sistēmas konfigurācijas alternatīvas B. Gala pieejas izvēlē izmantoti kritēriji IV. Sistēmas apraksts A. Īss aptvēruma izklāstījums B. Noteikto elementu iespējamība V. Izmaksu-labumu analīze VI. Tehnisko risku novērtējums VII. Tiesisks sazarojums VIII. Citi projektam specifiskie faktori Tehniski ekonomisko pamatojumam pirmo apskati veic projekta pārvaldnieks (lai novērtētu satura uzticamību) un tad augstākā vadība (lai novērtētu projekta statusu). Pamatojumam ir jāseko lēmuma pieņemšanai "sākt/nesākt". Ir jāpiezīmē, ka šādi lēmumi tiks vēlāk pieņemti arī pēc plānošanas, specifikācijas izstrādes un programmatūras izstrādes soļiem. Ekonomiskā lietderība Starp citām svarīgām lietām tehniski ekonomiskais pamatojums satur izmaksu un labumu analīzi - novērtējumu sistēmas izstrādes projekta ekonomiskajam pamatojumam. Izmaksu-labumu analīze attēlo projekta izstrādei nepieciešamas izmaksas un salīdzina tos ar materiāliem un nemateriāliem ieguvumiem no sistēmas izstrādes. Izmaksu-labumu analīzi sarežģī kritēriji, kuri ir atkarīgi no izstrādājamās sistēmas raksturlielumiem, relatīva projekta izmēra un sagaidāmās peļņas no kapitālieguldījumiem, kura ir daļa no organizācijas stratēģiskā plāna. Bez tam, audzi ieguvumi no sistēmas izstrādes ir nes nemateriālu vērtību (piemēram, labākā projektēšanas kvalitāte, veicot iteratīvu optimizāciju, paaugstināta klientu apmierinātība, labāka lēmumu pieņemšana). Dažreiz tiešo kvantitatīvo novērtējumu ir grūti iegūt.

Iespējamie informācijas sistēmas ieguvumiIespējamas informācijas sistēmas izmaksasIeguvumi no aprēķinu vai drukāšanas uzdevumu uzlabošanas Izmaksu samazināšana katra vienuma aprēķinam un drukāšanai (CR) Aprēķinu uzdevumu precizitātes uzlabošana (ER) Iespēja ātri izmainīt mainīgos un vērtības aprēķinu programmās (IF) Ievērojami uzlabots aprēķinu un drukāšanas ātrums (IS) Ieguvumi no ierakstu uzturēšanas uzdevumu uzlabošanas Iespēja "automātiski" vākt un uzkrāt datus no ierakstiem (CR, IS, ER) Ierakstu pilnīgāka un sistēmatiskāka uzturēšana (CR, ER) Paaugstināta ierakstu uzturēšanas ietilpība - vietas un izmaksu ziņā (CR) Ierakstu uzturēšanas standartizēšana (CR, IS) Uzlabota ierakstu uzkrāšanas drošība (ER, CR, MC) Uzlabota ierakstu pārnesamība (IF, CR, IS) Ieguvumi no ierakstu meklēšanas uzdevumu uzlabošanas Ātrāka ierakstu izguve (IS) Uzlabota iespēja piekļūt ierakstiem no lielām datu bāzēm (IF) Uzlabota iespēja veikt labojumus ierakstos datu bāzēs (IF, CR) Spēja savienot vietnes, kurām nepieciešama meklēšanas iespēja, ar telekomunikāciju palīdzību (IF, IS) Iespēja auditēt un analizēt ierakstu meklēšanas aktivitātes (MC, ER) Ieguvumi no sistēmas pārveidošanas iespēju uzlabošanas Iespēja vienlaicīgi mainīt visas ierakstu klases (IS, IF, CR) Iespēja pārvietot lielus datu failus (IS, IF) Iespēja veidot jaunus failus, apvienojot citu failu elementus (IS, IF) Ieguvumi no analīzes un simulācijas iespēju uzlabošanas Iespēja ātri veikt sarežģītus, vienlaicīgus aprēķinus (IS, IF, ER) Iespēja veidot simulācijas sarežģītām

Sagādes izmaksas Konsultāciju izmaksas Aprīkojuma iegādes vai nomas izmaksas Aprīkojuma instalācijas izmaksas Izmaksas aprīkojuma izmaiņām (gaisa kondicionēšanas iekārtas, drošība u.c.) Īpašuma izmaksas Pārvaldības un ar sagādi saistītā personāla izmaksas Sākotnējas izmaksas Operētājsistēmas programmatūras izmaksas Komunikācijas aprīkojuma instalācijas izmaksas (telefonlīnijas, datu līnijas u.c.) Palaides personāla izmaksas Darbaspēka meklēšanas un salīgšanas izmaksas Zaudējumi no sistēmas nepalaišanas Ar projektu saistītas izmaksas Lietojumprogrammatūras iegādes izmaksas Programmatūras pielāgošanas izmaksas Iekšējo lietojumu izstrādes darbaspēka, u.c. izmaksas Lietotāju personāla apmācības izmaksas Datu vākšanas un datu instalācijas procedūru izmaksas Dokumentācijas sagatavošanas izmaksas Izstrādes pārvaldības izmaksas Nepārtrauktas izmaksas Sistēmu uzturēšanas izmaksas (aparatūra, programmatūra un telpas) Īres izmaksas (elektrība, telefoni, u.c.) Aparatūras amortizācijas izmaksas Sistēmu pārvaldības, ekspluatācijas un plānošanas aktivitātēs iesaistītā personāla izmaksas

parādībām, atbildot uz jautājumu "kas būs, ja...?" (MC, IF) Iespēja savākt lielu apjomu datu plānošanai un lēmumu pieņemšanai (MC, IF) Ieguvumi no procesu un resursu pārvaldības uzlabošanas Samazināta darbaspēka nepieciešamība procesu un resursu pārvaldībai (CR) Uzlabota iespēja savirknēt procesus, kā, piemēram, veidojot konveijeru (CR, MC, IS, ER) Uzlabota iespēja uzturēt ilgstošu resursu uzraudzību (MC, ER, IF)

Saīsinājumi: CR - izmaksu samazināšana; ER - kļūdu samazināšana; IF - elastīguma paaugstināšana; IS - aktivitātes ātruma paaugstināšana; MC - uzlabota pārvaldības plānošana vai kontrole.

Tehniskā realizējamība Veicot tehnisko analīzi, analītiķis novērtē sistēmas koncepcijas tehniskos plusus, paralēli uzkrājot informāciju par veiktspēju, uzticamību, uzturamību un produktivitāti. Dažos gadījumos, sistēmas analīzes solis iekļauj arī ierobežotu izpēti un projektēšanu. Tehniskā analīze sākas ar sistēmas tehniskās dzīvotspējas novērtēšanu. Kādas tehnoloģijas ir nepieciešamas, lai apmierinātu sistēmas funkcionalitāti un veiktspēju? Kādi materiāli, metodes, algoritmi vai procesi ir nepieciešami un kādi ir to izstrādes riski? Kā šīs tehnoloģijas ietekmēs izmaksas? Starp rīki, pieejamiem tehniskas analīzes veikšanai, var minēt dažus, kā, piemēram, matemātiskas modelēšanas un optimizēšanas tehnikas, iespējamības un statistikas, rindošanas teorija un kontroles teorija. Blanchard un Fabrycky definē kritēriju kopu modeļu izmantošanai, veicot tehnisko analīzi, šādi:

1. Modelim ir jāreprezentē sistēmas konfigurācijas dinamiku pietiekami vienkāršu, lai to varētu viegli saprast un manipulēt ar to, tai pat laikā pietiekami tuvu realitātei. 2. Modelim ir jāiezīmē tie faktori, kuri ir svarīgi problēmas risināšanai un noklusēt tos, kuri nav tik svarīgi. 3. Modelis ir jāveido kā vispārējs, iekļaujot visus būtiskus faktorus un tam ir jābūt uzticamam, ņemot vērā rezultātu atkārtojamību. 4. Modeļa projektējumam jābūt pietiekami vienkāršam, lai savlaicīgi implementēt problēmu risinājumus. 5. Modeļa projektējumam ir jāiekļauj noteikumi vieglai modificēšanai un/vai papildināšanai, lai ļautu novērtēt papildus faktorus atbilstoši prasībām. No tehniskās analīzes iegūtie rezultāti veido bāzi citiem "sākt/nesākt" lēmumiem. Ja tehniskais risks ir nopietns, ja modelis norāda uz pieprasītas funkcijas vai veiktspējas realizācijas neiespējamību, ja sistēmas daļas vienkārši nav savienojamas - ir jāveic solis atpakaļ !

14.1. Konspekts 1 Projektēšanas pamati un principi (Design Concepts and Principles) Izmantotie materiāli: Roger S. Pressman. “Software Engineering. A Practioners Approach” – McGraw-Hill. Inc., 1997, 13. nodaļa (lpp.341-364) Lekcijas plāns Projektējuma dokumentācija Secinājumi Projektēšanas metodes Datu projektēšana Arhitektūras projektēšana Arhitektūras projektēšanas process Projektējuma pēc beigu apstrāde

1. attēls. Analīzes modeļa pārveidošana par programmatūras projektējumu Projektējuma dokumentācija Projektējuma dokumentācijas sagatave: I. Sfēra A. Sistēmas mērķi B. Galvenās programmatūras prasības C. Projektējuma ierobežojumi II. Datu projektējums A. Datu objekti un izrietošas datu struktūras B. Failu un datu bāžu struktūras 1. ārējo failu struktūra a. loģiskā struktūra b. loģiskais ierakstu apraksts c. piekļuves metodes 2. globālie dati 3. failu un datu saistes norādes III. Arhitektūras projektējums A. Datu un kontroles plūsmas apraksts B. Atvasināta programmas struktūra IV. Saskarņu projektējums A. Cilvēka-datora saskarnes specifikācija B. Cilvēka-datora saskarnes projektējuma likumi C. Ārējo saskarņu projektējums 1. Saskarnes uz ārējiem datiem 2. Saskarnes uz ārējām sistēmām vai ierīcēm D. Iekšējo saskarņu projektējuma likumi V. Procesuāls projektējums Katram modulim: A. Apstrādes apraksts B. Saskarņu apraksts C. Projektējuma valodas (vai citu) apraksts D. Lietotie moduļi E. Iekšējo datu struktūras F. Komentāri/ ierobežojumi VI. Prasību saistes norādes VII. Testēšanas noteikumi A. Testēšanas vadlīnijas

B. Integrācijas stratēģija C. Īpašie apsvērumi VIII. Īpašas piezīmes IX. Pielikumi Katra projektējuma dokumentācijas sadaļa attiecas uz dažādiem projektējuma modeļu aspektiem. Numurētas sekcijas ir parasti pabeigtas, kad projektētājs sagatavo programmatūras risinājuma prezentāciju. Liela daļa informācijas, kuru satur I sekcija, nāk no programmatūras prasību specifikācijas (PPS) un analītiskā modeļa. II sekcija apraksta ārējo datņu struktūru, iekšējo datu struktūru un šķersatsauces starp datu objektiem un konkrētām datnēm. III sekcija uzskatāmi parāda, kā programmatūras arhitektūra izriet no analītiskā modeļa. IV un V sekcijas attīstās līdz ar saskarņu un procedūru projektējumu. VI sekcija satur prasību šķērsatsauces, kuru mērķis ir izveidot matricu, kurā būtu redzams, kā programmatūras projektējums apmierina klienta prasības, kā arī identificēts konkrēto prasību implementācijas kritiskums, sadalot tās pa moduļiem. VII sadaļa satur pirmo testēšanas dokumentācijas fāzi, kā arī norādījumus produkta piegādei klientam. Visbeidzot, IX sadaļa satur papildinformāciju - algoritmu aprakstus, alternatīvas procedūras, tabulārus datus, izvilkumus no citiem dokumentiem un citu svarīgu informāciju. Ir ieteicams izstrādāt arī sākotnējo darbības/instalācijas rokasgrāmatu un iekļaut to projektējuma dokumentācijas pielikumos. Secinājumi "Mēs mēģinām risināt problēmu, steidzoties caur projektēšanas procesu, lai iekrātu pietiekami laika, ko projekta beigu posmā izmantot to defektu atklāšanai un novēršanai, kuri mums būs radušies tāpēc, ka esam sasteiguši projektēšanas procesu". Glenford Myers Projektēšanas metodes Datu projektēšana Datu projektēšana ir pirmais un pēc dažu uzskatiem pats svarīgākais no 4 projektēšanas soļiem, kurus veic programminženierijas laikā. Datu projektēšanas process ir šāds: sākotnēji tiek izvēlēta loģiskā datu objektu (struktūru) reprezentācija; tad ir ļoti svarīgi identificēt programmas moduļus, kuriem ir jāsadarbojas tieši ar datu objektiem vai loģiskām struktūrām. Vasermans (Wasserman) piedāvā šādus datu projektējuma principus. 1. Sistemātiskas analīzes principus, ko lieto funkciju un uzvedības izzināšanā, jālieto arī datiem. 2. Visām datu struktūrām un ar tām veiktajām operācijām ir jābūt identificētām. 3. Jāizveido datu vārdnīca un tā jālieto gan datu, gan programmatūras projektēšanā. 4. Zema līmeņa datu projektējuma lēmumi ir jāpieņem projektēšanas procesa beigās. 5. Datu struktūras reprezentācijai ir jābūt zināmai tikai tiem moduļiem, kuri tieši izmanto datus, kurus satur atbilstošas struktūras. 6. Jāizveido noderīgo datu struktūru bibliotēka ar operācijām, kuras var būt veiktas, izmantojot šīs datu struktūras. 7. Programmatūras projektēšanas un programmēšanas valodai ir jāatbalsta abstraktu datu tipu specifikācija un realizācija.

Arhitektūras projektēšana Arhitektūras projektēšanas galvenais mērķis ir izstrādāt modulāru programmas struktūru un reprezentēt vadības attiecības starp moduļiem. Katrai programmatūras projektēšanas metodei ir savi plusi un mīnusi. Svarīgs faktors projektēšanas metodes izvēlē ir lietojumu plašums, kam šī metode var tikt piemērota. Datu plūsmu orientēta projektēšana ir piemērojama plašam lietojumu jomu lokam. Tā ir lietderīga gandrīz visām sistēmām, kur informācija rodas secīgi un nepastāv īpaša datu struktūru formāla hierarhija. Arhitektūras projektēšanas process Datu plūsmu orientēta projektēšana ir arhitektūras projektēšanas metode, kura ļauj ērti pāriet no programmas struktūras analītiskā modeļa uz projektējuma aprakstu. Šī pāreja no informācijas plūsmas uz moduļu struktūru ir veicama 5 soļos: 1. informācijas plūsmas tipa konstatēšana; 2. plūsmu robežu identificēšana; 3. datu plūsmu diagrammas (DPD) attēlošana par programmas struktūru; 4. vadības hierarhijas definēšana; 5. izveidojušās struktūras uzlabošana, izmantojot dažādus projektēšanas paņēmienus un heiristikas. Pārveidošanas (transform) plūsma: Sistēmas pamatmodelī (datu plūsmas modeļa 0. līmenis) informācijai ir jāienāk un jāiznāk no programmatūras "ārējās pasaules" formā. Informācija, kas ienāk sistēmā pa ārējo datu pārveidošanas ceļiem uz iekšējo formu, ir ienākošā (incoming) plūsma. Ienākošie dati tiek izlaisti caur pārveidošanas centru (transform center) un sāk virzīties pa ceļiem uz sistēmas ārpusi. Šī plūsma saucas par izejošo (outgoing) plūsmu. Ja kādā datu plūsmu diagrammas daļā saskatāmi pieminētie elementi, tā ir pārveidošanas plūsma. Transakciju (transaction) plūsma: Sistēmas pamatmodelis demonstrē pārveidošanas plūsmu, tāpēc visas datu plūsmas varētu ietilpināt šajā kategorijā.Tomēr nereti informācijas plūsmu raksturo viens datu vienums(item), ko sauc par transakciju, un kas izraisa citu datu plūsmu pa kādu no daudziem iespējamiem ceļiem. Transakciju pāreja ir līdzīga pārveidošanas pārejai. Galvenās atšķirības ir pārējā no DPD uz programmatūras struktūru: 1. solis - Apskata sistēmas pamatmodeli 2. solis - Apskata un detalizē datu plūsmu diagrammas 3. solis - Noskaidro, vai DPD fragmentam ir pārveidošanas vai transakciju plūsmu raksturiezīmes 4. solis - Izolē transakciju centru, nosakot ienākošo un izejošo plūsmu robežas 5. solis - Attēlo DFD par programmas struktūru, kas atbild par vadības plūsmas organizēšanu 6. solis - Caurskata DFD procesus ("burbuļus") un attēlo tos par atbilstošiem moduļiem 7. solis - Detalizē pirmās iterācijas programmas struktūru, izmantojot projektēšanas heiristikas, lai uzlabotu programmatūras kvalitāti Projektējuma pēcapstrāde Veiksmīgas pārveidošanas vai transakciju attēlošanas (mapping) beigās parasti seko

papildus dokumentēšana, kas ir daļa no arhitektūras projektēšanas procesa. Pēc tam, kad struktūra ir izveidota un detalizēta, ir jāveic šādi uzdevumi: jāizstrādā apstrādes apraksts katram modulim; jāizstrādā saskarņu apraksts katram modulim; jādefinē lokālo un globālo datu struktūras; jāatzīmē visi projektējuma ierobežojumi; jāveic projektējuma apskate (review); jāapsver optimizācija (ja nepieciešama un pamatojama).

14.2. Konspekts 2 Sistēmas projektēšana - pāreja no DFD uz arhitektūras projektējumu Izmantotie materiāli: Roger S. Pressman. “Software Engineering. A Practioners Approach” – McGraw-Hill. Inc., 1997, 13. nodaļa (lpp.375-391) Lekcijas plāns Arhitektoniskā projektēšana Transformācijas plūsma Transakciju plūsma Projektēšanas piemērs Arhitektoniskā projektēšana Datu plūsmu-orientēta projektēšana ir arhitektoniskās projektēšanas metode, kura ļauj ērti pāriet no analīzes modeļa uz programmas struktūras projektējuma aprakstu. Pāreja no informācijas plūsmas (reprezentētas kā datu plūsmu diagramma) uz programmas struktūru nosacīti sastāv no 5 soļiem: (1) nosaka informācijas plūsmas tipu; (2) identificē plūsmas robežas; (3) datu plūsmu diagrammu attēlo par programmas struktūru; (4) ar „faktorēšanas” metodi definē vadības hierarhiju; (5) rezultējošo struktūra pilnveido, izmantojot dažādus projektēšanas paņēmienus un heiristiskas metodes. Transformācijas plūsma Fundamentālajā sistēmas modelī (datu plūsmas diagrammas 0. līmenis) informācija ieiet un iziet no sistēmas "ārējās pasaules" formā (skat. 1.att.). Informācija ieiet sistēmā pa ceļiem, kas pārveido ārējos datus iekšējā formā, tāpēc to sauc par ienākošo plūsmu. Sistēmas kodolā notiek pārveidošana jeb transformācija. Ieejas dati tiek izlaisti caur transformācijas centru un sāk virzīties uz sistēmas ārpusi. Datus, kuri iziet pa šiem ceļiem, sauc par izejošo plūsmu. Kopējā plūsma rit secīgi un tā iet pa vienu vai dažiem "taisniem" ceļiem. Kad kādam datu plūsmas diagrammas segmentam piemīt šādas raksturiezīmes, mums ir transformācijas plūsma. Transakciju plūsma Fundamentālais sistēmas modelis vienmēr satur transformācijas plūsmu, tādējādi tā iespējams raksturot ikvienu datu plūsmu. Tomēr informācijas plūsmu nereti var raksturot, izmantojot vienu datu vienumu, ko sauc par transakciju un kura izraisa

pārējās datu plūsmas. Transakciju plūsma parādās, kad datu plūsmu diagramma pieņem 2.att. redzamo formu.

1. attēls. Informācijas plūsma Transakciju plūsmu raksturo datu kustība pa ieejas ceļiem, pārveidojot ārējās pasaules informāciju par transakciju. Transakcija tiek aprēķināta, par pamatu ņemot tās vērtību, tiek uzsākta plūsma pa vienu no darbības ceļiem (action paths). Informācijas plūsmas centru, kurš izstaro darbības ceļus, sauc par transakcijas centru.

2. attēls. Transakciju plūsma Transformāciju attēlošana (Tranform mapping) Transformāciju attēlošana ir projektēšanas soļi, kuri ļauj DFD ar transformācijas plūsmas raksturiezīmēm attēlot kā iepriekš definētu sagatavi programmas struktūrām. Piemērs. Sistēmas apraksts Lai ilustrētu projektēšanas procesu, aprakstīsim SafeHome drošības sistēmas izstrādi. SafeHome sistēma ļauj mājas saimniekam konfigurēt drošības sistēmu, kad tā ir instalēta, pārvaldīt drošības sistēmai pievienotus sensorus un darboties ar

papildtastatūru un funkcionālo tastatatūru, ko satur SafeHome vadības panelis (3. attēls)

3. attēls. SafeHome vadības panelis Veicot instalāciju, SafeHome vadības panelis tiek izmantots sistēmas konfigurēšanai. Katram sensoram tiek piešķirts numurs un tips, tiek uzstādīta galvenā parole sistēmas ieslēgšanai un izslēgšanai, kā arī tiek ievadīts telefona numurs, kas tiks uzgriezts, ja sistēma nostrādās. Kad tiek atpazīts sensora notikums, sistēma rada skaņas signālu. Pēc konfigurācijā noteiktā laika intervāla sistēma uzgriež telefona numuru un ziņo par notikuma vietu un dabu. Zvans tiek atkārtots ik pa 20 sekundēm, kamēr uz to netiek atbildēts. Visa veida mijiedarbība ar SafeHome tiek pārvaldīta no lietotāju-mijiedarbības apakšsistēmas, kura nolasa ievadu, ko nodrošina papildtastatūra un funkcionālā tastatūra, attēlo paziņojumus un sistēmas statusu uz LCD ekrāna.... 0. līmeņa datu plūsmu diagramma SafeHome sistēmai ir parādīta 4. attēlā.

4. attēls. Konteksta līmeņa datu plūsmu diagramma Projektējuma soļi 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 2. solis - caurskatīt un uzlabot sistēmas datu plūsmu diagrammu (6. att.).

6. attēls. 2. līmeņa datu plūsmu diagramma 3. solis - noteikt, vai DPD ir transformācijas vai transakcijas plūsmu raksturiezīmes (7. att.). 4. solis - izolēt transformācijas centru, norādot ienākošās un izejošās plūsmas robežas (7. att.).

7. attēls. 3. līmeņa datu plūsmu diagramma ar plūsmas robežām 5. solis - veikt "pirmā-līmeņa faktorēšanu (factoring)" (8. att.).

8. attēls. Pirmā-līmeņa „faktorējums" 6. solis - veikt "otrā-līmeņa faktorējumu" (9. att.).

9. attēls. Pirmā līmeņa faktorējums 7. solis - uzlabot pirmo sistēmas struktūras iterāciju, izmantojot heiristisku projektēšanu programmatūras kvalitātes uzlabošanai (10. att.).

10. attēls. "Pirmā slīpējuma" sistēmas struktūra

Transakciju attēlošana (mapping). Daudzos lietojumos viens datu vienums izraisa vienu vai vairākas informācijas plūsmas, kuras ietekmē funkciju, kuru satur šis datu vienums (11. att.). Transakciju attēlošanas soļi: 1. solis - Caurskatīt fundamentālo sistēmas modeli. 2. solis - Caurskatīt un uzlabot datu plūsmas diagrammu. 3. solis – Noteikt, vai DPD ir transformācijas vai transakcijas plūsmas raksturiezīmes. 4. solis - Identificēt transakcijas centru un plūsmas raksturiezīmes katram darbību ceļam. 5. solis - Attēlot DPD par programmas struktūru, kas būs atbildīga par transakciju veikšanu. 6. solis - Sadalīt un uzlabot transakciju struktūru un katra darbību ceļa struktūru. 7. solis - Uzlabot pirmo programmas struktūras iterāciju, izmantojot projektēšanas heiristikas programmatūras kvalitātes uzlabošanai.

11. attēls. Transakcijas attēlošana

15.1. Konspekts Konfigurācijas pārvaldība (Configuration Management) Izmantotie materiāli:

Roger S. Pressman. “Software Engineering. A Practioners Approach” – McGraw-Hill. Inc., 1997, 9. nodaļa (lpp.209-227) Lekcijas plāns Kas ir programmatūras konfigurācijas pārvaldība? Bāzlīnijas Programmatūras konfigurācijas vienumi Programmatūras konfigurācijas pārvaldības process Programmatūras konfigurācijas objektu identifikācija Versiju kontrole Izmaiņu vadība Konfigurācijas audits Stāvokļa uzskaite Kas ir programmatūras konfigurācijas pārvaldība? Programmatūras izstrādes procesa rezultātus var iedalīt 3 kategorijās: (1) programmas (koda līmenis, izpildāmās formas); (2) dokumentācija (tehniska, administratora, lietotāja); (3) dati, ko satur pati programma. Informācijas kopu, kas satur visus izstrādes procesa rezultātus, sauc par programmatūras konfigurāciju. Laika gaitā konfigurācijas vienumu kļūst arvien vairāk un vairāk. Arī programmatūras izmaiņas dara savu. Kā vēsta programmatūras inženierijas Pirmais likums : "Nav svarīgi, kurā solī jūs atrodaties sistēmas dzīves ciklā, sistēma mainīsies un sistēmas tieksme mainīties augs līdzi dzīves ciklam". Bāzlīnijas Izmaiņas ir dzīves neizbēgama realitāte programmatūras izstrādē. Pasūtītāji vēlas mainīt prasības. Izstrādātāji vēlas mainīt tehnisko pieeju. Vadītāji vēlas mainīt projekta pieeju. Kāpēc? Atbilde ir tiešām ļoti vienkārša. Laikam ejot uz priekšu, visas iesaistītās puses uzzina vairāk par to, ko viņi vēlas, kādu pieeju labāk izvēlēties u.tml.. Šīs jaunās zināšanas ir galvenais izmaiņu virzītājs, un visbiežāk izmaiņas ir pamatotas, ko, protams, ir grūti pieņemt izstrādātājiem. Bāzlīnijas ir programmatūras konfigurācijas pārvaldības koncepcija, kas palīdz mums pārvaldīt izmaiņas bez nopietnām traucējumiem pamatoto izmaiņu realizācijai. IEEE Std. 610.12-1990 definē bāzlīnijas sekojoši: Specifikācija vai produkts, kurš formāli ir apskatīts un saskaņots, kurš tādējādi kalpo par pamatu turpmākai izstrādei un kurš var tikt mainīts, tikai izmantojot formālu vadības procedūru. Viens veids, kā ilustrēt bāzlīnijas, ir analoģija: Iedomājieties virtuves durvis lielā restorānā. Lai izvairītos no sadursmēm, viena durvju puse ir atzīmēta kā IEEJA, bet otra - kā IZEJA. Durvīm ir ierīkoti slēdži, kuri ļauj katrai durvju pusei vērties tikai savā virzienā. Ja oficiants pieņem pasūtījumu virtuvē, noliek to uz paplātes un tad saprot, ka ir paņēmis nepareizo šķīvi, viņš var ātri, bez problēmām nomainīt šķīvjus pirms iziešanas no virtuves. Bet, ja oficiants jau ir paspējis iziet no virtuves un iedot nepareizo šķīvi restorāna apmeklētājam, apmeklētājam aizrādot par kļūdu, oficiantam ir jāseko noteiktai procedūrai: (1) paskatīties pasūtījuma lapā, lai pārliecinātos par kļūdu; (2) atvainoties; (3) atgriezties virtuvē caur IEEJAs durvīm; (4) paskaidrot problēmu; un tā tālāk...

Bāzlīnijas ir analogs šķīvim, kurš ceļo no virtuves līdz restorāna apmeklētājam. Pirms programmatūras konfigurācijas vienums (item) kļūst par bāzlīniju, izmaiņas var notikt ātri un neformāli. Savukārt, ja bāzlīnijas ir nodibinātas, mēs figurāli esam izgājuši ārā pa viena virziena durvīm, un turpmākās izmaiņas var notikt tikai pēc noteiktas procedūras. Zemāk ir attēloti konfigurācijas pārvaldības izplatītākie vienumi (1. attēls) un to saistība ar projekta datubāzi (sinonīmi - projekta datne, repozitorijs) (2. attēls).

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. Programmatūras konfigurācijas vienumi Sekojoši konfigurācijas vienumi ir galvenie un veido vadlīniju kopu: 1. Sistēmas specifikācija 2. Programmatūras projekta plāns 3. Programmatūras prasību specifikācija a. Grafiskie analīzes modeļi b. Procesu specifikācija c. Prototips(i) d. Matemātiskā specifikācija 4. Sākotnēja lietotāju rokasgrāmata 5. Projektējuma specifikācija a. Datu projektējuma apraksts b. Arhitektūras projektējuma apraksts c. Moduļu projektējuma apraksti d. Saskarņu projektējuma apraksti e. Objektu apraksti (objektu-orientētas izstrādes gadījumā) 6. Programmatūras koda izdruka 7. Testēšanas specifikācija a. Testa plāns un procedūra b. Testpiemēri un rezultāti 8. Darbības un instalācijas rokasgrāmatas 9. Strādājošā programmatūra a. Strādājošo moduļu kods b. Saistītie moduļi 10. Datubāzes apraksts a. Shēma un failu struktūra b. Sākotnējs saturs 11. Lietotāju rokasgrāmata 12. Uzturēšanas dokumentācija a. Programmatūras problēmu ziņojumi b. Uzturēšanas pieprasījumi c. Izmaiņu pieprasījumi 13. Programmatūras inženierijas standarti un procedūras Programmatūras konfigurācijas pārvaldības process Programmatūras konfigurācijas pārvaldība ir svarīga kvalitātes nodrošināšanas sastāvdaļa. Tās galvenā atbildības sfēra ir izmaiņu vadība. Tomēr programmatūras konfigurācijas pārvaldība ir atbildīga arī par konfigurējamo vienumu identifikāciju un programmatūras versijām, programmatūras auditēšanu, lai pārliecinātos, ka tā ir izstrādāta pareizi, un visu konfigurācijas izmaiņu uzskaiti. Jebkura diskusija par programmatūras konfigurācijas pārvaldību aptver sarežģītu jautājumu kopu: Kā organizācija identificē un pārvalda daudzas esošas programmas versijas (un to dokumentāciju), lai nodrošinātu efektīvu izmaiņu pievienošanu? Kā organizācija vada izmaiņas pirms un pēc programmatūra ir piegādāta pasūtītājam? Kurš ir atbildīgs par izmaiņu apstiprināšanu un prioritizēšanu? Kā var pārliecināties, ka izmaiņas ir izpildītas pareizi? 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: identificēšana, versiju vadība, izmaiņu vadība, konfigurācijas auditēšana un stāvokļa uzskaite. Programmatūras konfigurācijas objektu identifikācija Lai vadītu un pārvaldītu programmatūras konfigurācijas vienumus, katram no tiem ir jābūt atsevišķi nosauktam un organizētam objektorientētā modelī. Identificējami ir 2 veida objekti: pamatobjekti un agregātobjekti. Katram objektam ir nosaukums, apraksts, resursu saraksts un "realizācija". Objekta nosaukumam jāidentificē objektu nepārprotami (t.i. unikāli). Objekta apraksts ir informācija, kas identificē konfigurācijas pārvaldības vienuma tipu (dokuments, programma, dati), projekta identifikatoru un izmaiņu un/vai versijas informāciju. Katrs objekts laika gaitā mainās, tāpēc tā vēsture var tikt attēlota kā evolūcijas grafs (3. attēls).

3. attēls. Konfigurācijas objekta evolūcijas grafs. Versiju vadība Versiju vadība ietver procedūras un rīkus dažādu konfigurācijas objektu versiju pārvaldībai. Konfigurācijas pārvaldība ļauj lietotājam iezīmēt alternatīvas sistēmas konfigurācijas, izvēloties attiecīgas versijas. Tas tiek nodrošināts, sasaistot atribūtus katrai programmatūras versijai, un ļaujot izvēlēties konfigurāciju, aprakstot nepieciešamo atribūtu kopu. Ar "atribūtiem" ir domāts versijas numurs vai veikto izmaiņu apraksts, kas atšķir vienu programmatūras versiju no otras. Viena versiju reprezentācija ir evolūcijas grafs (3. attēls). Katrs grafa mezgls ir agregātobjekts, kas ir gatava programmatūras versija. Savukārt katra programmatūras versija ir konfigurācijas objektu vienumu kopa (programmatūras kods, dokumenti, dati) un katra versija var sastāvēt no dažādiem variantiem.

4. attēls. Versijas varianti Piemēram, iedomāsimies tādu programmas versiju, kurai ir komponentes 1, 2, 3, 4 un 5 (4. attēls). Komponente 4 tiek izmantota tikai tad, ja programmatūra tiek instalēta uz datoriem, kuri izmanto krāsu monitorus, savukārt, uz monohromatiskiem monitoriem tiek lietota 5. komponente. Tādējādi var secināt, ka versijai ir 2 varianti: (1) komponentes 1,2,3 un 4; (2) komponentes 1,2,3 un 5. Lai instalētu pareizo programmatūras versijas variantu, katrai komponentei var piešķirt "atribūtu-kopu" - nosacījumus, kuri nosaka, vai komponente ir lietojama instalējamā programmatūras versijā. Katram variantam var piešķirt vienu vai vairākus atribūtus. Piemēram, krāsas atribūtu var lietot, lai noteiktu, kuru komponenti nepieciešams iekļaut krāsu monitoru gadījumā. Izmaiņu vadība Lielam programmatūras izstrādes projektam nevadītas izmaiņas noved pie haosa. Izmaiņu vadība iekļauj procedūras un rīkus, lai nodrošinātu izmaiņu vadības mehānismu. Izmaiņu vadības process ir ilustrēts 5. attēlā.

5. attēls. Izmaiņu vadības process Izmaiņu pieprasījums tiek iesniegts un novērtēts, lai aprēķinātu tehniskus plusus, potenciālus blakus efektus, vispārējo ietekmi uz citiem konfigurācijas objektiem un sistēmas funkcijām, kā arī tā realizācijas izmaksas. Novērtējuma rezultāti tiek pasniegti kā izmaiņu ziņojums, ko izmanto izmaiņu vadības padome (IVP) - cilvēks vai grupa, kuri pieņem gala lēmumu par izmaiņas statusu un prioritāti. Saskaņotām izmaiņām tiek veidots inženieriskais izmaiņu pieprasījums, kas raksturo izmaiņas, kuras jāveic, un apskates un auditēšanas kritērijus. Kad izmaiņas ir realizētas, izmaiņu vadības mehānisms tiek izmantots nākamās programmatūras versijas sagatavošanā. "Bloķēšanas" un "atbloķēšanas" procesi implementē divus svarīgus izmaiņu vadības elementus - piekļuves vadību un sinhronizācijas vadību (6. attēls). Piekļuves vadība pārvalda, kurš no programmatūras izstrādātājiem ir tiesīgs piekļūt un izmainīt noteiktu konfigurācijas objektu. Sinhronizācijas vadība palīdz pārliecināties, ka paralēlas izmaiņas, kuras veic divi darbinieki, nepārklāj viena otru.

6. attēls. Piekļuves un sinhronizācijas vadības procesi Konfigurācijas audits Identifikācija, versiju vadība un izmaiņu vadība palīdz programmatūras izstrādātājiem uzturēt kārtībā to, kas citādi būtu haoss. Tomēr pat visveiksmīgākais vadības mehānisms izseko izmaiņai tikai, līdz inženieriskais izmaiņu pieprasījums ir izveidots. Kā mēs varam būt pārliecināti, ka izmaiņas ir pareizi īstenotas? Atbilde ir divēja: (1) izmantojot formālas tehniskas apskates un (2) veicot programmatūras konfigurācijas auditu. Programmatūras konfigurācijas audits papildina formālas tehniskas apskates, novērtējot konfigurācijas objektu raksturiezīmes, kurām netiek pievērsta uzmanība apskašu laikā. Audits uzdod un atbild uz sekojošiem jautājumiem: 1. Vai izmaiņu pieprasījumā iekļautās izmaiņas tika realizētas? Vai tika veiktas kādas papildus izmaiņas? 2. Vai tika veikta formāla tehniska apskate, lai novērtētu tehnisku pareizību? 3. Vai izstrādātāji strikti sekoja programmatūras izstrādes standartiem? 4. Vai izmaiņas tika iekļautas programmatūras konfigurācijas vienumos? Vai izmaiņu datums un autors tika ierakstīti? Vai konfigurācijas objekta atribūti atspoguļoti izmaiņās? 5. Vai izmaiņas bloķēšanā, atbloķēšanā un uzskaitīšanā ir sekots programmatūras konfigurācijas vadības procedūrām? 6. Vai visi konfigurācijas vienumi ir atbilstoši atjaunināti? Stāvokļa uzskaite Konfigurācijas stāvokļa uzskaite (dažreiz saukta par stāvokļa grāmatvedību) ir programmatūras konfigurācijas vadības uzdevums, kurš atbild uz šādiem jautājumiem: 1. Kas ir noticis? 2. Kurš to izdarīja?

3. Kad tas noticis? 4. Ko tas vēl ietekmēs? Informācijas plūsma šim procesam ir attēlota 5. attēlā. Konfigurācijas stāvokļa uzskaite spēlē vitālu lomu lielu programmatūras izstrādes projektu veiksmē. Kad projektā ir iesaistīti daudzi darbinieki, ļoti bieži gadās, ka "kreisā roka nezina, ko dara labā roka". Divi izstrādātāji var vienlaicīgi modificēt vienu un to pašu konfigurācijas vienumu. Tādējādi konfigurācijas stāvokļa uzskaite palīdz izvairīties no problēmām, uzlabojot komunikāciju starp iesaistītām pusēm.

16.1. Dokumenti programmizstrādes gaitā

16.2. Projekta uzsākšanas pārskats Unprintable file: I semestris/Kospekti/Sagataves/1.Projekta uzsaksana.doc

16.3. Projekta biznesa sfēras apraksts Unprintable file: I semestris/Kospekti/Sagataves/2.Biznesa sferas apraksts.doc

16.4. Projekta uzsākšanas rīkojums Unprintable file: I semestris/Kospekti/Sagataves/3.Projekta rikojums.doc

16.5. Projekta sfēra Unprintable file: I semestris/Kospekti/Sagataves/4.Projekta sfera.doc

16.6. Darba nostādnes Unprintable file: I semestris/Kospekti/Sagataves/5.Darba nostadne.doc

16.7. Projekta plāns Unprintable file: I semestris/Kospekti/Sagataves/6.Projekta plans.doc

16.8. Projekta kalendārais plāns Unprintable file: I semestris/Kospekti/Sagataves/7.Projekta kalendarais plans.mpp

16.9. Programmatūras prasību specifikācijas sagatave Programmatūras prasību specifikācijas sagatave LVS standarts - Informācijas tehnoloģija. Programmatūras prasību specifikācijas (PPS) ceļvedis (LVS 68:1996) - iesaka, izstrādājot projektējuma dokumentu, izmantot šādu sagatavi.

1. Ievads 1.1. Nolūks 1.2. Darbības sfēra 1.3. Definīcijas, akronīmi un saīsinājumi 1.4. Saistība ar citiem dokumentiem 1.5. Pārskats 2. Vispārējais apraksts 2.1. Produkta perspektīva 2.2. Produkta funkcijas 2.3. Lietotāja raksturiezīmes 2.4. Vispārējie ierobežojumi 2.5. Pieņēmumi un atkarības 3. Konkrētās prasības 3.1. Funkcionālās prasības 3.1.1. Funkcionālā prasība 1 3.1.1.1. Ievads 3.1.1.2. Ievade 3.1.1.3. Apstrāde 3.1.1.4. Izvade 3.1.2. Funkcionālā prasība 2 ..... 3.1.n. Funkcionālā prasība n 3.2. Ārējās saskarnes prasības 3.2.1. Lietotāja saskarne 3.2.2. Aparatūras saskarne 3.2.3. Programmatūras saskarne 3.2.4. Sakaru saskarne 3.3. Veiktspējas prasības 3.4. Projekta ierobežojumi 3.4.1. Atbilstība standartiem 3.4.2. Aparatūras ierobežojumi ..... 3.5. Atribūti 3.5.1. Drošība 3.5.2. Uzturamība ..... 3.6. Citas prasības 3.6.1. Datu bāze 3.6.2. Operācijas 3.6.3. Vietas adaptācija Atsauces Pielikumi Indekss

16.10. Projektējuma dokumentācijas sagatave Projektējuma dokumentācijas sagatave

LVS standarts - Informācijas tehnoloģija. Ieteicamā prakse programmatūras projektējuma aprakstīšanai (LVS 72:1996) - iesaka, izstrādājot projektējuma dokumentu, izmantot šādu sagatavi. 1. Ievads................................................................................................................................ 1.1. Nolūks......................................................................................................................... 1.2. Darbības sfēra.............................................................................................................. 1.3. Definīcijas un saīsinājumi.............................................................................................. 2. Saistība ar citiem dokumentiem........................................................................................... 3. Dekompozīcijas apraksts..................................................................................................... 3.1. Moduļu dekompozīcija.................................................................................................. 3.1.1. Pirmā moduļa apraksts........................................................................................... 3.1.2. Otrā moduļa apraksts............................................................................................. 3.2. Vienlaicīgo procesu dekompozīcija................................................................................. 3.2.1. Pirmā procesa apraksts.......................................................................................... 3.2.2. Otrā procesa apraksts............................................................................................ 3.3. Datu dekompozīcija...................................................................................................... 3.3.1. Pirmās datu entītijas apraksts................................................................................. 3.3.2. Otrās datu entītijas apraksts................................................................................... 4. Atkarības apraksts.............................................................................................................. 4.1. Starpmoduļu atkarības.................................................................................................. 4.2. Starpprocesu atkarības................................................................................................. 4.3. Datu atkarības.............................................................................................................. 5. Saskarnes apraksts............................................................................................................ 5.1. Moduļu saskarne.......................................................................................................... 5.1.1. Pirmā moduļa apraksts........................................................................................... 5.1.2. Otrā moduļa apraksts............................................................................................. 5.2. Procesu saskarne........................................................................................................ 5.2.1. Pirmā procesa apraksts.......................................................................................... 5.2.2. Otrā procesa apraksts............................................................................................ 6. Detalizētais projektējums.....................................................................................................

6.1. Moduļu detalizētais projektējums................................................................................... 6.1.1. Pirmā moduļa detalizējums..................................................................................... 6.1.2. Otrā moduļa detalizējums....................................................................................... 6.2. Datu detalizētais projektējums....................................................................................... 6.2.1. Pirmās datu entītijas detalizējums........................................................................... 6.2.2. Otrās datu entītijas detalizējums............................................................................. Atsauces...............................................................................................................................

16.11. Kvalitātes plāns Unprintable file: I semestris/Kospekti/Sagataves/8.Kvalitates plans.doc

16.12. Pagrieziena punktu pārskats Unprintable file: I semestris/Kospekti/Sagataves/9.Pagrieziena punktu parskats.doc

16.13. Iknēdeļas statusa atskaite Unprintable file: I semestris/Kospekti/Sagataves/10.Iknedelas statusa atskaite.doc

16.14. Mēneša progresa atskaite Unprintable file: I semestris/Kospekti/Sagataves/11.Menesa progresa atskaite.doc

16.15. Projekta riski Unprintable file: I semestris/Kospekti/Sagataves/12.Projekta riski.doc

16.16. Izmainu pieprasījums Unprintable file: I semestris/Kospekti/Sagataves/13.Izmainu pieprasijums.doc