dok/IS_tehniska_specifikacija_v_7_… · Web viewiespēja savienot dokumentus (MS Word, MS Excel, PDF) ar darba uzdevuma veidni un mainīt, ... HCMP IBM AIX vidē, Oracle Clusterware

Pielikums2015. gada 19. maijaKonkursa nolikumam

Nr. LZRA2015/1/K

TEHNISKĀ SPECIFIKĀCIJA (iepirkuma identifikācijas Nr. LZRA2015/1/K)

1. IEVADS 21.1. Konteksts un dokumenta mērķis.........................................................21.2. Iepirkuma mērķi un struktūra............................................................21.3. Izmantoto terminu definīcijas un skaidrojumi...........................................31.4. Izmantotie saīsinājumi....................................................................41.5. Saistītie dokumenti.......................................................................4

2. VISPĀRĪGS APRAKSTS52.1. Esošās situācijas raksturojums............................................................5

2.1.1. LZRA darbība..........................................................................................52.1.2. Nepieciešamība pēc Revīzijas Atbalsta Informācijas Sistēmas (RAIS)......................52.1.3. Revīzijas vai pārbaudes projekta darba procesa posmi.......................................6

2.2. Sistēmas darbības apraksts.............................................................102.2.1. RAIS programmatūras arhitektūra..............................................................102.2.2. Sistēmas lietotāji...................................................................................102.2.3. Sistēmas tehniskā arhitektūra...................................................................11

2.3. IS izveides un ieviešanas laika plāns....................................................12

3. IEPIRKUMA PRASĪBU APRAKSTS 133.1. Pakalpojuma izpildes prasības..........................................................13

3.1.1. Projekta organizatoriskās prasības.............................................................133.1.2. Sistēmas izveides, ieviešanas un uzturēšanas prasības.....................................15

3.2. Sistēmas funkcionālās prasības.........................................................193.2.1. RAIS sistēma........................................................................................193.2.2. Sistēmas integrācijas prasības...................................................................27

3.3. Sistēmas nefunkcionālās prasības..................................................................29

1. Ievads

1.1. Konteksts un dokumenta mērķis

1.2. Iepirkuma mērķi un struktūraIepirkuma mērķis ir nodrošināt veidojamās Revīzijas Atbalsta Informācijas Sistēmas (turpmāk RAIS) izstrādi vai pielāgošanu un ieviešanu. Šī iepirkuma ietvaros konkursa uzvarētājam būs jānodrošina RAIS informācijas sistēmas funkcionālo bloku izstrāde vai pielāgošana un ieviešana, veicot nākamajā tabulā aprakstīto komponenšu izstrādi un piegādi.1. tabula – Iepirkuma komponentes

Komponente Skaidrojums

RAIS sistēmas programmatūras izstrāde vai pielāgošana

Piegādātājs izstrādā vai pielāgo programmatūras funkcionālos blokus RAIS informācijas reģistrācijai, apstrādei, izvadei.

Galvenie funkcionālie bloki:• Klientu reģistrs;• Lietotāju reģistrs;• Veidņu datubāze un projektu veidu pārvaldība• Projektu izveide un pieņemšana;• Projekta faila izveide un apstrāde;• Projekta pabeigšana un arhivēšana;• Revīzijas procedūru loģikas izmaiņu pievienošana;• Lietotāju un sistēmas administrēšana.

RAIS sistēmas integrācija ar iekšējām un ārējām informācijas sistēmām

Piegādātājs izstrādā vai pielāgo integrāciju ar iekšējām un ārējām sistēmām.

Sagatavojot piedāvājumu, pretendentiem jāpiedāvā pilns risinājums visu 1. tabulā minēto un tehniskā specifikācijā aprakstītās prasības komponenšu darbības nodrošināšanai. Pretendentiem Piedāvājumā atsevišķi jānorāda un secīgi jāapraksta nākamajā tabulā minētās pozīcijas.

Komponente Piezīmes

Pretendenta izstrādātās programmatūras funkcionalitāte, atbilstoši tehniskā specifikācijā aprakstītajām prasībām

Jāiekļauj Pretendenta piedāvājumā

Pretendenta izmantojamās trešo pušu programmatūras komponentes Jāiekļauj Pretendenta piedāvājumā

Programmatūra datu apmaiņas nodrošināšanai ar ārējām un iekšējām IS

Jāiekļauj Pretendenta piedāvājumā

Aplikāciju serveru programmatūra Jāiekļauj Pretendenta piedāvājumā.

Datu bāzu vadības sistēmas licences Pretendentam jānodrošina risinājuma darbināšanai nepieciešamās DBVS licences, ņemot vērā Pasūtītāja esošo infrastruktūru.

Operētājsistēmas Nodrošinās Pasūtītājs. Pretendentam jāapraksta prasības pret OS, ņemot vērā Pasūtītāja esošo infrastruktūru.

Cita programmatūra Jebkāda papildus programmatūra, kas nepieciešam 2. un 3. nodaļā definēto prasību izpildei jāiekļauj Pretendenta piedāvājumā

Tehniskais nodrošinājums Nodrošinās Pasūtītājs. Pretendentam jāapraksta prasības pret

Komponente Piezīmes

tehnisko nodrošinājumu, ņemot vērā Pasūtītāja esošo un plānoto infrastruktūru.

Cits tehniskais nodrošinājums Jebkāds papildus tehniskais nodrošinājums, kas nepieciešam 2. un 3. nodaļā definēto prasību izpildei jāiekļauj Pretendenta piedāvājumā

1.3. Izmantoto terminu definīcijas un skaidrojumi2. tabula – Izmantoto terminu definīcijas un skaidrojumi

Termins Skaidrojums

Biznesa procesu izpildes valoda (Business Process Execution Language)

Biznesa procesu izpildes valoda (Business Process Execution Language). Valoda biznesa procesu aprakstīšanai un biznesa procesu mijiedarbības aprakstīšanai organizācijās un starp tām.

Klasifikators Vienas vai vairākas datu bāzes tabulas ar specializētas informācijas krājumu kāda lieluma sistematizēšanai.

Lietotāja saskarne Saskarne informācijas apmaiņai starp lietotāju un programmatūras komponentēm.

Metadati Dati, kas apraksta informāciju un dažādus tās parametrus.

Tīmekļa pakalpnes (Web services)

Vienots veids, lietojumprogrammu datu apmaiņai. Pārraidei tiek izmantoti tīmekļa protokoli. Tīmekļa pakalpnes nodrošina informācijas apmaiņas iespēju, nepārzinot otras iesaistītās sistēmas programmatūru. Pakalpojuma lietotājam ir svarīgi tikai saņemt konkrētu resursu, savukārt pakalpojuma sniedzējs var jebkurā brīdī brīvi izvēlēties, kādā valodā un platformā izstrādāt un darbināt nepieciešamos algoritmus.

Uz pakalpojumiem orientēta arhitektūra (Service Oriented Architecture)

Dizaina principu kopums, kas paredz iespēju izmantot tīmekļa tehnoloģijas, veidot modulārus pakalpojumus, kurus iespējams savstarpēji integrēt un atkārtoti izmantot, izmantojot vienotus datu apmaiņas principus (tīmekļa pakalpnes).

Web Tīmekļa vide, kura ar pārlūkprogrammas starpniecību var tikt darbinātas aplikācijas.

Klienti Mazo un vidējo revidentu uzņēmumu Klienti.

Projekts (engagement) Konkrēts darbs (revīzija vai pārbaude), kura rezultātā tiek sagatavots revidentu ziņojums

Projekta darba fails Sistemātiski dokumentētu ar projektu saistītu darba uzdevumu un dokumentu kopums

Darba uzdevums Darbs (revīzijas procedūra), kas tiek veikts projekta (engagement) ietvaros un kas nepieciešams revidentu ziņojuma sniegšanai; darba uzdevumi parasti tiek aprakstīti noteiktas formas veidnēs

Finanšu pārskats Klienta sagatavots finanšu pārskats, par kuru revidents sniedz atzinumu

Revidentu ziņojums Revidentu ziņojums par finanšu pārskatiem, kas atspoguļo veikto darbu

Finanšu pārskata komponente Finanšu pārskata sastāvdaļa (piemēram, bilances postenis, finanšu pārskata pielikums utt.)

Veidne(dokumenta veidne)

Iepriekš noteikts darba uzdevums, kas saglabāts sistēmā vai dokumenta veidnē, vai abos divos

Veidņu (template) datubāze Ilustratīvu darba uzdevumu un veidņu kopums, no kura darba uzdevumi vai veidnes var tikt importētas projekta failā

Ar revīzijas uzņēmumu saistīts superlietotājs

Revīzijas uzņēmuma superlietotājs/ administrators, kuru nosaka administrators (sistēmu administrators, kas saistīts nevis ar revīzijas uzņēmumu, bet gan ar vispārējo programmatūras administrāciju)

1.4. Izmantotie saīsinājumi3. tabula – Izmantotie saīsinājumi

Saīsinājums Skaidrojums

ASP Microsoft tīmekļa risinājumu izstrādes tehnoloģija (Active Server Pages)

DBVS Datu bāzes vadības sistēma

HTTP Tīmekļa informācijas pārraides protokols (Hyper text transfer protocol)

IKT Informācijas un komunikāciju tehnoloģijas

IS Informācijas sistēma

Pasūtītājs Latvijas Zvērināto Revidentu Asociācija (LZRA)

Piegādātājs Piegādes un ieviešanas tiesības ieguvušais iepirkuma konkursa Pretendents

PPA Programmatūras projektējuma apraksts

PPS Programmatūras prasību specifikācija

Pretendents Iepirkuma konkursa dalībnieki, no kuriem tiek atlasīts viens Piegādātājs

RAIS Revīzijas Atbalsta Informācijas Sistēma

SOA Uz pakalpojumiem (pakalpne) orientēta arhitektūra (Service Oriented Architecture)

SSO Single Sign-on

USPS Uzticams Sertifikācijas Pakalpojumu Sniedzējs

XML Paplašināma datu apraksta valoda (eXtensible Markup Language)

1.5. Saistītie dokumenti4. tabula – Saistītie dokumenti

Nr. p.k. Saīsinātais nosaukums Pilnais nosaukums

1. Metodoloģīja "Starptautisko Revīzijas standartu lietošanas rokasgrāmata mazu un vidēju uzņēmumu revīzijās" http://www.fm.gov.lv/lv/sadalas/gramatvedibas_un_revizijas_politika/projekts_tehniska_palidziba_finansu_parskatu_sagatavosana/tulkojumi/".

2. Likums par zvērinātajiem revidentiem

Likums “Par zvērinātajiem revidentiem”

http://www.fm.gov.lv/lv/sadalas/gramatvedibas_un_revizijas_politika/projekts_tehniska_palidziba_finansu_parskatu_sagatavosana/tulkojumi/

http://www.fm.gov.lv/lv/sadalas/gramatvedibas_un_revizijas_politika/projekts_tehniska_palidziba_finansu_parskatu_sagatavosana/tulkojumi/

2. Vispārīgs aprakstsŠajā sadaļā sniegts pārskats par esošo situāciju, kā arī aprakstīti IS mērķi un uzdevumi, kā arī funkcionālie bloki. Papildus tam sadaļa satur informāciju par IS izveides un ieviešanas laika plānu, kas Piegādātājam jāņem vērā, sagatavojot un iesniedzot piedāvājumu.

2.1. Esošās situācijas raksturojums2.1.1. LZRA darbība

Latvijas Zvērinātu revidentu asociācija (LZRA) ir neatkarīga profesionāla korporācija, kas dibināta 1994.gadā saskaņā ar likumu “Par zvērinātiem revidentiem”. Organizāciju dibināja 75 zvērināti revidenti, bet pirmsākumi Latvijā meklējami jau 1938.gada 12.jūlijā, kad Latvijas Republikas Ministru kabinets pieņēma un Valsts Prezidents izsludināja “Likumu par zvērinātiem revidentiem”. LZRA ir vienīgā profesionālā organizācija Latvijā, kas apvieno visus zvērinātos revidentus un zvērinātu revidentu komercsabiedrības.

Asociācijas kā neatkarīgas Latvijas zvērinātu revidentu profesionālās korporācijas mērķis ir īstenot zvērinātu revidentu profesionālo pašpārvaldi, lai veicinātu profesionālās kvalifikācijas paaugstināšanu, radošo spēju izkopšanu un pieredzes apgūšanu, kā arī rūpētos par savas profesijas prestižu un tiesisko aizsardzību. Asociācijas darbība ir vērsta uz likumā “Par zvērinātiem revidentiem” noteikto uzdevumu izpildi:

nodrošināt profesionālo standartu un ētikas normu, kā arī citu uz profesiju attiecināmo regulējošo normatīvo aktu ievērošanas un biedru profesionālās darbības uzraudzību;

pārstāvēt savu biedru intereses un aizstāvēt tās, organizēt zvērinātu revidentu kvalifikācijas eksāmenus, kā arī lemt par sertifikāta izsniegšanu zvērinātam revidentam un licences izsniegšanu zvērinātu revidentu komercsabiedrībai;

kārtot Zvērinātu revidentu reģistru un Zvērinātu revidentu komercsabiedrību reģistru;

izskatīt zvērinātu revidentu un klientu strīdus pēc strīdā iesaistītās puses pieprasījuma;

organizēt zvērinātu revidentu profesionālo apmācību un kvalifikācijas celšanu;

izstrādāt un iesniegt likumdošanas orgāniem rekomendācijas grāmatvedības standartu un revīziju jautājumos;

nodrošināt zvērinātu revidentu darbības kvalitātes kontroli.

2.1.2. Nepieciešamība pēc Revīzijas Atbalsta Informācijas Sistēmas (RAIS)

Dokumentējot savu darbu, mazie revīzijas uzņēmumi pārsvarā šobrīd rīkojas pēc saviem visai subjektīviem ieskatiem un prakses. Veikto darbu dokumentē atsevišķos failos (datnēs), taču nav visaptverošas vienotas sistēmas, kas sniegtu pārskatu par to, vai visi nepieciešamie darba uzdevumi ir paveikti un kādā darba izpildes stadijā tie atrodas. Turklāt atsevišķi dokumentu faili prasa daudz manuālā darba, kas bieži padara mazo revīzija uzņēmumu darbu neefektīvu.

Ņemot vērā iepriekš minēto, mazie revīzijas uzņēmumi nespēj risināt šo problēmu, patstāvīgi investējot attiecīgas programmatūras izstrādē. Latvijas Zvērināto Revidentu Asociācija vēlas izmantot pieejamo Latvijas un Šveices sadarbības programmas finansiālo atbalstu, lai izstrādātu speciālu revīzijas programmatūru, kas būtu pielāgota Latvijas tirgus vajadzībām un līdz ar to palielinātu gan šajā nozarē veiktā darba efektivitāti, gan kvalitāti.

Jaunās programmatūras ieviešana:

palīdzēs mazināt manuālo darbu un ļaus revidentiem veikt savu darbu efektīvāk;

uzlabos darba kvalitāti, jo darba procesi strukturēti noteiktā sistēmā;

vienkāršos uzraudzību, kā arī savstarpējo sadarbību un konsultācijas revidentu vidū, jo darbs tiek veikts, izmantojot līdzīgu sistēmu;

ļaus rast kopīgus risinājumus darba dokumentu arhivēšanai un citām problēmām, ko šobrīd katrs revidents risina individuāli; un

ļaus revīzijas uzņēmumiem apmainīties ar jaunām veidnēm, kā arī piedalīties to izstrādē.

LZRA plāno realizēt RAIS ieviešanas projektu un to RAIS piedāvāt mazajiem revīzijas uzņēmumiem kā maksas pakalpojumu, kur pirmajos 2 gados abonentmaksā tiktu iekļautas ar RAIS darbināšanu saistītās infrastruktūras un administrēšanas izmaksas, bet pēc 2 gadiem arī RAIS uzturēšanas izmaksas.

2.1.3. Revīzijas vai pārbaudes projekta darba procesa posmiŠajā nodaļā atspoguļoti darba procesa (revīzijas vai pārbaudes projekta) posmi un orientējošā darbu izpildes secība, kuru atbalstam tiek veidota RAIS.

1. attēls – Revīzijas un pārbaudes projekta galvenie darba procesa posmi

Darba uzdevuma posms

Uzdevumu piemēri

(RAIS sistēmā jādokumentē visu darba uzdevuma ietvaros veikto uzdevumu apraksts un rezultāti)

Papildu skaidrojums: Izstrādājamās sistēmas ietvaros un ārpus tās veiktais darbs (atsevišķi uzdevumi)

1.Klienta pieņemšana (akceptēšana)

1.1. Revidents izpēta par klientu pieejamo informāciju.

1.2. Revidents izvērtē atbilstību neatkarības, resursu, kvalifikācijas un citām prasībām, kuru izpilde nepieciešama darba pieņemšanai (akceptēšanai).

1.3. Revidents pieņem lēmumu par klienta akceptēšanu un paraksta pakalpojumu līgumu.

1.1. Galvenie klienta dati tiek reģistrēti RAIS sistēmā pieejamajā klienta kartiņā. Klienta izpētes gaitā iegūtā informācija tiek pievienota attiecīgajos failos (datnēs).

1.2. Veiktais darbs tiek dokumentēts ārējos failos (datnēs).

1.3. Lai pieņemtu lēmumu par darba pieņemšanu, tiek aizpildīta anketa, un lēmums par klienta akceptēšanu tiek pieņemts RAIS sistēmā. RAIS sistēma aizpilda līguma veidni ar klienta kartiņā ievadītajiem datiem.

2.Projekta plānošana 2.1. Revidents iegūst informāciju un aizpilda šādus 2.1. Klienta biznesa (uzņēmējdarbības vides) izpratne


Uzdevumu piemēri



dokumentus:

klienta biznesa izpratne, ārējo un iekšējo faktoru ietekme un saistītie riski;

nozīmīgu grāmatvedības uzskaites procesu, iekšējo kontroļu un saistīto risku izpratne.

(Ja darbs projekta ietvaros tiek veikts ilgtermiņā, veidnes tiek ņemtas no iepriekšējā gada projekta failiem (datnēm); veidnes tiek pārskatītas un, ja nepieciešams, atjauninātas.)

2.2. Revidents ievada galvenos finanšu pārskata datus (bilanci un peļņas vai zaudējumu aprēķinu) programmatūrā un savieno tos ar žurnālu/virsgrāmatu datiem, kas importēti no grāmatvedības programmas, kas satur grāmatvedības uzskaites līmeņa informāciju.

2.3. Revidents nosaka būtiskumu, pamatojoties uz finanšu pārskata rādītājiem.

2.4. Revidents izanalizē finanšu pārskatu un identificē jomas, kurās iespējamas būtiskas neatbilstības.

2.5. Revidents sagatavo risku kopsavilkumu un izvērtē to nozīmīgumu un iespējamo ietekmi.

2.6. Revidents sagatavo plānoto revīzijas procedūru izpildes grafiku atbilstoši identificētajiem riskiem (lielākā daļa uzdevumu tiek plānoti, pamatojoties uz finanšu pārskata komponentēm; jo lielāks skaits komponenšu, jo lielāks arī uzdevumu skaits).

2.7. Darba uzdevumi tiek nodoti izpildei darba grupas locekļiem.

tiek dokumentēta ārējā failā (datnē). Identificētie riski tiek ievadīti sistēmā, un to izvērtēšanas kopsavilkums tiek dokumentēts RAIS.

2.2. Rādītāji tiek ievadīti vai importēti RAIS.

2.3. Būtiskums tiek aprēķināts RAIS, izmantojot datus (rādītājus), kas minēti iepriekšējā apakšsadaļā (līdz 4-5 rādītājiem). Jābūt iespējai aprakstīt (noteikt) aprēķina procedūru/ formulu un sistēmā izmantotos rādītājus.

2.4. Riska jomas tiek ievadītas sistēmā finanšu pārskata posteņu līmenī. Veiktā atlase nosaka izlases kopu aprēķinu RAIS (jo augstāks risks, jo lielāka izlases kopa).

2.5. Visi riski tiek apkopoti RAIS vienuviet.

2.6. Darba uzdevumi, kas veicami, lai pārbaudītu finanšu pārskata komponentes, tiek noteikti, pamatojoties uz risku novērtējumu. Parasti ar finanšu pārskata posteņu pārbaudi saistītie uzdevumi ir standarta un iepriekš noteikti. Attiecībā uz konkrēto uzdevumu RAIS jāietver šāda informācija: posteņa summa, riska novērtējuma rezultāts, pieeja un kopsavilkums. Tālāk testi tiek dokumentēti ārējos MS Word un Excel failos (veidnēs). Ielādējot uzdevumus no veidņu datubāzes, jābūt iespējai izvēlēties, kuras veidnes ielādēt un kuras ne (iespējām jābūt piedāvātām sazarotas koka struktūras veidā, lai varētu izvēlēties vai nu visas testa veidnes, kas attiecas uz konkrēto posteni, vai tikai dažas no tām (atbilstošās)). Jābūt iespējai no veidņu datubāzes vēlāk ielādēt papildu uzdevumus un veidnes.

2.7. Katrs darba uzdevums tiek uzticēts personai, kas ir atbildīga par tā izpildi.

RAIS var ietvert masveida darba uzdevumu iespēju (piemēram, revidents izvēlas kādas personas vārdu un pievienot tam vairākus uzdevumus un ar šo uzdevumu saistītus dokumentus).

3. Revīzijas pierādījumu iegūšana

3.1. Revidents vai revidenta asistenti iegūst pierādījumus, lai gūtu pārliecību, ka finanšu pārskatā kopumā vai finanšu pārskata komponentēs nav būtisku neatbilstību. Šādus pierādījumus var iegūtu, izmantojot dažādas metodes (testus vai kontroles, substantīvas analītiskas procedūras, detalizētas pārbaudes). Identificētās neatbilstības tiek atsevišķi reģistrētas darblapā. Pēc darba uzdevuma pabeigšanas par to atbildīgā persona atzīmē tā statusu kā „pabeigts”

3.1. RAIS tiek uzskaitīti darba uzdevumi (darba mērķis, apraksts un pabeigšana) un norādīta informācija par to, vai attiecīgie darba uzdevumi ir pabeigti un pārbaudīti. Praktiski tas tiek darīts, izmantojot darba uzdevumiem pievienotos MS Word un Excel failus.


Uzdevumu piemēri



(nepabeigts darba uzdevums varētu tikt iezīmēts „dzeltens”, bet pabeigts – „zaļš”. Kad par darba uzdevuma izpildi atbildīgā persona atzīmējusi darba statusu kā „pabeigtu” (zaļš), sistēmai automātiski jāizveido un jāpievieno pabeigšanas datums.

3.2. Zvērināts revidents pārbauda visus pabeigtos darba uzdevumus un tiem pievienotos dokumentus (pārbaude tiek reģistrēta kopā ar pārējo ar darba uzdevumu saistīto informāciju – pārbaudītais darba uzdevums varētu tikt iezīmēts „zils”). Ja nepieciešams, revidents pievienos dokuments un jautājumus par darba uzdevuma izpildi atbildīgajai personai, kura vēlāk atbildēs uz šiem jautājumiem vai veiks papildu darbu/uzlabos jau veikto darbu. Kad pārbaudītājs ir atzīmējis darba uzdevumu kā „pārbaudīts”, bet par darba uzdevumu atbildīgā persona pēc tam mainījusi ievadīto informāciju par šo darbu, attiecīgā darba statuss un apzīmējums automātiski tiek mainīts uz „nepabeigts” (par darba uzdevuma izpildi atbildīgajai personai un pārbaudes veicējam atkal jāatzīmē daba statuss kā „pabeigts” un „pārbaudīts”).

3.3. Revidents apkopo visus finanšu pārskatā veiktos labojumus un visas neizlabotās neatbilstības un kļūdas.

3.2. Katra dokumenta un darba uzdevuma metadati RAIS ietver norādi par to, vai attiecīgais dokuments vai darba uzdevums ir pārbaudīts. Ja pārbaudes laikā rodas kādi jautājumi (tiek izteikti kādi komentāri), attiecīgajam darba uzdevumam tiek pievienots jautājums (statuss: neatbildēts jautājums), uz kuru par darba izpildi atbildīgajai personai ir jāpievieno atbilde/komentārs (atbildēts jautājums). Pēc tam pārbaudes veicējs atzīmē jautājumu kā atbildētu (slēdz jautājumu). Programmai jābūt skatījumam, kas parādītu tā saucamās neatrisinātās problēmas (jautājumus un komentārus) kopā ar saiti uz attiecīgo darba uzdevumu vai dokumentu.

3.3. Projekta ietvaros identificētās neatbilstības tiek ievadītas RAIS manuāli (neatbilstības summa, skartie debeta un kredīta grāmatojumi, norāde par to, vai projekta laikā neatbilstība novērsta vai ne, utt.). Ņemot vērā neatbilstību labojumus, programma aprēķina finanšu pārskata posteņa galīgās summas.

Ievadot finanšu pārskata posteņus, tiek pārbaudīts, vai revidentam ir zināmi visi projekta laikā veiktie labojumi un korekcijas.

4. Secinājumu izdarīšana un atzinuma formulēšana

4.1. Neatbilstību ietekmes un būtiskuma izvērtēšana

4.2. Papildu analītisko procedūru veikšana un novērtējums par to, vai plānošanas posmā veiktais risku izvērtējums paliks nemainīgs

4.3. Secinājumu dokumentēšana un lēmuma pieņemšana par sniedzamā revīzijas atzinuma veidu

4.4. Apliecinājuma vēstules sagatavošana, kas klienta vadībai jāparaksta līdz ar finanšu pārskatu

4.5 Revidentu ziņojuma sniegšana

4.1. Pēc būtības neatbilstību ietekmes izvērtēšana nozīmē iepriekš izstrādātu anketu ar atbilžu variantiem aizpildīšanu attiecībā uz katru finanšu pārskata posteni un katru neatbilstību.

4.2. Finanšu rādītāji RAIS tiek aprēķināti, pamatojoties uz galīgajām finanšu pārskatā atspoguļotajā summām. Visas nozīmīgās izmaiņas tiek analizētas, salīdzinot galīgās summas ar iepriekš aprēķinātajām.

4.3. Pēc būtības secinājumu dokumentēšana nozīmē iepriekš izstrādātu anketu ar atbilžu variantiem aizpildīšanu un galīgā slēdziena formulēšanu.

4.4. Vēstule, kurā sniegts rakstisks vadības apliecinājums, ir ārējs dokuments (jābūt iespējai tai pievienot RAIS ģenerētu nekoriģēto/neizlaboto neatbilstību kopsavilkumu).

4.5 Revidenta ziņojums ir ārējs dokuments.

5. Darbības projekta pabeigšanai

5.1. Projekta slēgšana un arhivēšana 5.1. Projekta slēgšana un arhivēšana ir RAIS funkcionalitātes. Pirms arhivēšanas sākšanas sistēmai automātiski jāpārbauda, vai visi darba uzdevumi


Uzdevumu piemēri



5.2. Jebkādas izmaiņas, kas veiktas pēc arhivēšanas, jādokumentē kopā ar attiecīgiem paskaidrojumiem.

apzīmēti kā „pabeigti” un „pārbaudīti” un, ja nē, sistēmai jāģenerē kļūdas paziņojums, un arhivēšanu nevar sākt.

RAIS jāreģistrē slēgšanas un arhivēšanas datums. Pēc arhivēšanas pabeigšanas visiem programmas skatījumiem un visiem pievienotajiem dokumentiem jābūt aizsargātiem pret izmaiņām (tiem jābūt pieejamiem tikai lasīšanas režīmā “read only”).

5.2. Izmaiņas datos vai dokumentos, kas saglabāti RAIS, var tikt veiktas tikai izņēmuma gadījumos. Tādā gadījumā, sistēmai jāatspoguļo, kurš ir veicis attiecīgās izmaiņas, kas ir mainīts un kad šīs izmaiņas veiktas.

2.2. Sistēmas darbības apraksts2.2.1. RAIS programmatūras arhitektūra

Šī projekta Sistēmas programmatūras arhitektūru veidos viens pamatbloks – RAIS Informācijas Sistēma, kā arī izstrādāta datu pārnešanas funkcionalitāte ar vismaz 6 populārākajām grāmatvedības programmām Latvijā.

2.2.2. Sistēmas lietotājiRAIS izmantos vairākas lietotāju grupas, kurām nepieciešamā funkcionalitāte kā arī funkcijas atspoguļotas nākamajā tabulā.

5. tabula –RAIS lietotāju grupas

Lietotāju grupa Funkcionalitāte

Administratori • Vispārējā sistēmas administrēšana;• Superlietotāju izveide un lomu piešķiršana.

Superlietotāji • Jaunu lietotāju izveide revīzijas uzņēmumam, lietotāju piekļuves tiesību (lomu) noteikšana atsevišķu revīzijas vai pārbaudes projektu realizācijai.

Lietotāji • Sistēmas standarta lietojums – var tikt piešķirtas dažādas lomas atkarībā no pozīcijas konkrēta revīzijas vai pārbaudes projektā.

• Lietotāju un viņu tiesību un privilēģiju administrācija (lietotājs var vienlaikus būt iesaistīts dažādos projektos, kuros viņam vai viņai ir dažādas lomas un līdz ar to lietotājam var būt dažādas lietotāja tiesības). Daži projektā pildāmo lomu piemēri (bet ne visi) (saraksts hierarhiskā secībā), kur katram nākamam (augstākam) līmenim ir visas iepriekšējo līmeņu tiesības un privilēģijas:

• Projekta partneris (zvērināts revidents, atbildīgs par projektu kopumā): visas tiesības, plus var pievienot vai izslēgt lietotājus;

• Projekta vadītājs: var pievienot un pārbaudīt uzdevumus un pārvaldīt veidnes;

• Revidenta asistents: var papildināt informācija savu darba uzdevumu ietvaros; var atlasīt paša veicamos darbus, pievienot pierādījumus (failus uzdevumiem) un pārbaudīt tā paša līmeņa vai zemāku līmeņu revidentu darbu;

• Novērotājs: var tikai skatīt datus.

• Lietotāji tiek izveidoti katram revīzijas uzņēmumam atsevišķi (ja revīzijas uzņēmumi glabā datus vienā un tajā pašā serverī, viens un tas pats lietotājs var tikt aprakstīts vairāku revīzijas uzņēmumu ietvaros).

Piezīme: Lietotāju grupas un lomas var tikt precizētas PPS / PPA izstrādes laikā.

2.2.3. Sistēmas tehniskā arhitektūraInformācija šajā sadaļā ir paredzēta Pretendentiem informācijai par plānoto RAIS tehnisko arhitektūru, kas jāņem vērā, izstrādājot vai pielāgojot RAIS programmatūras komponentes.

Risinājums jāveido vairākiem tehnoloģiskajiem elementiem, lai nodrošinātu RAIS paredzēto funkciju uzturēšanu. Nākamajā attēlā ir sniegts vispārīgs paredzētās sistēmas tehniskās arhitektūras attēlojums.

2. attēls – RAIS sistēmas tehniskā arhitektūra

Paredzams, ka sistēmas darba nodrošināšanai būs pieejamas šādas tehnoloģiskās komponentes:► RAIS aplikāciju serveri. Viens vai vairāki serveri ar instalētu aplikāciju servera programmatūru,

kas veiktspējas un nepārtrauktības nodrošināšanai darbojas klastera režīmā.

► RAIS sistēmas DB serveris. Viens vai vairāki datu bāzes serveri ar instalētu DBVS programmatūru, kas veiktspējas un nepārtrauktības nodrošināšanai darbojas klastera režīmā. Gadījumā, ja risinājuma izveidei būs ierobežoti resursi, jāpastāv iespējai izmantot vienu datu bāzes serveri, nodrošinot sistēmas paplašināšanas iespēju, nākotnē veidojot datu bāzes klasteri.

► Testu serveri. Testu serveri tiks izmantoti RAIS jauninājumu testiem, pirms izmaiņu pārnešanas uz RAIS ekspluatācijas vidi. Testa serveru darbība var tikt nodrošināta uz viena fiziska servera, veidojot virtuālos serverus (datu bāzei, aplikāciju serverim, tīmekļa saskarnei un pakalpnēm) pēc nepieciešamības.

► Datu pārraides tikla komponentes – Pasūtītājs nodrošinās risinājuma darbināšanai esošos datu pārraides tīkla aktīvos (tīkla adapterus, centrmezglus, komutatorus, tiltus un maršrutētājus) kā arī pasīvos elementus. Piegādātājam ir jāiepazīstas ar Pasūtītāja rīcībā

esošo datu pārraides infrastruktūru un ātrumu, nepieciešamības gadījumā sagatavojot ieteikumus tās pilnveidošanai.

Nākamajā tabulā ir apkopota informācija par datu apmaiņu:

6. tabula – Projekta ietvaros izstrādājamā datu apmaiņa ar sekojošām datu kopnēm

Sistēma Datu kopne Īss apraksts

Grāmatvedības programmas (vismaz 6)

• Grāmatvedības dati Nepieciešams nodrošināt importēt programmatūrā žurnālu/grāmatu datus (konta nr., sākuma atlikums, beigu atlikums, debets un kredīts) no grāmatvedības programmas (ievaddati var būt xls, xlsx, txt (tab delimited), csv formātā).

RAIS izstrādes procesā importēšanai nepieciešamie modeļi jāizveido vispopulārākajām grāmatvedības programmām (vismaz 6); datu importēšana no citām grāmatvedības programmām tiks veikta, importējot datus no iepriekš formatētas Excel tabulas.

2.3. IS izveides un ieviešanas laika plāns Sākotnēji projektu ir plānots realizēt līdz 2015. gada septembra beigām. Atbilstoši programmatūras izstrādes un ieviešanas dzīves ciklam projektu plānots veikt sekojošos darbu posmos. Plānotie projekta darbu posmi un to sākotnējais laika plāns shematiski attēlots nākamajā tabulā.7. tabula – RAIS izveides un ieviešanas laika plāns

Projekta darbu posms

2015.gads 2017.gads

5 6 7 8 9 1 1 1 1 2 3 4 5 6 7 8 9 1 1 1

1. posms. RAIS PPS / PPA izstrāde, prototipa izstrāde un demonstrēšana X

2. posms. RAIS piegāde un pielāgošana X

3. posms. RAIS testēšana X X

4. posms. RAIS ieviešana un konfigurēšana (t.sk. tehnisko resursu piegāde, uzstādīšana un konfigurēšana)

X

5. posms. RAIS sistēmas galveno lietotāju apmācības X X

Projekta noslēgums X

RAIS bezmaksas uzturēšana un garantija (24 mēneši) X X X X X X X X X X X X X

3. Iepirkuma prasību aprakstsŠajā sadaļā sniegts RAIS un ar tās izveidi un ieviešanu saistīto prasību detalizēts izklāsts. Pretendentiem jānodrošina turpmāk tekstā izklāstīto prasību izpilde un savos piedāvājumos jāsniedz apliecinājumi konkrēto prasību izpildei, kā arī paskaidrojumi par to, kā tiks nodrošināta attiecīgo prasību izpilde tādā detalizācijas līmenī, kas:

► demonstrētu Pretendenta izpratni par attiecīgo prasību izpildi;

► dotu iespēju konkursa komisijai izvērtēt piedāvātā risinājuma pamatotību un atbilstību Pasūtītāja vajadzībām.

3.1. Pakalpojuma izpildes prasības3.1.1. Projekta organizatoriskās prasības

RAIS izveide, ieviešana un RAIS komponenšu uzturēšana realizējams kā vienots projekts, kurš jāpārvalda, ņemot vērā starptautiskos standartos aprakstītās pieejas un metodes IT projektu vadībā un pielāgojot to Pasūtītāja specifikai.8. tabula – O Projekta organizatoriskās prasības

Nr. Prasība Apraksts

O1. Projekta pārvaldība

O1.1. Projekta organizatoriskā struktūra

Piegādātājam projekta realizācijā tā organizatoriskā struktūra jāpiedāvā, paredzot vismaz šādas detalizācijas struktūru:• Projekta uzraudzības komisija (izveidojama pēc nepieciešamības par to vienojoties

ar Pasūtītāju), kuras sastāvā ietilpst Pasūtītāja un Piegādātāja vadības pārstāvji, kā arī var Pasūtītājs tās sastāvā var uzaicināt citu projektā iesaistīto pušu pārstāvjus. Projekta uzraudzības komisijas sēdēs izvērtēta projekta vadības grupas sniegtā informācija par projekta īstenošanas progresu, analizēti potenciālie projekta pasākumu īstenošanas riski, analizētas problēmas projekta īstenošanā, kā arī pieņemti lēmumi par nepieciešamību veikt projektā grozījumus. Gadījumos, kad ir konstatētas domstarpības vai radušās problēmas projekta vadības grupas un Piegādātāja vai citu sadarbības partneru starpā, projekta uzraudzības komisija Pasūtītājam sniedz rekomendējoša rakstura problēmas risinājuma piedāvājumu.

• Projekta vadības grupa, kuras sastāvā ietilpst Pasūtītāja un Piegādātāja projekta vadītāji un vadošie speciālisti. Projekta vadības grupa informē projekta uzraudzības komisiju par projekta statusu un progresu, nodrošina nepieciešamo projekta virzību un detalizētu projekta pasākumu plānošanu atbilstoši projekta uzraudzības padomē nolemtajam, kā arī nodrošina citu projekta vadības aspektu ikdienas vadību.

• Projekta darba grupas, kuru sastāvā ietilpst konkrēto darba pakešu piegādei nepieciešamie speciālisti gan no Piegādātāja, gan no Pasūtītāja puses. Projekta vadības grupa nosaka, kāda veida projekta darba grupas izveidojamas. Projekta darba grupa ir atbildīga par konkrētu darbu izpildi atbilstoši projekta vadības grupas uzstādījumiem. Projekta darba grupas projekta vadības grupai regulāri sniedz pārskatus par veicamo darbu statusiem un progresu.

Pretendentam jāpiedāvā detalizēts projekta organizatoriskais modelis.

O1.2. Projekta komunikācijas vadība Pretendentam jāapraksta piedāvātā pieeja projekta komunikācijas vadībai visos organizatoriskās struktūras līmeņos.

O1.3. Projekta kvalitātes vadība Piegādātājam jāveic nepieciešamie pasākumi, lai nodrošinātu projekta kvalitātes vadību atbilstoši labās prakses principiem, t.sk., bet ne tikai:• pirms visu dokumentu nodevumu izstrādes uzsākšanas Piegādātājs saskaņo

dokumentu nodevumu sagatavju ar Pasūtītāju;• kopēja izstrādes un ieviešanas procesa kvalitātes nodrošināšana;• nodevumu savlaicīga iesniegšana Pasūtītājam saskaņošanai;• projekta risku savlaicīga un regulāra identificēšana un attiecīga eskalācija.


Pretendentam jāapraksta piedāvātā pieeja projekta kvalitātes vadības nodrošināšanai.

O1.4. Projekta izmaiņu vadība Pretendentam jāpiedāvā projekta izmaiņu vadības modelis, kas paredz vairāku līmeņu projekta izmaiņu izskatīšanu un eskalāciju atbilstoši šo izmaiņu nozīmīgumam un ietekmei uz projekta laika, finanšu un citiem resursiem, kā arī uz projekta apjomu.

O1.5. Projekta vadības standarti un metodoloģijas

Projekta pārvaldība nodrošināma atbilstoši kādam no starptautiski atzītiem nozares standartiem projektu pārvaldības jomā (piemēram, PRINCE2, PMBOK).

O1.6. Programminženierijas labās prakses izmantošana

Piegādātājam projekta realizācijā jāvadās pēc programminženierijas standartiem un labākās prakses:• Latvijas valsts standarti, kas nosaka programmatūras un programmatūras izstrādes

procesa dokumentēšanu dažādās tās attīstības stadijās, kā arī programmatūras kvalitātes nodrošināšanas pasākumu veikšanu;

• Standard for Information Technology. Software Life Cycle Processes. Software Development. Acquirer-Supplier Agreement (IEEE J-STD-016), starptautisks standarts, kas nosaka visa programmatūras dzīves cikla procesus, nepieciešamo dokumentāciju un tās saturu;

• Information technology – Software life cycle processes (ISO/IEC 12207:2008), starptautisks standarts, kas nosaka programmatūras dzīves cikla procesus;

• kvalitātes vadības sistēmas standarts ISO/IEC 9001.

O1.7. Projekta darba valoda Projekta darba valoda ir latviešu vai angļu valoda. Piegādātājam dokumentālie nodevumi izstrādājami latviešu vai angļu valodā.Projekta laikā iespējama speciālistu piesaiste, kuri nepārvalda latviešu vai angļu valodas, šādā gadījumā Piegādātājam šo speciālistu saziņā ar Pasūtītāju jānodrošina tulkošana bez papildu maksas.Atsevišķi projekta dokumentālie nodevumi, iepriekš saskaņojot ar Pasūtītāju, var tikt izstrādāti kādā svešvalodā.

O2. Projekta dokumentācija

O2.1. Interviju un tikšanās protokoli/kopsavilkumi

Pasūtītājs nodrošinās projekta uzraudzības komisijas un projekta vadības grupas sēžu protokolēšanu.Piegādātājam jānodrošina darba grupu sanāksmju un (vai) citu tikšanos protokolēšanu (pierakstu veidošanu par pieņemtajiem lēmumiem) un saskaņošanu ar tikšanās reizē iesaistītajām pusēm.

02.2. Projekta pārvaldības plāns Piegādātājam atbilstoši piedāvātajam Projekta pārvaldības modelim jānodrošina Projekta pārvaldības plāna sagatavošana un uzturēšana.

O2.3. Progresa/statusa ziņojumi Projekta progresa/statusa ziņojumi izstrādājami un iesniedzami Pasūtītājam saskaņā ar noteikto projekta organizatorisko struktūru.

O3. Projekta laika plāns

O3.1. Projekta posmi un to izpildes termiņi

Projekta realizācija Piegādātājam jānodrošina saskaņā ar tehniskās specifikācijas sadaļā aprakstīto IS izveides un ieviešanas laika plānu.

O3.2. Projekta posmu realizācijai nepieciešamie resursi

Piegādātājam jānodrošina visu projekta realizācijai nepieciešamo resursu pieejamība visu projekta laiku pilnvērtīgai, savlaicīgai un kvalitatīvai projekta realizācijai.

O3.3. Projekta laika plāna aktualizēšana

Pretendentam jāsniedz precizēts un detalizēts projekta laika plāns, kurā ņemtas vērā Pretendenta resursu un citu piedāvājumā izklāstīto aspektu ietekme uz projekta izpildi.Precizētajā projekta laika plānā visu darbu izpilde jāparedz ne vēlāk kā tehniskajā specifikācijā aprakstītajā IS izveides un ieviešanas laika plānā.Projekta realizācijas laikā izmaiņas projekta laika plānā veicamas caur projekta izmaiņu vadības mehānismu.


O4. Projekta nodevumi

O4.1. Sistēmas dokumentācija Piegādātājam RAIS piegādes, pielāgošanas un ieviešanas projekta laikā jāveic vismaz šādas dokumentācijas izstrāde:• „RAIS programmatūras prasību specifikācija”;• „RAIS programmatūras projektējuma apraksts sistēmas moduļu izstrādei un

ieviešanai”;• „RAIS piegādes, pielāgošanas un ieviešanas plāns”;• „RAIS testēšanas plāns un apkcepttestu piemēri”;• „RAIS testēšanas kopsavilkums pārskats”;• „RAIS lietotāju rokasgrāmata”;• „RAIS administratora rokasgrāmata” (t.sk. RAIS programmatūras un citu komponenšu

uzstādīšanas (instalēšanas), konfigurēšanas un darbības atjaunošanas instrukcijas) ;• "RAIS nepārtrauktas darbības nodrošināšanas plāns";• „RAIS ekspluatācijas noteikumi”;• „RAIS drošības risku pārvaldības plāns”.• pārskati un prezentācijas par katra posma ietvaros veiktajiem darbiem.

Sistēmas dokumentācijas komplektam jābūt pilnīgam tādā izpratnē, lai:• trešajām pusēm būtu iespējams pārliecināties par to, ka sistēmas izstrāde, piegāde

un ieviešana ir notikusi saskaņā ar izvirzītajām prasībām un nozares labo praksi;• sistēmas lietotājiem tiek sniegta visa nepieciešamā informācija, lai viņi patstāvīgi un

pilnvērtīgi varētu izmantot sistēmas piedāvāto funkcionalitāti;• sistēmas administratoriem ir pieejama nepieciešamā informācija par sistēmas

nepārtrauktu darbības nodrošināšanu atbilstoši sistēmas specifikai.Sistēmas dokumentācijas saraksts var tikt precizēts projekta gaitā.

O4.2. RAIS programmatūras nodevumi

Piegādātājam pēc RAIS piegādes, pielāgošanas un ieviešanas projekta jāiesniedz Pasūtītājam izstrādāto programmatūras risinājumu un gatavās programmatūras licences, pielāgojumu pirmkodi, izpildkodi, instalācijas pakotnes un programmatūras versijas apraksts.

3.1.2. Sistēmas izveides, ieviešanas un uzturēšanas prasības9. tabula – (V) Sistēmas izveides, ieviešanas un garantijas prasības


V1. Sistēmas prasību analīze un projektējuma izstrāde

V1.1. Esošās situācijas analīze un detalizēta prasību analīze

Piegādātājam jāiepazīstas ar esošo situāciju saistībā ar RAIS izstrādi un papildināšanu apjomā, kas nepieciešams RAIS PPA un PPS izstrādei (t.sk. jāiepazīstas ar normatīvajiem aktiem, procesu aprakstiem un citu dokumentāciju, kā arī jāveic intervijas ar Pasūtītāja norādītajām personām, lai gūtu pilnīgu izpratni par revidentu darbu un ar to saistītajām procedūrām).Veicot šo aktivitāti, Piegādātājs apraksta pasūtītāja biznesa procesus tādā detalizācijas pakāpē, lai aprakstus varētu izmantot RAIS sistēmas izveidei.

V1.2. IS konceptuālā projektējuma izstrāde un saskaņošana

Kā starpposmu PPS izstrādē Piegādātājs sagatavo īsu IS konceptuālā projektējuma aprakstu, kurā ir izklāstīti IS konceptuālie risinājumi (precizējot savu piedāvājumu atbilstoši analīzes rezultātiem) un kurā tiek aprakstītas risinājuma komponentes, to savstarpējā saistība, sistēmas funkcionalitāte un dalījums funkcionālajos moduļos, datu bāzes loģiskā shēma, iekšējās un ārējās saskarnes, sistēmas ieviešanas pieeja u.c. risinājuma elementi.Konceptuālais projektējums jāprezentē tam un jāsaskaņo ar Pasūtītāju.Pamatojoties uz saskaņoto konceptuālo projektējumu, Piegādātājam jāsagatavo pārējās IS prasības.Konceptuālais projektējums, kas saturēs precizētu aplikācijas un tehnisko arhitektūru, kas ir iekļaujama PPS kā atsevišķa sadaļa.


V1.3. Prasību identifikācija un trasējamība

PPS un PPA noteiktās prasības jāidentificē ar unikāliem identifikatoriem.Sistēmas pielāgošanas, piegādes un ieviešanas gaitā jābūt iespējai trasēt konkrētās prasības īstenošanu visā RAIS projekta dzīves cikla laikā.

V1.4. Detalizācijas pakāpe PPS un PPA jāizstrādā vismaz tādā detalizācijā, kas ir pietiekama, lai Pasūtītājam būtu iespējams uzturēt un administrēt RAIS sistēmu.PPS jāsagatavo tādā detalizācijas pakāpē, kas nodrošina pilnvērtīgu RAIS funkcionalitātes realizāciju. Prasībām jābūt pilnīgām, verificējamām un nepretrunīgām.Ja Piegādātājam ir nepieciešama pilnīgāka informācija par Pasūtītāja vajadzībām, Piegādātājs šo informāciju precizē vai specificēt un papildina dokumentāciju.

V1.5. Atbilstība tehnisko specifikāciju prasībām (biznesa)

Izstrādājot PPS un PPA, Piegādātājam jānodrošina PPS un PPA atbilstība šajā tehniskajā specifikācijā noteiktajām (biznesa) prasībām, kā arī detalizētas prasību analīzes laikā identificētajām Pasūtītāja vajadzībām un prasībām.Atkāpes no tehniskajā specifikācijā noteiktajām prasībām ir iespējams tikai formāla izmaiņu pārvaldības procesa rezultātā.

V1.6. Pielāgošanas, piegādes un ieviešanas plāna sagatavošana

Piegādātājs sagatavo un saskaņo ar Pasūtītāju RAIS izveides un ieviešanas plānu, kurā, ņemot vērā esošās situācijas analīzi un IS ieviešanas posmus, tiek precizēts piedāvājumā izklāstītais RAIS izveides un ieviešanas plāns (precizējot laika plānojumu, RAIS ieviešanas posmus, finanšu un cilvēkresursus, ieviešanas kārtu funkcionalitāti un citus ar RAIS ieviešanu saistītus aspektus).

V2. Sistēmas izveide

V2.1. Sistēmas funkcionalitātes izveide

Piegādātājam jāveic RAIS funkcionalitātes izveide atbilstoši tehniskās specifikācijas un projektējuma (PPS un PPA) prasībām.

V2.2. Saskarņu ar citām sistēmām izstrāde

Piegādātājam jāveic RAIS saskarņu izstrāde informācijas apmaiņai ar citām informācijas sistēmām saskaņā ar tehniskajā specifikācijā un izstrādātajā PPS un PPA noteiktajām prasībām.

V2.3. Sistēmas izstrādes vide Ja nepieciešama atsevišķu komponentu izstrāde, Piegādātājam jānodrošina sava izstrādes vide, izmantojot savus resursus.

V3. Datu migrācija

V3.1. Datu migrācija Datu migrācija projektā netiek plānota, taču Piegādātājam jāizvērtē iespējas atsevišķus datus pārnest no esošajām Pasūtītāja sistēmām. Datu migrācijas veikšanas gadījumā piegādātājam jāsastāda plāns, norādot kā tieši tiks validēta datu integritāte (nemainība) pirms un pēc migrācijas, un jāiekļauj tas sistēmas testu plānā.

V4. Sistēmas testēšana

V4.1. Testēšanas dokumentācija Piegādātājam jānodrošina vismaz šāda testēšanas dokumentācija, kas apliecina Piegādātāja veikto RAIS testēšanas apjomu saskaņā ar standartu LVS 70:1996 "Informācijas tehnoloģija. Programminženierija. Programmatūras testēšanas dokumentācija":• testēšanas plāns;• testu projektējuma specifikācija;• testpiemēra specifikācija;• testēšanas procedūras specifikācija;• testējamā vienuma pavadzīme;• testēšanas žurnāls;• testa problēmas ziņojums;• testēšanas kopsavilkuma pārskats.Piegādātājam jānodrošina iepriekš minētās dokumentācijas pieejamība Pasūtītājam pēc Pasūtītāja pieprasījuma.

V4.2. Testēšanas apjoms Piegādātājam jānodrošina RAIS testēšana, kas aptver pilnvērtīgu testu veikšanu visām RAIS komponentēm, gan arī šo komponenšu savstarpējai darbībai un RAIS integrācijas pārbaudēm (testiem) datu apmaiņai ar citām informācijas sistēmām.

V4.3. Testu vide Piegādātājam ir jāveic testa vides prasību sagatavošana. Pasūtītājs nodrošina testa vides


izveidi sistēmas ieviešanas laikā līdz sistēmas pieņemšanai ekspluatācijā un darbināšanai ekspluatācijas vidē.

V4.4 Akcepttestēšana Piegādātājam jānodrošina testa vides sagatavošana Pasūtītāja vidē (kas pēc tehniskiem parametriem atbilst paredzamai darba videi), kā arī nepieciešamais atbalsts Pasūtītājam, lai Pasūtītājs varētu veikt akcepttestēšanu.

V4.5. Akcepttestēšanas procedūra un plāns

Piegādātājs sagatavo un saskaņo ar Pasūtītāju RAIS akcepttestēšanas procedūru un plānu, kurā tiek aprakstīta akceptēšanas kārtība un kritēriji, kā arī akcepttestēšanas testi.

V4.6. Drošības testēšana Piegādātājam jānodrošina drošības testu veikšana Pasūtītāja vidē.

V4.7. Veiktspējas testēšana Piegādātājam testu plānā jāiekļauj veiktspējas testēšana un jāveic sistēmas veiktspējas pārbaudes pilnvērtīgai sistēmas funkcionēšanai. Testi jāveic uz Pasūtītāja aparatūras, kurai jāatbilst ekspluatācijas videi, kuru paredzēts izmantot ekspluatācijas sistēmas darbināšanai pēc sistēmas ieviešanas.

V5. Sistēmas ieviešana un konfigurēšana

V5.1. Sistēmas uzstādīšana ekspluatācijas vidē

Piegādātājam jānodrošina RAIS uzstādīšana un konfigurēšana (pielāgošana darbībai konkrētajā vidē) sistēmas ekspluatācijas vidē, Pasūtītājam nododot pilnvērtīgi strādājošu IS.

V5.2. Pasūtītāja speciālistu iesaistīšana

Veicot sistēmas uzstādīšanu ekspluatācijas vidē, jāiesaista Pasūtītāja norādītie LZRA speciālisti tādā apjomā, lai tie gūtu pilnvērtīgu priekšstatu par procedūrām, kas tiek veiktas, uzstādot sistēmu ekspluatācijas vidē.

V6. Sistēmas administratoru apmācības un datu ievades administratoru apmācības

V6.1. Apmācību plāns Piegādātājam pirms apmācību uzsākšanas ir jāizstrādā un ar Pasūtītāju jāsaskaņo apmācību plāns un to saturs.

V6.2. Sistēmas administratoru apmācības

Piegādātājam atbilstoši programmatūras izstrādes posmiem jāveic Sistēmas administratoru apmācības un jānodrošina nepieciešamie mācību materiāli.

V6.3. Lietotāju apmācības Piegādātājam jānodrošina galveno lietotāju apmācība darbam ar sistēmu, sagatavojot apmācību kursu un nodrošinot apmācības klātienē.Piegādātājam jānodrošina e-apmācību sistēmas izstrāde sistēmas lietotājiem, tai skaitā jānodrošina e-apmācību vide un materiāli.

V6.4. Apmācību apjoms Piegādātājam jānodrošina Sistēmas administratoru apmācības un galveno lietotāju apmācības tādā līmenī, lai lietotāji patstāvīgi un pilnvērtīgi spētu izmantot sistēmas piedāvāto funkcionalitāti, kā arī patstāvīgi veikt sistēmas administrēšanas, uzraudzības un atjaunošanas pasākumus.

V6.5. Apmācību vide un vieta Piegādātājam jānodrošina apmācību vide Sistēmas administratoru apmācības un galveno lietotāju apmācībām ar Pasūtītāju iepriekš saskaņotā vietā (skaits <50 cilvēki).

V6.6. Tehniskais aprīkojums apmācību veikšanai

Piegādātājam jānodrošina visa nepieciešamā tehniskā aprīkojuma un mācību materiālu sagatavošana, kas nepieciešama veiksmīgai apmācību norisei.

V6.7. Apmācību valoda Piegādātājam jānodrošina, ka apmācības tiek veiktas latviešu valodā.

V7. Sistēmas uzturēšana un atbalsts

V7.1. Sistēmas garantija Sistēmas garantija iekļauj vismaz šādu pakalpojumu sniegšanu Pasūtītājam saistībā ar piegādātajām IS komponentēm:• pēc akcepttestēšanas atrasto programmatūras izstrādes un ieviešanas kļūdu

bezatlīdzības novēršana;• programmatūras licenču atjaunināšana;• administratoru klātienes vai attālināts atbalsts (2. līmeņa).Garantijas pakalpojumu sniegšanas ietvaros netiek paredzēta jaunas funkcionalitātes izstrāde, kā arī tā neattiecas uz gadījumiem, kad sistēmas atteici izraisa problēmas IT iekārtu darbā.Piegādātājam jānodrošina sistēmas ekspluatācijas atbalsts un problēmu novēršana sistēmas ieviešanas un ekspluatācijas laikā.


Piegādātājam ir jānodrošina atbalsts, kas paredz Pasūtītāja pieteikumu reģistrēšanu, klasificēšanu un apstrādi saskaņā ar definētiem reakcijas laikiem.

V7.2. Garantijas darbības laiks Piegādātājam jānodrošina izveidoto un piegādāto IS komponenšu garantija līdz pilnvērtīgas IS un visu tās komponenšu ieviešanai pie Pasūtītāja, kā arī 2 (divu) gadu periodā pēc IS un visu tās komponenšu ieviešanas.

V7.3. Garantijas atbildība Piegādātājs ir atbildīgs par kvalitatīvu un nozares labās prakses vadlīnijām atbilstošas IS izstrādi, ieviešanu un piegādi, paredzot un ieviešot attiecīgus drošības, datu kvalitātes, IS izmantošanā ērtus un lietotājam draudzīgus mehānismus.

V7.4. Garantijas problēmu un izmaiņu pārvaldības kārtība

Piegādātājam jānodrošina Pasūtītāja pieteikto problēmziņojumu un izmaiņu pieprasījumu uzskaite un pēc Pasūtītāja pieprasījuma jāsniedz uzkrātie dati.

V7.5. Reakcijas laiki uz problēmu ziņojumiem

Piegādātājam Pasūtītāja darba dienās jānodrošina reakcijas laiks 0,5 stundu laikā

V7.6. Garantijas problēmu novēršanas laiks

Problēmu novēršanas maksimālais laiks saskaņā ar SLA (tiks saskaņots Projekta realizācijas laikā, balstoties uz vispārpieņemtu industrijas praksi).

V7.7. Licenču atjaunināšana Piegādātājam sistēmas atbalsta un uzturēšanas ietvaros jānodrošina visu tā piegādāto sistēmas darbībai nepieciešamo licenču atjaunināšana.

V7.8. Sistēmas uzlabošanas pakalpojumi (izmaiņu pieprasījumu apstrāde)

Piegādātājs nodrošina Pasūtītājam garantētu iespēju par maksu saņemt sistēmas uzlabošanas pakalpojumus 3 gadu periodā sākot ar Līguma noslēgšanas dienu.Sistēmas uzlabošana notiks, pamatojoties uz savstarpēji saskaņotiem izmaiņu pieprasījumiem (RFC, Request for change).Ja Pasūtītājs sniedz Piegādātājam izmaiņu pieprasījumus attiecībā uz būtisku jaunas funkcionalitātes izstrādi gan garantijas laikā, gan pēc garantijas termiņa beigām, Piegādātājam jānodrošina sistēmas uzlabošanas pakalpojumu sniegšana (funkcionalitātes izmaiņas) atbilstoši jaunām tiesību aktu prasībām un lietotāju prasībām noteiktā darba apjoma robežās (pēc abpusējās vienošanās ar Pasūtītāju).Garantijas ietvaros netiek paredzēta būtiski jaunas funkcionalitātes izstrāde.Pretendentam jānorāda tehniskajā piedāvājumā paredzēto sistēmas uzlabošanas pakalpojumu sniegšanas pieeja, savukārt, finanšu piedāvājumā jānorāda to izmaksas (speciālistu darba laika izmaksas).

3.2. Sistēmas funkcionālās prasības3.2.1. RAIS sistēma

10. tabula – F1 Vispārējās funkcionālās prasības (bloki)


F1.1. RAIS sistēmas funkcionālie bloki un to atbalstāmie procesi

F1.1.1. Sistēmai jābūt pieejamiem šādiem funkcionālajiem blokiem, kuri tiek atsevišķi nodrošināti katram revidentu uzņēmumam):

PPS un PPA izstrādes gaitā augstāk minētie funkcionālie bloki var tikt precizēti. Diagrammā bultu virziens attēlo informācijas plūsmas virzienu.

F1.2. Prasības pret RAIS, kas izriet no revīzijas procesa apraksta

Pretendentam Piedāvājumā ir jāiekļauj Tehniskajā specifikācijā turpmākajās nodaļās aprakstītās prasības kā arī prasības, kas funkcionāli netieši izriet no revīzijas procesa soļu apraksta un spēkā esošās revīzijas veikšanas metodoloģijas .

11. tabula – F2 Klientu reģistrs


F2.1. Klienta dati F2.1.1. Izveidojot klienta kartiņu, sistēmā jāsaglabā šāda informācija:

• Vispārīga informācija par klientu (tiek izmantota datu ievades forma) un kontaktinformācija Papildu skaidrojums: tiek izmantota sistēmā pieejamā datu ievades forma.

• Informācija par klienta īpašniekiem (tiek izmantota datu ievades forma, iespējamība pievienot failus, ja nepieciešams) Papildu skaidrojums: iespējamais risinājums – tiek izveidots darba uzdevums (klienta patieso īpašnieku identifikācija) un darba uzdevuma izpildes gaitā iegūtās veidnes un pierādījumi tiek savienoti ar to.

• Cita informācija par klientu (datu ievades forma un iespēja pievienot failus ar papildu informāciju) Papildu skaidrojums: cita informācija par klientu, iespējams, tiek pievienota atsevišķos failos (piemēram, tīmeklī veiktas izpētes un meklēšanas rezultāti); citas informācijas saraksts var tikt aprakstīts kā darba uzdevums.

• Klienta pieņemšanas anketa (datu ievades forma sistēmā). Jābūt iespējai klientu reģistrā klientu atzīmēt kā neaktīvu (pēc attiecībām ar klientu izbeigšanas). Jābūt iespējai dzēst tikai tos klientus, attiecībā uz kuriem nav atvērts vai arhivēts neviens projekts. Statuss „neaktīvs” tiek izmantots, lai ierobežotu klientu attēlošanu klientu reģistrā vai klientu meklēšanas logā, izveidojot attiecīgo


projektu. Iepriekš minētais saraksts var tikt precizēts PPA un PPS izstrādes laikā.

F2.2. Klientu reģistra funkcijas F2.2.1. Sistēmai ir jānodrošina vismaz šādas ar Klientu reģistru saistītas funkcijas:• Jaunu Klientu kartiņas izveide (Piemērs: Klienta pieņemšana ir darba uzdevums,

kuram ir piesaistīta dokumenta veidne; šim uzdevuma var būt piesaistīti arī papildu ārējie faili);

• Unikāla identifikācijas (ID) numura automātiska piešķiršana Klienta kartiņai;• Klientu kartiņas ierakstu satura ievadīšana;• Klientu kartiņas ierakstu saglabāšana;• Klientu meklēšana pēc kartiņas datiem;• Klientu kartiņas ierakstu koriģēšana un papildināšana;• Klientu kartiņas izdrukāšana.• Saistīto ar klientu reģistrāciju dokumentu (noteiktas formās) saglabāšana un izdruka.

12. tabula – F3 Lietotāju reģistrs


F3.1 Lietotāju dati un funkcijas F3.1.1. RAIS jānodrošina vismaz sekojoša Lietotāju reģistra funkcionalitāte:

• Ar revīzijas uzņēmumu saistītam superlietotājam jābūt iespējai pievienot citus lietotājus.

• Jābūt iespējai izveidot lietotāju grupas (lomas), pie kurām pieder lietotāji.• Jābūt iespējai noteikt ar revīzijas uzņēmumu saistīto superlietotāju, kurš var izveidot

jaunus lietotājus.• Jābūt iespējai pievienot, mainīt un dzēst lietotājus un atzīmēt to statusu kā

„neaktīvu”.• Jābūt iespējai saglabāt vismaz šādu lietotāja informāciju:

• personas kods, vārds un uzvārds, e-pasta adrese, tālruņa numurs, noklusējuma loma projektā, papildu identifikācija: uzņēmuma vai trešās puses darbinieks.

13. tabula – F4 Veidņu datubāze un projektu veidu pārvaldība


F4.1. Veidņu datubāze un projektu veidu pārvaldība

F4.1.1. RAIS jānodrošina vismaz sekojoša veidņu datubāzes un projektu veidu pārvaldības funkcionalitāte (visi tālāk tekstā minēti dati serverī jāglabā katram revīzijas uzņēmumam atsevišķi.

• Jābūt iespējai noteikt RAIS veidņu datubāzes lietotājus un viņu lietotāju tiesības (tiesības skatīt vai tiesības mainīt).

• Jābūt iespējai tajā pašā datubāzē aprakstīt veidņu komplektus pa projektu veidiem. • Jābūt iespējai parādīt veidņu sarakstu pa projektu veidiem (jābūt iespējai projekta

failā importēt papildu veidnes gan projekta izveides, gan īstenošanas procesā; turklāt jābūt iespējai importēt gan vienu, gan vairākas veidnes vienlaicīgi).

• Veidņu datubāzes superlietotājam jābūt iespējai pievienot jaunus projektu veidus un noteikt attiecīgajam projekta veidam piemērotās dokumentu veidnes (MS Word, MS Excel), izveidot jaunās veidnes izveides kopiju, balstoties uz tajā pašā vai kādā citā datubāzē, kurai lietotājam ir piekļuve, pieejamu veidni.

• Jābūt iespējai mainīt un dzēst esošās veidnes. • Attiecībā uz veidnēm jābūt iespējai noteikt, kas attiecīgajam projektam ir obligāts,


proti, kas pie projekta izveides tiks importēts pēc noklusējuma. • Jāizveido datubāzē glabājamo veidņu struktūra, un katrai veidnei tiks piešķirta

unikāla atsauce. Serverī varētu būt atsevišķa veidņu datubāze un versijas, kurās ietilptu iepriekš minēto darba uzdevumu veidnes līdz ar attiecīgo dokumentu veidnēm. Piekļuves tiesību veidnēm noteikšana (revīzijas uzņēmumu vai lietotāju līmenī).

• Veidņu datubāze ietvers dažādas projektu veidnes, kuru saturs atkarīgs no projekta veida (revīzija, pārbaude). Tomēr projektu veidnēs būs daļas, kas savstarpēji pārklājas, un tās atšķirsies galvenokārt pēc darba uzdevumu un pievienoto darba dokumentu veidņu skaita.

Informācijas apmaiņa ar veidņu datubāzi:

F4.1.2. Jānodrošina, ka iepriekš sagatavotas darba uzdevumu veidnes un MS Word un Excel veidnes var importēt sistēmā. Sistēmai vajadzētu spēt automātiski par katru projektu aizpildīt dažas veidņu daļas (piemēram, attiecīgajās MS Word un Excel veidnēs ievadīt galvenos projekta datus, programmatūrā ievadītos finanšu rādītājus utt.).

F4.1.3. Jābūt iespējai visus sistēmā ievadītos datus pārnest uz ārējo dokumentu veidnēm, ja nepieciešams. Dokumentā jābūt norādītai vismaz šādai informācijai:• klienta nosaukums;• par darba izpildi atbildīgās personas vārds;• posteņa summa (sākuma un beigu atlikums, pārskata periods vai iepriekšējais

salīdzināmais periods); • ar posteni saistītie konti un to atlikumi (sākuma un beigu atlikums, pārskata periods

vai iepriekšējais salīdzināmais periods);• būtiskums plānošanas nolūkā;• nebūtisku neatbilstību slieksnis;• riska novērtējuma rezultāti apgalvojuma līmenī; • specifiskie riski, kas attiecībā uz posteni identificēti riska novērtēšanas laikā;

F4.1.4. Ir tādas dokumentu veidnes, kurās jānorāda cita veida dati (piemēram, ar klientu noslēgtais pakalpojumu līgums, kurā jāievada klienta nosaukums un adrese, informācija par personām, kuras paraksta līgumu, projekta budžets un tamlīdzīga informācija).

• darba uzdevumu, dokumentu u.c. saraksti, kurus iespējams šķirot un filtrēt (piemēram, pēc atbildīgās personas, statusa utt.). Vēlams, lai lietotāji varētu izveidot sarakstus atbilstoši sava uzņēmuma vajadzībām, izvēloties sarakstos un filtros izvietojamos laukus. Jābūt iespējai šos sarakstus eksportēt uz MS Excel;

• iespēja savienot dokumentus (MS Word, MS Excel, PDF) ar darba uzdevuma veidni un mainīt, pievienot un dzēst tos projekta gaitā;

• iespēja aprakstīt savienojumu starp grāmatvedības programmatūras žurnāla/grāmatas datiem un darba uzdevuma veidnēm tā, lai grāmatvedības datus varētu automātiski pārnest uz (vai savienot ar) darba uzdevuma vai ar to saistīto dokumentu veidni(-ēm).


Papildu skaidrojums: Nepieciešams izveidot savienojumus starp finanšu pārskata posteņiem un žurnāla/grāmatas informāciju (kontu saraksts ar summām) klienta grāmatvedības programmā, ko sniedzis klients. Savienojami apraksti nozīmē, ka konts vai kontu kopums automātiski tiek savienots ar finanšu pārskata posteni. Uz šī pamata kontu summas tiek sadalītas starp darba uzdevumiem, un darba uzdevumam atbilstošie konti tiek pārnesti uz attiecīgo dokumenta veidni.

F4.1.5. Programmatūras izstrādes laikā nepieciešams izveidot iepriekš aprakstīto savienojumu šablonus vispopulārākajām grāmatvedības programmām (vismaz sešām, precīzs saraksts tiks noteikts turpmākās analīzes gaitā izstrādājot PPS/PPA) un viens MS Excel šablons, uz kuru informācija varētu tikt eksportēta no grāmatvedības programmatūras un no kura to varētu importēt revīzijas programmatūrā.

Piemērs:

Finanšu pārskatā ietverti posteņi „Nauda un naudas ekvivalenti” un „Debitori un avansa maksājumi”. Savienojumu apraksts būtu sniedzams kontu sarakstā, kad konts tiek savienots ar attiecīgo finanšu pārskata posteni.

Viena iespēja ir izveidot atbilstības tabulu, kurā kontu saraksts ir līdzās atsaucēm uz attiecīgajiem finanšu pārskatiem.

Konta nr. Konta nosaukums Finanšu pārskata postenis10101 Nauda kasē Nauda un naudas ekvivalenti (A1)10110 Swedbank Nauda un naudas ekvivalenti (A1)….12010 Pircēju un pasūtījumu parādi Debitori un avansa maksājumi (A2)

Otra iespēja ir aprakstīt savienojamību kā diapazonu:

Nauda un naudas ekvivalenti (A1) 10101…10199, Debitori un avansa maksājumi (A2) 12010…12019

Otrā iespēja varētu būt elastīgāka. Tomēr, importējot no MS Excel, lietotājiem, iespējams, ērtāks būs pirmais variants, kad savienojumi starp kontiem un finanšu pārskata posteņiem tiek veidoti pēc datu importēšanas. Importējot datus, svarīgi pārbaudīt, vai visi konti savienoti ar atbilstošo posteni. Jābūt iespējai mainīt savienojumus vai dzēst kontu datus un importēt tos atkārtoti.

14. tabula – F5 Projekta izveide un pieņemšana


F5.1. Projektu izveide un pieņemšana

F5.1.1. Izveidojot jaunu projektu, sistēmas projektu sarakstā par šo projektu tiek saglabāta un uzturēta šāda informācija:

• vispārēja informācija par projektu (projekta veids un galvenie dati) - (izmantojot datu ievades formu un iespēju pievienot failus, ja nepieciešams);

• projekta darba grupas locekļi (lietotāji) un viņu lomas; • projekta budžets (izmantojot formu vai atsevišķu failu), sadalījumā pa darbībām un

darba grupas locekļiem. (Papildu skaidrojums: darba uzdevumu saraksts un laika grafiks parasti ir standarta, jāpievieno personāliju dimensija, ko iespējams izdarīt, izmantojot matricas tabulu (lietotāji ailēs) vai papildu rindas; praksē vienu uzdevumu bieži veic viena persona); un

• projekta pieņemšanas anketa (izmantojot datu ievades formu).


F5.1.2. Projektu sarakstā redzami tikai tie projekti, kuros lietotājs identificēts kā darba grupas loceklis (un šo sarakstu var atvērt tikai attiecīgais lietotājs).

F5.1.3. Kad vispārīgie dati ir ievadīti, projekta faila izveidei ar visiem iepriekš aprakstītajiem darba uzdevumiem un dokumentu veidnēm tiek izmantotas veidnes.

15. tabula – F6 Projekta failu izveide un apstrāde


F6.1. Projekta faila izveide F6.1.1. Sistēmai jānodrošina Projekta faila izveide un projekta pieņemšana (1 klients = 1 uzņēmums, ar vienu uzņēmumu var būt saistīti vairāki projekti, projekts sastāv no darba uzdevumiem, kuriem var tikt pievienoti vairāki dokumenti). Lietotāju pievienošana projektam un viņu lomas un tiesību (tiesības skatīt, tiesības mainīt) noteikšana.

Dažādos projekta posmos veikto darba uzdevumu elastīgs apraksts un šo uzdevumu klasifikācija trīs grupās: plānošana, pierādījumu iegūšana un secinājumu formulēšana.

F.6.1.2. Projekts sastāv no vairākām darbībām (iepriekš sauktām arī par „darba uzdevumiem”, kuras lietotājam ir jāspēj aprakstīt un brīvi mainīt. Jābūt iespējai katrai darbībai pievienot dokumentus.

Pie projekta izveides jābūt iespējai izvēlēties, vai atvērt tukšu projekta failu, izmantojot kādu veidņu datubāzē pieejamu failu vai kādu citu jau pabeigtu projektu. Šādā gadījumā jābūt iespējai izvēlēties, kādus darba uzdevumus un dokumentus pārnest uz jauno projektu. Sistēmai varētu būt atbalsta procedūra, kas importētu veidnes no veidņu datubāzes, pamatojoties uz iepriekš programmatūrā ievadīto informāciju (rādītāji, risku novērtējums un izvēlētā pieeja). Piemēram, būtu jābūt iespējai importēt veidnes, pamatojoties uz šādiem rādītājiem: postenis – krājumi, risks – vērtība, pieeja – datu pārbaudes un kontroļu pārbaudes. Lietotājam jāspēj mainīt pirms tam veiktās izvēles pirms importēšanas procesa sākšanas.

Papildu skaidrojums: Plānojot darbu, tiek veikta provizoriska izvēle attiecībā uz finanšu pārskata posteni. Līdzīgas provizoriskas izvēles ir pieejamas veidņu datubāzē. Automātisku izvēli varētu veikt, pamatojoties uz izvēļu atbilstības salīdzinājumu. Turklāt obligātie darba uzdevumi un veidnes, kas nav atkarīgas no izvēles, vienmēr var tikt importētas.

Varbūtējās izvēles varētu būt šādas: • finanšu pārskata posteņa nosaukums;• apgalvojums (juridiskais nosaukums; vērtības noteikšana un attiecināšana;

pilnīgums; esamība vai rašanās; pareizība; periodizācija; klasifikācija; uzrādīšana); • apgalvojuma līmenī identificētais risks; • revīzijas procedūras (datu pārbaudes, substantivās analītiskās procedūras, kontroļu

pārbaudes);• darba uzdevumi (intervija, novērojums, pārbaude u.c.).

F6.1.3. Par katru darba uzdevumu sistēmā būs šāda informācija: atsauce uz failu, norāde par darba veikšanas vietu, darba mērķa apraksts un secinājumi, kā arī ar darba uzdevumu saistīto ārējo dokumentu veidnes. Atkarībā no projekta izpildes posma darba uzdevumu apraksti (veidnes) var ietvert vēl citu informāciju (ar darba uzdevumu saistīti vadības apliecinājumi, procedūras/pārbaudes veids utt.).

F6.1.4. Jānodrošina iespēja, ka lietotājs var mainīt datus darba uzdevuma laukā vai dokumenta veidnē.

F6.1.5. Darba uzdevumu veidnes un saistīto dokumentu veidnes tiek atlasītas pēc šādiem kritērijiem: • atbilstošās veidnes tiek atlasītas atkarībā no projekta (veidnēm jābūt sagrupētām

pēc projekta veida: revīzijas veidnes un pārbaudes veidnes); • katrā projektā vienmēr ir vairāki obligāti veicami darba uzdevumi, un noteiktas

veidnes ir izmantojamas visos projektos; • darba uzdevumi un veidnes finanšu pārskata posteņu pārbaudei tiek atlasītas

plānošanas posmā (kuri posteņi ir jāpārbauda (ir būtiski) un kādiem riskiem attiecīgie posteņi ir pakļauti);

• daži darba uzdevumi un dokumentu veidnes tiek atlasītas manuāli, pamatojoties uz


revidenta sprieduma.

F6.1.6. Programmatūrai jābūt kontrolēm, kas nodrošinātu to, ka veidne netiek pievienota projekta failam (un netiek arī pārrakstīta), ja fails jau ietver veidni ar tādu pašu numuru. Šādā gadījumā sistēma parāda brīdinājumu ar to veidņu sarakstu, kuras jau ir iekļautas projekta failā un kas tāpēc netiek pievienotas attiecīgajam projekta failam.Importējot dokumentu veidnes no veidņu datubāzes, veidņu laukus aizpilda ar atbilstošu informāciju no vispārējiem projekta datiem.

F6.1.7. Darba uzdevumi ir jānumurē (tiem jānorāda atsauces), un programmatūrai automātiski jānumurē dokumenti, kas tiek pievienoti (atsauces numurs tiek ģenerēts atbilstoši darba uzdevuma numuram).

F6.1.8. Lietotāja vide tiek iedalīta divās daļās: pa kreisi ir darbības (darba uzdevumi) un pa labi – detalizēta informācija, kas attiecas uz konkrēto darba uzdevumu ( pievienotā ievades forma un dokumenti).

F6.1.9. Katrai darbībai ir viena datu ievades forma un lietotājam tiek parādīts darbību saraksts sazarota koka veidā, kur darbības sakārtotas pēc numuriem. Jābūt iespējai aprakstīt darba uzdevumus (to atsauces), izmantojot vismaz četru līmeņu hierarhiju.

Ekrāna skatījuma kreisās puses piemērs:

Atsauce Darbība Izpildītājs Statuss

1 Plānošana

10 Riska novērtējums

101 Ārējo risku novērtējums

….

A10 Debitoru parādu pārbaude

Ekrāna skatījuma labās puses piemērs (atbilstoši kreisajā pusē izvēlētajiem darba uzdevumiem):

A10 – Debitoru parādu pārbaude

Kopsavilkuma galvene

Riska novērtējuma rezultāti pa apgalvojumiem

Īss darba pieejas, statusa apskats

Saturs

Darba uzdevumu apraksts, kurā norādīts, kuri apgalvojumi un riski jāpārbauda, veicot šo procedūru

Veiktā darba apraksts ar iespēju pievienot failus (piemēram, faila atsauce A10.1)

Secinājumi un kopsavilkums par identificētajām neatbilstībām

Personas, kas veikusi darbu, iniciāļi, un darba pabeigšanas datums

Personas, kas pārbaudījusi darbu, iniciāļi, un darba pārbaudes datums

Šie piemēri sniegti, lai dotu priekšstatu par revidentu vēlmēm, un tie nav saistoši risinājuma piedāvājumam. Vērtēšanas komisija analizēs un vērtēs katru risinājumu/piedāvājumu atsevišķi.

F6.1.10. Jābūt iespējai filtrēt darbības pēc statusa, atbildīgās personas, darbības veida


utt.

F6.1.11. Dažādos projekta posmos (plānošana, pierādījumu iegūšana un secinājumu izdarīšana) var tikt izmantotas dažādas ievades formas. Vēlams, lai lietotājs varētu izmantot dažāda veida standarta ievades formas. Atbilstoši aplēsēm 90-95% darba uzdevumu var tikt veikti, izmantojot vienu standarta darba uzdevuma formu (standarta uzdevums). Lielākā daļa praktiskā darba tiek veikta, izmantojot ārējos failus. Sistēmā jābūt izveidotām atsevišķām datu ievades formām šādiem darba uzdevumiem: • projekta budžeta sastādīšana dalījumā pa darba uzdevumiem un personām (vairāku

cilvēku gadījumā vairākas ailes; limits varētu būt ne vairāk par 6 cilvēkiem). (Skaidrojums: sagatavojot budžetu, sistēmā tiek ievadīts projekta sākuma posmam nepieciešamais laiks (provizoriskā aplēse, pamatojoties uz iepriekšējo pieredzi); budžetam nav jābūt dinamiskam);

• galvenie finanšu pārskata rādītāji un to sākotnējā analīze; • kontu atlikumu savienojums ar atbilstošajiem finanšu pārskata posteņiem;• lapa grāmatvedības politiku izvēlei (kādas politikas piemērotas dažādiem bilances un

peļņas vai zaudējumu aprēķina posteņiem, piemēram, vai ieguldījuma īpašumi tiek novērtēti izmaksās vai patiesajā vērtībā);

• finanšu rādītāju analīze;• tabula identificēto risku izvērtēšanai; • veidne būtiskumu aprēķināšanai;• risku novērtējums apgalvojumu līmenī; • darblapa korekciju un labojumu izsekošanai; • nekoriģēto neatbilstību apkopojums.

Dažas no iepriekš minētajām veidnēm var tikt klonētas citiem uzdevumiem. Iepriekš minētais formu lauku dizains un izvietojums, kā arī darba loģika var tikt konkretizēta programmatūras izstrādes gaitā.

Papildu skaidrojums: nepieciešams izveidot darba uzdevuma formu, kurā lietotājs var pievienot jautājumus un sniegt atbildes uz tiem (jā, nē, nav attiecināms); ja atbilde nozīmē problēmu, veidnē jābūt iekļautai iepriekšējai šīs problēmas apraksta iespējai. Turklāt jābūt iespējai atbildēt uz jautājumu tekstuālu komentāru veidā. Nākamajā posmā varētu tikt apsvērts, vai atsevišķas atbildes atkarībā no apstākļiem varētu iedarbināt kādas automātiskas procedūras. No otras puses, varētu tikt samazināta ārējo failu daļa.

F6.1.12. Uzdodot lietotājiem veicamos darba uzdevumus, jābūt iespējai uzdot vairākus darbus vienlaicīgi. Lietotāji/ darba veicēji var tikt noteikti un mainīti arī projekta/darba gaitā.

F6.1.13. Katram darba uzdevumam jābūt iespējai noteikt tā statusu („pabeigts”, „nepabeigts”) un reģistrēt, vai un kad darbs ir pārbaudīts. Veidojot iepriekš minētās procedūras, programmatūrai automātiski jāģenerē un jāpievieno lietotāja iniciāļi un datums.

Veicot jebkuru darbu, revidents var identificēt kādu neatbilstību, kas būtu jāiekļauj neatbilstību kopsavilkumā. Projekta nobeiguma posmā jābūt iespējai sagatavot darba uzdevumu izpildes gaitā identificēto neatbilstību kopsavilkumu un nodalīt koriģētās un nekoriģētās neatbilstības. Tāpat sistēmai jāspēj ģenerēt nekoriģēto/neizlaboto neatbilstību veidni (lai nekoriģētās neatbilstības varētu eksportēt, piemēram, uz vadības apliecinājuma vēstuli, ja nepieciešams).

16. tabula – F7 Projekta pabeigšana un arhivēšana


F7.1. Projekta pabeigšana un arhivēšana

F7.1.1. Kad visi darba uzdevumi ir pabeigti, programmatūrai jāļauj arhivēt projektu, atņemot lietotājiem tiesības projekta failā mainīt datus/dokumentus u.c. Izmaiņas tad


var veikt tikai ar superlietotāja, kas saistīts ar revīzijas uzņēmumu, atļauju. Visas izmaiņas, kas veiktas pēc arhivēšanas, jāreģistrē, un personai, kura veikusi attiecīgās izmaiņas, žurnālā jāpievieno paskaidrojums.

Papildu skaidrojums: Ar revīzijas uzņēmumu saistītajam superlietotājam jāspēj atvērt fails izmaiņu veikšanai. Superlietotājam jāreģistrē jebkādas šādas darbības kopā ar skaidrojumu par to, kas un kāpēc ticis mainīts. Kad fails ir atvērts, vai nu no jauna aktīvas kļūst lietotājiem projekta sākumā piešķirtās lomas vai ir iespējams pievienot jaunus lietotājus ar jaunām lomām.

F7.1.2. Arhivēšana un pabeigtu projektu papildināšana. Jābūt iespējai grupēt un filtrēt projektus tā, lai no visiem revīzijas uzņēmuma projektiem lietotājiem būt vieglāk atrast tos projektus, kuros ir iesaistīti tieši viņi.

Piemērs: Lietotājs var redzēt to darba uzdevumu un projektu (tajā skaitā tajos pildāmo lomu) sarakstu, kuru izpilde viņam/viņai uzticēta; lietotājs var šķirot savus darba uzdevumus un projektus atbilstoši to statusam/ierakstam/posmam utt.

17. tabula – F8 Revīzijas procedūru loģikas izmaiņu pievienošana programmatūrā


F8.1. Revīzijas procedūru loģikas izmaiņu pievienošana programmatūrā

F8.1.1. Nepieciešamībai pēc izmaiņām programmatūras līmeņa revīzijas procesa soļu loģikā ir jābūt izņēmuma kārtā, proti, būtu jābūt iespējai veikt lielāko daļu darbību un procesu, izmantojot standarta veidnes, ko var izstrādāt lietotājs, un dokumentus, kas var tikt tām pievienoti. Taču nepieciešams paredzēt, ka ar revīzijas uzņēmumu saistīts superlietotājs pēc iespējas var koriģēt revīzijas soļu loģiku (var tikt noteikt soļu loģikas iestatījumi). Piemēram, noteikt, kuras darbības un kādā secībā ir veicamas, kādas veidnes atbilst kādam projekta veidam utt.

F8.1.2. Lietotājam jāspēj aprakstīt šādu revīzijas loģiku: - Būtiskuma aprēķināšana, izmantojot programmatūrā importētos/ievadītos finanšu pārskata datus

Būtiskuma aprēķināšanas modeļa piemērs:

Būtiskums ir atkarīgs no programmatūrā ievadītiem finanšu rādītājiem (līdz pieciem) un iespējamības noteikt, vai tie tiks vai netiks izmantoti būtiskuma bāzes aprēķinā. Attiecībā uz katru rādītāju tiek noteikta tā procentuālā daļa, kas tiks izmantota aprēķinā. Šādi tiek noteikta būtiskuma bāze.

Būtiskums ir noteikts kā būtiskuma bāzes procentuālā daļa (procentuālo daļu nosaka lietotājs).

Būtiskumu plānošanas nolūkā nosaka kā procentuālo daļu (procentuālo daļu nosaka lietotājs) no būtiskuma.

Nebūtisko neatbilstību īpatsvaru nosaka kā procentuālo daļu (procentuālo daļu nosaka lietotājs) no būtiskuma.

F8.1.3. Lietotājam jāspēj aprakstīt šādu revīzijas loģiku - Risku novērtējums (riski tiek izvērtēti uzņēmumam un finanšu pārskatiem kopumā, kā arī finanšu pārskata posteņu līmenī) un risku sasaiste ar konkrētiem posteņiem

Riski tiek novērtēti pa posteņiem un apgalvojumiem. Tiek novērtēti gan piemītošie riski, gan kontroļu riski. Riski var tikt novērtēti pēc šādas skalas: zems, vidējs, augsts, vai arī, izmantojot atbildes „jā” vai „nē”. Lietotājam jāspēj definēt riska novērtējumam piedāvātas opcijas programmatūras iestatījumā.

F8.1.4. Lietotājam jāspēj aprakstīt šādu revīzijas loģiku – izveidot Savienojumu starp finanšu pārskata posteņiem un kontu plānu aprakstu

Mērķis ir mazināt manuālo darbu, pārnesot kontu datus no grāmatvedības programmatūras.

RAIS būtu jānodrošina šāda funkcionalitāte:


• Finanšu pārskata komponenšu/sastāvdaļu saraksts (lietotājam jāspēj mainīt saraksts)• Finanšu pārskata rādītāju importēšana un rādītāju savienošana ar sistēmā

aprakstītajām finanšu pārskatu komponentēm.

Papildu skaidrojums: jāizveido atbilstības tabula, lai savienotu programmas laukus ar importējamā faila laukiem. To var izdarīt programmatūra ar tabulu, kurā lietotājs var izveidot nepieciešamos savienojumus ar atbilstības tabulu. Sistēmā tiek importēti tikai tie dati, kuriem šajā sistēmā ir atbilstošs lauks.

• Iepriekš noteikto risku saraksts sadalījumā pa finanšu pārskatu komponentēm, no kura lietotājs var izvēlēties atbilstošos riskus to varbūtības un paredzamo seku izvērtēšanai.

• Ilustratīvas formas standarta darba uzdevumiem un to lauku apraksts, kuri tiek ņemti no programmatūras (finanšu rādītāji, riska novērtējuma rezultāti u.c.) projekta līmenī.

3.2.2. Sistēmas integrācijas prasībasSaskarņu nodrošināšanai ar ārējām sistēmām, nepieciešams izstrādāt uz SOA standartiem un principiem balstītu integrācijas vidi. Interfeisu izstrādē, kas saistīti ar ārējo sistēmu esošo interfeisu izmantošanu ir jāņem vērā otras puses piedāvātais datu apmaiņas scenārijs. Plānojot datu saskarņu arhitektūru nepieciešams ņemt vērā datu sniedzēju interfeisu prasības un, ja nepieciešams, jāspēj realizēt visas paredzētās darbības. RAIS datu pieejamības nodrošināšana ārējiem pieprasītājiem jānodrošina ar tīmekļa pakalpņu starpniecību. Ja nepieciešama cita veida datu apmaiņa, tad integrācijas vidē jāspēj realizēt arī cita veida datu apmaiņa (piemēram, datu replikācija, teksta failu sūtīšana, bināru failu sūtīšana un saņemšana).

18. tabula – F16 Sistēmas integrācijas prasības

Precīzas saņemamās un nododamās informācijas vienības definējamas izstrādājot RAIS projektējumu.


F9.1. Datu apmaiņas pamatprincipi

F9.1.1. Vienota integrācijas vide Veidojot vienotu integrācijas vidi, vēlams nodrošināt šādus servisus (prasība ir precizējama PPS/PPA izstrādes laikā):• Identitātes un drošības servisi. Servisu grupa, kas nodrošina centralizētus

autentifikācijas, autorizācijas un audita servisus. Tāpat drošības servisi ir atbildīgi par ziņojumu šifrēšanu, atšifrēšanu un integritātes pārbaudi gan datu pārraides, gan ziņojumu līmenī. Integrācijas videi jānodrošina iespēja realizēt centralizētu drošības politiku saskarņu līmenī, balsoties uz WS-Policy/WS-Security standartiem. Lietotāju autentifikācijai ir jāatbalsta sekojoši drošības tokeni: SAML, lietotājaID/parole, X509 sertifikāti.

Vēlamā atbilstība standartiem:

• XML/XSLT/XPath/XQuery - Sistēmai jānodrošina XML, XSLT, XPath un XQuery atbalsts:

• Paplašināmā iezīmēšanas valoda jeb XML (eXtensible Markup Language) ir W3C rekomendācija speciālas nozīmes iezīmēšanas valodu veidošanai. Tās galvenā nozīme ir strukturēta teksta un informācijas koplietošanas atvieglošana internetā.

• XSLT (Extensible Stylesheet Language Transformation) ir deklaratīva, XML bāzēta valoda, kas paredzēta XML dokumentu transformāciju aprakstīšanai.


• XPath ir pieprasījumu valoda, kas paredzēta ierakstu (mezglu) atrašanai XML dokumentā.

• XQuery ir pieprasījumu un programmēšanas valoda, kas paredzēta lai iegūtu datus no XML dokumentu kopas.

• SAML un x.509 - Sistēmai ir jānodrošina atbalsts SAML un x.509 standartiem: • SAML (The Security Assertion Markup Language) ir XML bāzēts, atvērts

standarts, kurš nodrošina autentifikācijas un autorizācijas informācijas apmaiņu starp identitātes un servisa nodrošinātājiem.

• x.509 ir standarts, kurš nodrošina šifrēšanas infrastruktūru un privilēģiju pārvaldības infrastruktūru, tai skaitā kriptogrāfijas atslēgu un sertifikātu pārvaldību, privilēģiju pārvaldību u.t.t.

• Datu apmaiņas servisi. Servisu grupa, kas nodrošina gan sinhronu, gan asinhronu ziņojumu pārraidi, datubāzu replikāciju starp iesaistītajām DBVS, dažādu datu apmaiņas protokolu (SOAP, HTTP/-S, FTP, SMPT u.c.) un formātu (XML, binārie formāti) uzturēšanu, kas nepieciešami ārējo sistēmu integrācijai.

• Atbilstība SOA - Sistēmai jāievēro sekojošas, servisu orientētas arhitektūras (SOA) raksturiezīmes:• Servisu kvalitāte;• Servisu autonomija;• Atvērto standartu atbalsts;• Servisu sadarbspēja;• Iespēja sadarboties ar ārējo sistēmu servisiem, kuru izstrādē izmantotas

dažādas tehnoloģijas, piemēram, J2EE vai .NET;• Atkārtota lietojamība;• Komponenšu vāja sasaiste;• Servisu saistību paplašināšana ar minimālu ietekmi;• Servisu abstrakcija.

• Pārvaldības servisi. Nodrošina centralizētu servisa līmeņa definēšanu, atsekošanu un vizuālu attēlošanu, balstoties uz servisu veiktspējas mērījumiem (atbildes laiks, ziņojumu apstrādes laiks u.c.)

• Ziņojumu apstrādes servisi. Servisu grupa, kas nodrošina ziņojumu transformāciju, validāciju, maršrutizāciju un kļūdu apstrādi.

F9.1.2. Kļūdu apstrāde Integrācijas servisiem jāspēj nodrošināt korekta kļūdu apstrāde un datu apmaiņā iesaistīto sistēmu informēšana par to nosūtīto datu saņemšanas un apstrādes statusu

F9.1.3. Citas papildu pārbaudes Nepieciešams nodrošināt iesūtīto dokumentu integritāti un pārliecināties, ka dokumenti nesatur vīrusus un citu ķaitniecisku programmatūru.

F9.2. Datu apmaiņa ar Grāmatvedības sistēmām

F9.2.1. Saņemamā informācija Nepieciešams nodrošināt importēt programmatūrā žurnālu/grāmatu datus (konta nr., sākuma atlikums, beigu atlikums, debets un kredīts) no grāmatvedības programmas (ievaddati var būt xls, xlsx, txt (tab delimited), csv formātā).

RAIS izstrādes procesā importēšanai nepieciešamie modeļi jāizveido vispopulārākajām grāmatvedības programmām (vismaz 6); datu importēšana no citām grāmatvedības programmām tiks veikta, importējot datus no iepriekš formatētas Excel tabulas.

F9.2.2. Nosūtāmā informācija NA

F9.2.3. Datu apmaiņas modeļu elastība

Atšķirīgo grāmatvedības programmu dēļ lietotājam būtu jāspēj izveidot jaunas datu importēšanas shēmas. Lietotājam jāspēj definēt/mainīt savienojumus starp


importētajiem datiem un programmatūrā aprakstītajām finanšu pārskatu komponentēm, pamatojoties uz izmantoto grāmatvedības programmu (savienojumi tiek uzturēti/saglabāti atbilstības tabulā, kuru lietotājam jāspēj mainīt vai papildināt, ja nepieciešams).

3.3. Sistēmas nefunkcionālās prasības

19. tabula –Sistēmas vispārīgās nefunkcionālās prasības


N1. Vispārējā arhitektūra

N1.1. Sistēmas arhitektūras veids RAIS klienta puses realizāciju vēlams veidot kā “Fat” vai “Thick Client” – proti nedrošinot Klientu darbu arī autonomā vidē (bez patstāvīga interneta pieslēguma).

N1.2. Sistēmas arhitektūras realizācija

Ja sistēma tiek realizēta, izmantojot tīmekļa lietotni, sistēmas izveidē vēlams izmantot MVC (Model View Controller) modeļa-skata-kontroliera programmatūras izstrādes arhitektūras principu (nav obligāts).Katru servera arhitektūras līmeni jāizvieto uz atsevišķa mezgla fiziskā vai virtuālā serverī.Katrā servera arhitektūras līmenī jānodrošina mezglu dublēšana, izmantojot klasteru tehnoloģijas (piemērām, Web-serveriem – NLB tehnoloģija, aplikāciju serveriem – klasterizācija aplikāciju līmenī, datubāzes serveriem – klasterizācija – MS cluster services Windows vidē, HCMP IBM AIX vidē, Oracle Clusterware Solaris vidē.Sistēmai jābūt paplašināmai, ar iespēju pievienot jaunu mezglu (Web-serveris un/vai Aplikāciju serveris) bez darba apstādināšanas.

N2. Lietotāja saskarne

N2.1. Savietojamība ar interneta pārlūkprogrammām

Ja sistēma ir realizēta, izmantojot tīmekļa lietotni, tad jānodrošina savietojamība vismaz ar šādām tīmekļa lietojumprogrammām:• Microsoft Internet Explorer, sākot no v9 Ja sistēma ir realizēta, izmantojot tīmekļa lietotni, jānodrošina lietotāja tīmekļa pārlūkprogrammas un tās versijas pārbaude un jāinformē par tās savietojamības iespējamu neatbilstību.

N2.2. Lietotāju datoru resursu pietiekamība

Sistēmai jānodrošina funkcionālo un nefunkcionālo prasību realizācija (tajā skaitā veiktspējas prasību realizācija), ņemot vērā šādas datortehnikas minimālās datortehnikas prasības: • Procesors pēc www.cpubenchmark.net testa PassMark CPU rezultātiem vismaz 1100

punktu. Operatīvā atmiņa 2 Gb.

N2.3. Dinamiskas lietotāja saskarnes izmantošana

Sistēma jāveido, izmantojot tehnoloģisku platformu, kas dod iespēju veidot dinamisku lietotāja saskarni.

N2.4. Lietotāja identificēšana saskarnē

Saskarnē skaidri jāidentificē lietotājs, kurš autorizēts darbam ar sistēmu.Lietotāja saskarnei ir jānodrošina automātiska autentifikācija.

N2.5. Lietotāju saskarnes un datu apstrādes valoda

Jābūt iespējai nodrošināt gan programmatūras tīkla saskarnes, gan lietotāju saskarnes valodas maiņu. Abiem interfeisiem jābūt latviešu, angļu un krievu valodā, un jābūt iespējai nākotnē pievienot vēl citas valodas. Programmas loģika būs vienā valodā. Piegādes brīdī programmatūrai jābūt latviešu, angļu un krievu valodā. Vēlams, lai programmatūra ietvertu iespēju pārbaudīt latviešu valodā brīvi ievadīta teksta pareizrakstību (ja šāds risinājums nav iespējams bez maksas, pretendentam jānorāda attiecīga maksa savā piedāvājumā).

Kļūdu paziņojumu detalizētāki skaidrojumi. Kļūdu nosaukumi un detalizēti apraksti kļūdām, kas rodas apstrādājot datu bāzes pieprasījumus vai izmantojot operētājsistēmas funkcionalitāti, var būt angļu valodā. Taču visas speciālās datu korektuma pārbaudes, lietotāja nepareizas darbības apstrādes un lielākās daļa sistēmas kļūdu ziņojumiem jābūt

http://www.cpubenchmark.net/


latviešu valodā.

N2.6. Obligāti aizpildāmie lauki Vizuāli jāizceļ obligāti aizpildāmie lauki. Ja obligāti aizpildāmais lauks nav aizpildīts, jāizmanto klienta puses kontrole lai lietotāju brīdinātu par nepieciešamību aizpildīt lauku, pirms mēģinājuma saglabāt datus.Ja datu saglabāšanas mēģinājums neaizpildītu obligāto lauku dēļ nav bijis sekmīgs,• lietotājam jāparāda skaidri saprotams paziņojums, kādi dati nav aizpildīti;• datu ievades logam jāatgriež fokuss uz pirmo neaizpildīto obligāto lauku.

N2.7. Ergonomisks sistēmas dizains • Lietotāja saskarnei ir jābūt ērtai un ergonomiskai (piemēram, horizontālo ritjoslu neesamība (datoram ar monitora izšķirtspēju 1024x768), pēc iespējas mazāk vertikālo ritjoslu izmantošana, pārskatāms ievadlauku izkārtojums utt.).

• Lietotāja saskarnē jāizmanto sistēmas lietotājam saprotami vārdi, frāzes, koncepcijas un grafika.

• Visu nepieciešamo informāciju, lai izmantotu sistēmu, lietotājam jābūt iespējai atrast pašā programmā.

• Lietotāja saskarnē jāizmanto nepārprotama terminoloģija, vienota izskata saskarnes elementi (piemēram, logi). Vadības elementiem (piemēram, pogām) visur jādarbojas vienādi.

• Lietotājs jāinformē par uzdevumu izpildes gaitu.• Lietotāja saskarnē jāpiedāvā iespēja izmantot tiešās izvēlnes, rīkjoslas un tamlīdzīgus

elementus, kas ļauj paaugstināt pieredzējuša lietotāja darba efektivitāti.• Kļūdu ziņojumu tekstos iekļautajai informācijai jābūt pietiekamai, lai lietotājs

saprastu problēmu un spētu izvēlēties nākošo darbību.• Sistēmas uzbūvei jāierobežo lietotāja kļūdīšanās iespēja, piemēram, ja esošajā

kontekstā darbība ir aizliegta, poga nav aktīva.• Nav nepieciešams meklēt informāciju par konkrēta uzdevuma veikšanu ārējos

informācijas avotos, sistēmā tiek piedāvāta īsa, uzdevuma veikšanai nepieciešama palīdzība. Izmantojot izvēlni „Palīdzība”, lietotājam nepieciešamības gadījumā jādod iespēja atrast atbildes uz jautājumiem par to, kā strādāt ar sistēmu.

• Jāparāda brīdinājums, ja lietotājs mēģina veikt kādu potenciāli bīstamu darbību, vai darbību, kuru grūti atsaukt.

Sistēmas vizuālajam izskatam ir jābūt saprotamam un vienkāršam, atbilstošam lietotāja uzdevumiem.Lietotāja saskarnei ir jāatbilst sekojošām prasībām:• Saskarnei ir jābūt ergonomiskai. Piemēram, pārskatāms un loģisks datu lauku

izkārtojums, pēc iespējas mazāk ritjoslu, u.tml.• Vienu un to pašu lietu dažādās ekrānformās jāapzīmē ar vieniem un tiem pašiem

nosaukumiem, terminiem vai saīsinājumiem.• Saskarsmē izmantotajiem paziņojumiem, frāzēm jābūt viegli saprotamām lietotājiem. Sistēmas standarta vai kļūdu paziņojumiem jābūt viegli saprotamiem, problēmas būtību paskaidrojošiem. Lietotājam ir jāpiedāvā varianti turpmākai rīcībai.Navigācijai starp ekrānformām jābūt izveidotai tā, lai lietotājam nebūtu jāatceras informāciju, pārslēdzoties starp ekrāniem.Jānodrošina atgriezeniskā saite ar lietotāju, cenšoties to informēt par darbībām, kas tiks veiktas sistēmā.

N2.8. Dati tabulu skatos Tabulu skatos dati jākārto dilstošā secībā pēc to ierakstu reģistrēšanas laika, ja funkcionālajā prasībā nav norādīts citādi.

N2.9. Datu kārtošana Noklikšķinot uz kolonnas nosaukuma tabulas galvenē jāveic datu kārtošana tabulā augošā secībā pēc ieraksta attiecīgajā kolonnā. Ja dati jau ir sakārtoti pēc ieraksta kolonna, jāmaina datu kārtošanas virziens.

N2.10. Datu izvēle IS jānodrošina iespēja lietotājam veikt datu izvēli no sarakstiem (drop-down lists) vismaz šādos veidos:• vēlamo datu izvēle no piedāvātā datu izvēles saraksta;• datu izvēle, ievadot datu izvēles laukā vēlamo datu nosaukuma pirmos simbolus.

N2.11. Meklēšana Sistēmai jānodrošina informācijas vienkāršas un izvērstas meklēšanas funkcionalitāte jebkurā no sistēmas satura apgabaliem. Meklēšanas funkcionalitāte pielāgojama atkarībā no sistēmas satura apgabala.Sistēmā jābūt iebūvētam datu meklēšanas rīkam, kas ļauj veikt vaicājumus pēc visiem


lietotājam pieejamajiem laukiem, to kombinācijām.Sistēmas meklēšanas rīkam jābūt ar iespēju papildināt un modificēt tā meklēšanas algoritmus.

N2.12. Atlases rezultātu attēlojums Jānodrošina meklēšanas un atlases rezultātu attēlošana strukturētos sarakstos.Jānodrošina tikai tās informācijas attēlošana, kurai ir piekļuve konkrētajam lietotājam.Attēlojot meklēšanas un atlases rezultātus, jānodrošina atrasto un atlasīto ierakstu skaita attēlošana.Par katru atrasto un atlasīto informācijas vienumu sarakstā jāietver:• atrastā vai atlasītā ieraksta teksta fragmenta attēlojumam, kas raksturo atrastā vai

atlasītā informācijas vienuma atbilstību definētajiem meklēšanas kritērijiem;• saite uz pilnu informācijas tekstu vai datni, kas satur meklējamo informāciju.Jānodrošina iespēja lietotājam veikt meklēšanas un atlases lietotāju kārtošanas iespējas:• definēt vienlaicīgi attēlojamo ierakstu skaitu;• kārtot rezultātus pēc jebkura saraksta parametra.

N2.13. Kodējumu atbalsts Jānodrošina daudzvalodu atbalsts (piemēram, izmantojot UTF-8 kodējumu) lietotāja saskarnē un datu ievades formās.Jānodrošina tādu kodējumu atbalsts, kas nodrošina korektu multivalodu, vismaz, latviešu, krievu un angļu valodas, informācijas ievadi, apstrādi, uzglabāšanu un izvadi, piemēram, UTF-8.

N2.14. Izmantojamie standarti un vadlīnijas

RAIS izstrādājama un ieviešama, atkarībā no izstrādes platformas un tehnoloģijām ņemot vērā vismaz šādos standartos un vadlīnijās noteikto:• ANSI/HFES 200 "Human Factors Engineering of Software User Interfaces";• ELMER/ELMER2 "User Interface Guidelines for Governmental Forms on the

Internet".

N3. Izdrukas

N3.1. Izdruku uzstādījumi Sistēmā jāparedz izdrukas automātiski pielāgojumi atkarībā no izdrukājamā satura (konteksta) veida.Informācijas izdruku pielāgojumi nosakāmi, izstrādājot RAIS projektējumu.

N3.2. Izdruku sagatavošana Sistēmai jānodrošina iespēja sagatavot šādas izdrukas:• interaktīvas izdrukas izveidošana un izdrukāšana;

Kā piemēru var minēt - divu veidu interaktīvās atskaites:• Saraksti tabulas veidā, kas var tikt sniegti kā PDF vai MS Excel faili.

Kur iespējams, lietotājam jāspēj definēt tabulas un izvēlēties, kuras lauka vērtības tiks attēlotas un kurus laukus var izmantot vaicājuma formulēšanai, izmantojot datu filtru.

• Revīzijas darba uzdevumu saraksti, kurus var attēlot un sniegt PDF faila veidā (kopā ar atsaucēm uz darba uzdevumiem pievienotajiem dokumentiem). Sagatavojot ziņojumu, lietotājam jāspēj atlasīt konkrētu uzdevumu vai uzdevumu kopumu, kas tiek attēlots uz ekrāna.

• fiksēta satura izdrukas izveidošana un izdrukāšana;

Sistēmai jānodrošina iespēja veikt izdrukas no jebkura RAIS funkcionālā bloka.

N4 Lietotāju pārvaldība

N4.1. Lietotāju grupas Sistēmā jābūt iespējai definēt lietotāju grupas un piešķirt lietotājiem tiesību komplektus atbilstoši vienai vai vairākām tiesību grupām, kas minētas sadaļā „Sistēmas lietotāji”.Lietotājiem jāparedz iespēja atrasties vairākās tiesību grupās.

N5. Drošības prasības

N5.1. Vispārīgi drošības principi Sistēmai jānodrošina, lai tiktu ievēroti sekojoši drošības rādītāji:• Konfidencialitāte – informācija ir pieejama tikai autorizētiem lietotājiem;• Datu integritāte – informācija ir pasargāta no tīšas vai netīšas neautorizētas


modificēšanas;• Pieejamība – informācija un ar to saistītā funkcionalitāte ir pieejama noteiktā

apjomā, laikā un vietā;• Autentiskums – informācijas izcelsme ir pierādāma, sistēma var uzticēties, ka

identitāte ir patiesa;• Atbildība – katru darbību ar informāciju ir jāsasaista ar tās veicēju.

N5.2. Atbilstība IT drošības politikai Sistēmai jāatbilst LZRA IT drošības politikai (nepieciešams pārrunāt tās pamatnoteikumus).

N5.3. Autentifikācija Pirms uzsākt jebkuras darbības ar sistēmu, sistēmas lietotājam ir jāautentificējas sistēmā, ievadot savu lietotāja vārdu un paroli. Šī informācija tiek lietota, lai identificētu lietotāja identitāti un saistīto informāciju.

N5.4. Autorizācija Labvēlīgas autentifikācijas gadījumā sistēma piešķir lietotājam atbilstošu tiesību komplektu – autorizē lietotāju veikt šim lietotājam atļautās darbības.Sistēmai jāuztur tiesību informācija un jānodrošina piekļuves kontrole, lai tikai autorizēti lietotāji varētu piekļūt tās resursiem. Tiesību kontroles realizācijai jāatbilst sekojošiem principiem:• Zina tikai tas, kuram jāzina;• Pienākumu pildīšanai jānodrošina minimālas privilēģijas;• Viss, kas nav atļauts, ir aizliegts.

N5.5. Piekļuves tiesību pārbaude Katram piekļuves kontroles veidam, Izpildītājam prasību analīzes laikā jānosaka un ar Pasūtītāju jāsaskaņo algoritms, pēc kura piekļuves tiesību kontroles laikā tiek noteikts ir vai nav tiesības piekļuvei.Jānodrošina iespēja kontrolēt pieslēgšanās pieeju pie sistēmas, integratora un izmantotās datubāzes ar trešās puses rīkiem (piemēram, ar SQLPlus). Datiem jābūt aizsargātiem ar administratīviem kontiem.

N5.6. Neidentificētam lietotājam atļautās darbības

Neidentificētam lietotājam sistēmā ir atļauts veikt tikai sevis identifikāciju, kā arī darbības, kuras ir paredzētas veikt sistēmas publiskajā vidē (prasību analīzes laikā Pasūtītājam ir jāidentificē publiskajā vidē pieejamās darbības).

N5.7. Lietotāja identificēšana Sistēmai jānodrošina, ka lietotājs tiek identificēts, pirms tiek atļauta jebkāda cita darbība ar sistēmu. Nesekmīgas identifikācijas gadījumā lietotājam jāsaņem paziņojums, ka identifikācija nesekmīga nenodot papildu informāciju, kas var palīdzēt veikt lietotājvārdu vai paroļu pārlasi.

N5.8. Paroļu uzglabāšana Sistēmai jānodrošina, ka paroles sistēmā tiek uzglabātas tikai šifrētā veidā. Šifrēšanai jāizmanto kāda no drošām vienvirziena šifrēšanas metodēm .Veicot paroles maiņu, sistēmai jāpieprasa iepriekšējās paroles atkārtotu ievadu. Ne jaunā, ne iepriekšējā ievadītā parole nedrīkst tikt attēlota uz ekrāna.

N5.9. Informācijas šifrēšana publiskā datu pārraides tīklā

Sistēmai jānodrošina informācijas kodēšana, pārraidot to publiskā datu pārraides tīklā (atskaitot informāciju, kas ir publiski pieejama). Informācijas kodēšanai ir jāizmanto SSL protokols ar vismaz 128 bitu kodēšanu. Tīmekļa pakalpnēm jāizmanto HTTPS datu apmaiņas protokols. Datu konfidencialitātes nodrošināšanai var tikt izmantots W3C "XML Encryption" standarts.

N5.10. Sistēmas drošības kontroļu neapejamība

Jānovērš piekļuve sistēmā glabājamai informācijai, apejot aplikācijas drošības kontroles, veicot kontroļu dublēšanu datu bāzes līmenī.

N5.11. Papildu aizsardzība no ārējiem lietotājiem pieejamām sistēmām

Tiesiski saistošajiem datiem jābūt aizsargātiem pret modificēšanu gadījumos, ja ārējam lietotājam ir izdevies iegūt kontroli pār RAIS.

N5.12. Integritāte Jānodrošina digitālo objektu integritātes kontrole, piemēram, veidojot un kontrolējot failu kontrolsummas.

N5.13. Auditācijas pierakstu veidošana Sistēmai jāveic autorizētiem lietotājiem pieejamo sistēmas nodrošināto procesu auditāciju. Visām integrācijas risinājumā veidotajām tīmekļa pakalpnēm jānodrošina centralizētu sistēmas žurnālu un auditācijas pierakstu veidošanu.

N5.14. Auditācijas pierakstu saturs Katrā auditācijas pierakstā sistēmai jāiekļauj vismaz sekojoša informācija par auditējamo


notikumu:• notikuma datums un laiks;• notikuma veids;• ar notikumu saistītā lietotāja identitāte;• notikuma iznākums – sekmīga vai nesekmīga darbība;• cita, attiecīgajam notikumam specifiska informācija, kas tiks identificēta prasību

analīzes laikā.

N5.15. Auditācijas pierakstu uzglabāšana

Sistēmai jānodrošina pilnvērtīgu un izsekojamu auditācijas pierakstu izveide, kas ir aizsargāti pret ārējiem iedarbības faktoriem, tai skaitā tīšu vai netīšu datu sagrozīšanu.

N5.16. Aizdomīgo darbību identifikācija un brīdināšana

Jāizstrādā aizdomīgo darbību identifikācijas servisa koncepcija (metodoloģija, algoritms vai algoritmu kopums). Servisa darbības koncepciju ir jāpārbauda, lietojot auditācijas un sistēmas žurnāla datus. Aizdomīgo darbību identifikācijas serviss veiks audita notikumu analīzi ar mērķi atklāt neparastas vai aizdomīgas darbības. Aizdomīgo darbību identificēšanas algoritmam ir jābūt dinamiski definējamam (bez sistēmas pārprogrammēšanas. Aizdomīgo darbību identifikācijas servisam ir nepieciešama saskarne lietotāju darbību uzraudzībai un brīdinājumu sūtīšanai.

N5.17. Sesiju pārtraukšanas mehānisms

Sistēmai jārealizē neaktīvas lietotāja sesijas pārtraukšanas mehānisms (lietotāja sesija tiek pārtraukta, sasniedzot noteiktu noildzes laiku. Šo laiku jāvar konfigurēt RAIS administratoriem).

N5.18. Izmantojamie standarti un vadlīnijas

Sistēmas drošības aizsardzības mehānismi izstrādājami un ieviešami, ņemot vērā vismaz šādos standartos un vadlīnijās noteikto:• OWASP izstrādātais A Guide to Building Secure Web Applications and Web Services;• OWASP izstrādātais Testing Guide;• ISO/IEC 27001 "Information security management systems — Requirements" un

ISO/IEC 27002 "Code of practice for information security management";• W3C labā prakse drošu tīmekļa aplikāciju izstrādē.

N6. Veiktspējas un mērogojamības prasības

N6.1. Vienlaicīgo lietotāju skaits RAIS jānodrošina 200 vienlaicīgu lietotāju darbība (CPU skaits un RAM apjoms), ievērojot nākamajā prasībā minētās sistēmas ātrdarbības prasības (jāparedz, ka nākotnē vienlaicīgu lietotāju skaits varētu pieaugt līdz 1000). Paredzams, ka sistēmā varētu tikt reģistrēti ap 100 revidentu uzņēmumu, kur katrs uzņēmums veic aptuveni 10-100 revīzijas gadā.

N6.2. Sistēmas ātrdarbība • Visām ekrāna formām, kas nesatur apjomīgu biznesa loģiku ir pilnībā jāparādās ne vairāk nekā 3 sekunžu laikā;

• Sistēmai ir jāizvada atbilstošs paziņojums lietotājam, ja atbilde no datu bāzes gaidāma ilgāk nekā pēc 3 minūtēm;

• Meklēšanai, kurā datu bāzē atrod līdz 100 meklējamām vienībām, 95% gadījumā jānotiek ātrāk par 5 sekundēm;

• Meklēšanai, kurā datu bāzē atrod vairāk kā 100 meklējamo, 95% gadījumu jānotiek ātrāk par 15 sekundēm;

Viena ieraksta pievienošanai, aktualizācijai vai likvidēšanai datu bāzē 95% gadījumu jānotiek ātrāk par 5 sekundēm.Jebkura lietotāju saskarņu sinhrona pieprasījuma apstrāde ar visu iesaistīto IS izsaukumiem un apstrādēm kopā nedrīkst pārsniegt 40 sekundes.Sistēmai jāspēj apstrādāt līdz 10 pieprasījumiem sekundē un līdz 10 milj. pieprasījumu mēnesī.

N6.3. Datu apjoms Jānodrošina stabila sistēmas darbība, nepārsniedzot definētās sistēmas ātrdarbības prasības pie kopējā datu apjoma, kas sasniedz 20 TB.

N6.4. Datu uzglabāšana Jānodrošina datu uzglabāšana datu bāzē.Digitālos objektus (failus) ir pieļaujams glabāt operētājsistēmas failu sistēmā, vai cita veida tehnoloģiju uzglabāšanas sistēmās.Failu metadati jāglabā datu struktūras, kas nodrošina ātru nepieciešamās informācijas atrašanu un attēlošanu.

N6.5. Informācijas indeksēšana Jānodrošina uzglabātās informācijas indeksācija tiem laukiem, pēc kuriem tiek veikta


meklēšana. Precīzs indeksējamo lauku saraksts definējums RAIS projektējumā.

N7. Sistēmas uzturamība

N7.1. Licenču prasības Visiem sistēmas mezgliem jābūt licencētiem, gan produkcijas gan testēšanas vidēs

N7.2. Testēšanas prasības Piegādātajam jāiesniedz testēšanas procedūras aprakstu, instrukcijas un dokumentu sarakstu ( testēšanas plāns, testēšanas scenāriji, testēšanas norises un problēmu pieteikumu žurnāli).Piegādātajam jāveic sistēmas alfa-testēšanu pirms nodošanas pasūtītājam.Jāveic sistēmas funkcionālā testēšana.Veiktspējas testēšanu pasūtītāja testa vidē ( reālajā laikā un darba aparatūras) pasūtītāja pārstāvja uzraudzībā pie pasūtītāja.Sistēmas veiktspējas testēšanu jāveic:

- ar rezultātu dokumentēšanu katrā mezglā,- mainot lietotāju skaitu no 1 līdz 200,

Visām testēšanas izmaksām jābūt iekļautām piedāvājumā ( tajā skaitā testēšanas rīku un aparatūras noma vai iegāde, licenču iegāde).

N7.3. Monitoringa prasības Nodrošināt sistēmas monitoringu, ar iespēju kontrolēt lietotāju transakciju izpildi, attēlojot tās ekrānā un lokalizēt problēmu jebkurā mezglā.Nodrošināt iespēju automatizēti detalizēt datus (Drill Down) transakcijā, lai varētu atklāt sistēmas komponenti, kura tērē visvairāk resursus.

N7.4. Datu rezerves kopēšana Sistēmai ir jānodrošina automātiska datu dublēšana un rezerves datu kopiju veidošana. Sistēmai ir jānodrošina automātiska datu rezerves kopiju izveide, to glabāšana un arhivēšana, kā arī iespēja izmantot rezerves kopiju datu atgūšanai un atjaunošanai.Rezerves datu kopiju veidošanai ir jābūt iespējamai bez sistēmas darbības pārtraukumiem.Datu rezerves kopiju veidošanu un atjaunošanu var nodrošināt ar datu bāzes vai trešo pušu programmatūras līdzekļiem. Sistēmas rezerves kopēšanas prasības Piegādātājam jāiekļauj „Sistēmas darbības atjaunošanas plānā”.Sistēmas datubāzei jānodrošina bojājumpiecietību un ātru darbspējas atjaunošanu (disaster recovery) avārijas gadījumā, izmantojot datubāzes spoguļošanu.

N7.5. Sistēmas uzturēšanas pārnesamība

Sistēmas uzturēšanu jāspēj veikt Piegādātājam vai jebkuram citam profesionālam programmatūras izstrādes uzņēmumam ar pieredzi izmantotajā izstrādes vidē un produktos. Lai nodrošinātu sistēmas uzturēšanu, Piegādātājam jāpiegādā instalācijas komplekts un dokumentācija (instalēšanas un administrēšanas rokasgrāmata).Pasūtītāja speciālistu apmācība jānodrošina instalēšanas un konfigurēšanas laikā.Sistēmai jābūt produkcijas un testēšanas vidēm.Piedāvājumā darbi, kas ir saistīti ar iekārtu iepirkšanu, piegādi, instalēšanu un konfigurēšanu jāiekļauj un jāuzskaita atsevišķā pozīcijā.

N7.6. Prasības tehnoloģiju atbalstam RAIS izveidē ir jāizmanto mūsdienīgas tehnoloģijas un izstrādes rīki, nodrošinot, ka izmantotās tehnoloģijas tiks uzturētas vēl vismaz 5 gadus no to ražotāju puses, un sistēmas funkcionalitāte šajā periodā varēs tikt papildināta atbilstoši pasūtītāja vajadzībām.

N7.7. Noslodzes sadalīšana Sistēmai ir jāatbalsta serveru aplikācijas un datu bāzes noslodzes sadalīšana (load balancing), dodot iespēju, nākotnē noslodzes pieaugšanas gadījumā, sadalīt pieprasījumus uz vairākiem serveriem, neveicot izmaiņas izstrādātajā programmatūrā.Sistēmas aplikācijām jādarbojas vienlaicīgi aktīvā režīmā vairākos eksemplāros, klasteru mezglos (aplikāciju serverim jābūt iespējai strādāt klastera režīmā active-active).

N7.8. Sistēmas darbības nepārtrauktība

Sistēmai jābūt pieejamai 7 dienas nedēļā 24 stundas diennaktī. Gada laikā jāgarantē vismaz 95% no sistēmas izmantojamības. Laiks, kad sistēmu nav iespējams lietot incidenta gadījumā, jāierobežo līdz 2 stundām (kas atbilst minimālajam nepieciešamajam atveseļošanas laikam (MTTR)).

N7.9. Pārbaudāmība Sistēmai ir jānodrošina iespēja simulēt pieprasījumu atbildes, ja ir saņemts atbilstoša veida pieprasījums, lai varētu veikt automatizētu servisa pieejamības un korektas darbības kontroli.

Documents

dok/IS_tehniska_specifikacija_v_7_… · Web viewiespēja savienot dokumentus (MS Word, MS Excel, PDF) ar darba uzdevuma veidni un mainīt, ... HCMP IBM AIX vidē, Oracle Clusterware