Atbildes uz pretendentu uzdotajiem jautājumiem
Atbildes uz pretendentu uzdotajiem jautājumiem
Atbildes uz pretendentu uzdotajiem jautājumiem
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Atbildes</strong> <strong>uz</strong> <strong>pretendentu</strong> <strong>uz</strong>dotajiem <strong>jautājumiem</strong><br />
Jautājums Nr.1.<br />
Pretendents lūdz skaidrot Nolikuma punktu 3.4.2.1.4. un 3.4.2.2.3. izvirzītās prasības par pieredzi<br />
pamatotību, kad Pretendentam tiek izvirzītas prasības par pieredzi pēdējo trīs gadu laikā ar Oracle<br />
Designer rīkiem Repository Object Navigator, Function Hierarchy Diagrammer, Entity<br />
Relationship Diagrammer, Design Editor, Matrix Diagrammer, Repository Reports.<br />
Pretendents pašreiz esošo Nolikuma redakcijas punktu 3.4.2.1.4. un 3.4.2.2.3. izvirzītās prasības<br />
pamatotības apstrīdēšanu un konkurenci ierobežojošo faktoru pamatošanu skaidro ar sekojošo:<br />
1. IT testēšanas novirzienā pasaulē plaši tiek pielietota melnās kastes testēšanas metodoloģija<br />
(no angļu val. - black box testing). Metodoloģijas būtība ir tāda, ka validācijas process tiek<br />
balstīts <strong>uz</strong> ieejas un izvades datiem, kā rezultātā iespējams validēt, vai testējamais objekts ir<br />
korekti funkcionējošs. Šī testēšanas metodoloģija ir paredzēta gan vienību testu, gan<br />
integrācijas testu, gan sistēmas testu, gan akcepttestu veidošanā un izpildē.<br />
2. Izpētot konkrētā konkursa Nolikumu, tika secināts, ka konkrētās sistēmas izmaiņu<br />
testēšanas prasības neietver tādus testēšanas nosacījumus, kur būtu jāpiemēro vēl citas<br />
testēšanas metodes, tāpēc Pretendents <strong>uz</strong>skata, ka melnās kastes testēšanas metodoloģija<br />
pilnībā atbilst šī konkursa Nolikuma izvirzītajām prasībām.<br />
3. Pieņemot, ka tiek izmantota melnās kastes testēšanas metodoloģija, Pretendents <strong>uz</strong>skata, ka<br />
šī konkursa Nolikuma punktu 3.4.2.1.4. un 3.4.2.2.3. izvirzītās prasības ierobežo un rada<br />
tādus apstākļus, pretēji, ja nebūtu šo ierobežojumu, kā rezultātā būtu iespējama efektīvāka<br />
un kvalitatīvāka sistēmas izmaiņu testēšana vai jebkādā citādā veidā nodrošināta augstākas<br />
testēšanas kvalifikācijas piemērošana un realizēšana atbilstoši šī paša Nolikuma<br />
izvirzītajam priekšmetam.<br />
Tāpat Pretendents lūdz skaidrot, kādi testēšanas pakalpojumu sniegšanas kvalitātes faktori tiek<br />
ietekmēti, Pretendentam pielietojot Nolikuma punktu 3.4.2.1.4. un 3.4.2.2.3. izvirzītās<br />
kvalifikācijas prasības, kā arī lūgums sniegt skaidrojumu, kādā mērā šie testēšanas pakalpojumu<br />
sniegšanas kvalitātes faktori nodrošina atbilstošāku kvalifikāciju un Nolikuma priekšmeta izpildi<br />
salīdzinājumā ar citu pretendenta izvēlētu ekvivalentu kvalifikācijas prasību piemērošanu?<br />
Atbilde<br />
Iepirkuma nolikuma 1.pielikuma „Tehniskā specifikācija” (turpmākām – tehniskā specifikācija)<br />
4.1. punktā ir noteikts, ka testētājiem ir jāveic ne tikai veikto izmaiņu akcepta testēšana, bet ir<br />
jāveic arī nodevumu kvalitātes pārbaude. Nodevumu kvalitātes pārbaude ietver programmatūras<br />
prasību specifikāciju un programmatūras novērtēšanu <strong>uz</strong> to atbilstību Pasūtītāja apstiprinātajiem<br />
izstrādes standartiem un vadlīnijām. Programmatūras testēšanā ir iespējams izmantot „melnās<br />
kastes metodoloģiju”, tomēr nodevumu kvalitātes pārbaudes nav iespējams veikt neprotot strādāt ar<br />
ORACLE Designer rīkiem un nezinot ORACLE specifiku. Līdz ar to, nolikuma<br />
3.4.2.1.4. apakšpunkta un nolikuma 3.4.2.2.3. apakšpunkta prasības ir pamatotas un saistītas ar<br />
iepirkuma priekšmetu.<br />
Jautājums Nr.2.<br />
Pretendents lūdz sniegt skaidrojumu par nolikumam pievienotajā pielikumā - "Tehniskā<br />
specifikācija", punktos "6.1.1. Testētāja <strong>uz</strong>devumu īss apraksts" un "6.1.2. Vadošā testētāja<br />
<strong>uz</strong>devumu īss apraksts" ietvertajām testēšanas <strong>uz</strong>devumu prasībām, kur minēts, ka testētājiem ir<br />
jāveic testa scenāriju izstrāde un izpilde, savukārt vadošajam testētājam ir jāveic nodevumu<br />
kvalitātes pārbaude. Vai ar <strong>uz</strong>devumu „nodevuma kvalitātes pārbaude” ir jāsaprot „Ievaddati”<br />
sadaļā minēto dokumentu atbilstības validēšana?<br />
Atbilde<br />
Tehniskās specifikācijas 6. sadaļā ar <strong>uz</strong>devumu „Nodevumu kvalitātes pārbaude” ir jāsaprot visu<br />
Izstrādātāja (skat. izmantoto terminu tehniskās specifikācijaspreambulā) sagatavoto nodevumu<br />
attiecībā <strong>uz</strong> programmatūras prasību specifikāciju un programmatūras tekstiem pārbaudi <strong>uz</strong>
2<br />
atbilstību Tehniskās specifikācijas 3.1. punkta tabulā pozīcijās nr.p/k 4., 6., 7., 12. norādītajiem<br />
SAIS izstrādes normatīviem. Tas nozīmē, ka ar <strong>uz</strong>devumu „nodevuma kvalitātes pārbaude” ir<br />
jāsaprot vadošā testētāja <strong>uz</strong>devumu īsā apraksta „Ievaddati” sadaļā minēto dokumentu atbilstības<br />
standartiem validēšanu.<br />
Jautājums Nr.3.<br />
Nolikumam pievienotajā pielikumā - "Tehniskā specifikācija", punktā "6.1.2.1. Nodevumu<br />
akceptēšana" ir minēts: "Atkārtots kvalitātes pārbaudes kopsavilkums". Vai Pretendents pareizi<br />
saprot, ka nodevuma akcepttestēšana ir jāveic vairākas reizes? Ja jā, tad lūgums sniegt skaidrojumu,<br />
cik reizes jāveic nodevuma akceptēšana?<br />
Atbilde<br />
Nodevumu kvalitātes pārbaudes (nevis akcepta testēšana) ir jāveic 2 (divas) reizes, pārbaudot vai<br />
Izstrādātājs (skat. izmantoto terminu Tehniskās specifikācijas preambulā) ir novērsis pirmajā<br />
pārbaudē atklātās kļūdas. Katra moduļa akcepta testēšanu veic tikai vienu reizi, pēc kuras tiek<br />
sagatavots kopsavilkums par konstatētajām nepilnībām.<br />
Jautājums Nr.4.<br />
Pretendents lūdz precizēt, ka testēšanas gaitā tiek nodrošināta iespēja izmantot sistēmas versiju,<br />
kurā pāreja <strong>uz</strong> eiro vēl nav nodrošināta. Piemēram, atsevišķā testēšanas vidē <strong>uz</strong>stādīta sistēma, kurā<br />
būtu iespējams veikt rezultātu salīdzināšanu ar sistēmu, kurā jau veiktas izmaiņas/pāreja <strong>uz</strong> eiro.<br />
Rezultātā tas ļautu efektīvāk veikt izmaiņu validēšanu.<br />
Atbilde<br />
Pasūtītājam nav iespējams nodrošināt 2 (divu) paralēlu vižu <strong>uz</strong>turēšanu visu testēšanas laiku, jo<br />
datu bāze aizņem vairāk nekā 3 (trīs) terabaitus. Ir jāparedz visu atskaišu, ekrānformu un procesu<br />
izpilde testēšanas vidē, kurā nav notikusi datu konvertācija. Pēc tam jāveic datu konvertācijas<br />
<strong>uz</strong>devums un visi procesi jāatkārto pārveidotajā vidē. Pasūtītājs risina jautājumu par iespējām<br />
nodrošināt paralēlas vides testēšanai.<br />
Jautājums Nr.5.<br />
Konkursa nolikuma 1. pielikuma "Tehniskā specifikācija" 1. pielikumā "PROJEKTA PIEGĀŽU<br />
UN NODEVUMU GRAFIKS" ir minēti sekojoši <strong>uz</strong>devumi:<br />
1. Latu simbola nomaiņa ar eiro SAIS ekrānformās un atskaitēs; atskaites 2 valūtās<br />
2. SAIS naudas lauku konvertācijas moduļa izstrāde<br />
Vai pretendents pareizi saprot, ka tikai 2. <strong>uz</strong>devuma ietvaros dati ekrānformās un pārējos sistēmas<br />
objektos (atskaitēs, izdrukās) tiks konvertēti no latiem <strong>uz</strong> eiro pēc pārejas kursa?<br />
Lūgums detalizētāk paskaidrot, kādas korektīvas darbības sistēmā tiks veiktas, realizējot 2.<br />
<strong>uz</strong>devumu?<br />
Atbilde<br />
Tehniskās specifikācijas 1. pielikumā „Projekta piegāžu un nodevumu grafiks” 2. <strong>uz</strong>devuma „SAIS<br />
naudas lauku konvertācijas moduļa izstrāde” ietvaros tiks izstrādāta datu konvertācijas programma,<br />
kura visus datu bāzes laukus, kuri satur summas latos, konvertēs <strong>uz</strong> euro pēc pārejas kursa.<br />
Izstrādātājiem ir <strong>uz</strong>devums dažām atskaitēm, kuras ir norādītas Tehniskās specifikācijas 2.<br />
pielikumā, nodrošināt izdrukas arī latos.<br />
Jautājums Nr.6.<br />
Pretendents lūdz sniegt skaidrojumu, ja Līguma izpildes termiņš noteikts no 01.09.2013 –<br />
31.10.2013. Izpildes termiņš ir tieši saistīts ar izstrādātāja gatavoto nodevumu iesniegšanas<br />
termiņiem.<br />
Kā notiks līguma izpildes termiņu korekciju veikšana gadījumos, ja tiks kavēti izstrādātāja<br />
nodevumu iesniegšanas termiņi? Papildus lūdzam skaidrot Tehniskās specifikācijas 1.pielikumā(<br />
Projektu piegāžu un nodevumu grafiks) norādītos iesniegšanas datumus, kuru izpildes termiņi ir
3<br />
2013.gada jūnijs un jūlijs, t.i., jau pirms konkrētā iepirkuma piedāvājumu iesniegšanas termiņa<br />
beigām.<br />
Atbilde<br />
Saskaņā ar Tehniskās specifikācijas 1. pielikumā „Projekta piegāžu un nodevumu grafiks” 3. un<br />
4.punktu Izstrādātāja pēdējie nodevumi paredzēti 30.09.2013. un testētājiem ir dots 1 (viens)<br />
mēnesis, lai notestētu pēdējos iesniegtos nodevumus.<br />
Ja izstrādātāji nodevumus neiesniegs plānā dotajā termiņā, tad tiks testētas tikai tās programmatūras<br />
sadaļas un dokumentācija, kura būs pilnībā pabeigta līdz 30.09.2013. Ja būs būtiski Izstrādātāja<br />
noteikto termiņu kavējumi, var tikt ierosināti Līguma termiņa grozījumi, bet darbu apjoms un<br />
samaksa paliek nemainīgi.<br />
Nodevumi, kuri būs iesniegti pirms testēšanas <strong>uz</strong>sākšanas ir jāvērtē un jātestē kopā ar visu<br />
testēšanai iesniegto programmatūru.<br />
Jautājums Nr.7.<br />
Pretendents lūdz sniegt skaidrojumu par Līguma 3.4.punktā minēto kritēriju “Ja pasūtītājs<br />
<strong>uz</strong>skata,…”! Kādi objektīvi apstākļi var būt par pamatu Pasūtītāja “<strong>uz</strong>skatam”, ka Izpildītāja<br />
personāla darbība un Pakalpojumu kvalitāte neatbilst Līguma noteikumiem.<br />
Atbilde<br />
Iepirkuma nolikuma 4.pielikuma „Līguma projekts (turpmāk – līguma projekts) 3.4. punktā jau ir<br />
minēti objektīvi apstākļi pasūtītāja iemesliem konkrētās personas atsaukšanai vai aizstāšanai ar citu<br />
– t.i. Izpildītāja personāla darbība neatbilst līguma noteikumiem un/ vai Pakalpojuma kvalitāte<br />
neatbilst līguma noteikumiem. Piemēram, ja pasūtītājam ir jāmāca testētājs kā veicama testēšana<br />
vai kā dokumentējama testēšanas gaita, tad pasūtītājam ir tiesības lūgt nomainīt nekvalitatīvu<br />
personālu. Pasūtītājs ir ieinteresēts saņemt kvalitatīvu pakalpojumu.<br />
Jautājums Nr.8.<br />
Pretendents lūdz skaidrot un detalizēti precizēt, kas ir <strong>uz</strong>skatāma par “garantiju” sniegtajiem<br />
testēšanas pakalpojumiem un kādi var būt iespējamie konstatētie trūkumi garantijas termiņa<br />
ietvaros? Pretendenta ieskatā garantijas nosacījumi attiecībā <strong>uz</strong> konkrētā Pakalpojuma rezultātiem<br />
nav piemērojami un līguma projekta teksts ir koriģējams, dzēšot 4.nodaļu, gan arī atsauces <strong>uz</strong><br />
garantijas nosacījumiem citur līguma tekstā (t.sk. dzēšot noteikumus par garantijas saistību izpildes<br />
nodrošinājuma iesniegšanu – līguma 7.nodaļa, kā arī līguma 10.5.p.kas Pretendenta ieskatā<br />
attiecināms <strong>uz</strong> soda sankciju piemērošanu izstrādes līguma izpildes gadījumā).<br />
Ja garantijas nosacījumi tiek precizēti un saglabāti tekstā, Pretendents lūdz skaidrot, ar ko pamatota<br />
4.4.2.punktā ietvertā saistībā ierasties pie Pasūtītāja 3 stundu laikā, kā arī novērst “konstatētos<br />
trūkumus” divu darba dienu laikā.<br />
Atbilde<br />
Tā kā Pasūtītājam nav iespēju pārbaudīt vai ir notestēta visa programmatūra, Pasūtītājs patur<br />
tiesības pieprasīt atsevišķu moduļu atkārtotu testēšanu garantijas laikā, ja ekspluatācijas laikā tiks<br />
atklāti nenotestēti programmatūras moduļi. Ja tādi moduļi tiks konstatēti, tad Izpildītājam 3 stundu<br />
laikā jāierodas pie Pasūtītāja un 2 darba dienu laikā jāveic atkārtota testēšana un jāsagatavo<br />
testēšanas kopsavilkums. Pasūtītājam nav iespēju pašam veikt sarežģītu procesu testēšanu, bet<br />
jāsasniedz kvalitatīvs rezultāts. Garantijas nosacījumi Līguma projektā tiks saglabāti.<br />
Jautājums Nr.9.<br />
Pretendents lūdz skaidrot, kādas ir noformējuma prasības attiecībā <strong>uz</strong> 5.2.1.punktā minēto<br />
“piegādes ziņojumu”?<br />
Atbilde<br />
Līguma projekts neparedz noteiktu formu piegādes ziņojumam. Tomēr piegādes ziņojumam ir<br />
jāsatur kopsavilkums par testēšanas laikā veiktajām aktivitātēm, sasniegtajiem rezultātiem un
4<br />
konstatētajām nepilnībām. Piegādes ziņojumu paraksta izpildītāja pilnvarotais pārstāvis un saskaņo<br />
pasūtītāja pilnvarotais pārstāvis.<br />
Jautājums Nr.10.<br />
Pretendents lūdz precizēt, kurš datums būs <strong>uz</strong>skatāms par nodevuma iesniegšanas datumu? Ja par<br />
nodevumu iesniegšanas datumu tiek <strong>uz</strong>skatīts akta parakstīšanas datums, tad ņemot vērā līguma<br />
5.3.punktā noteikto nodevumu saskaņošanas termiņu (20 darba dienas), pat teorētiski nav iespējams<br />
nodrošināt Tehniskajā specifikācijā norādīto nodevumu iesniegšanas termiņu ievērošanu<br />
Atbilde<br />
Saskaņā ar Līguma projekta 5.2. punktu nodevums ir jāiesniedz ne vēlāk par 30.10.2013.<br />
Nodevuma pārbaude notiek ne vairāk kā 20 dienas. Ja pārbaude rezultāts ir pozitīvs, tiek sagatavots<br />
nobeiguma pieņemšanas nodošanas akts, rēķins un bankas garantija. Nodevumu iesniegšanas<br />
termiņš nav akta parakstīšanas datums bet piegādes ziņojuma saņemšanas datums.<br />
Jautājums Nr.11.<br />
Pretendents lūdz precizēt, vai ar 5.3.1.un 5.3.2.punktos pielietoto terminu “ja tie neatbilst Pasūtītāja<br />
noteiktajām prasībām” saprotama atbilstība Līguma un tā pielikumu prasībām? Vai ar to var tikt<br />
aptvertas arī citas, Pasūtītāja papildus definētas prasības?<br />
Atbilde<br />
Pasūtītājs savas prasības ir izvirzījis un noteicis gan līguma, gan tā pielikuma noteikumos. Līdz ar<br />
to, ar līguma projekta 5.3.1. un 5.3.2.apakšpunkos noteikto terminu „ja tie neatbilst Pasūtītāja<br />
noteiktajām prasībām” jāsaprot atbilstība Līguma un tā pielikumu prasībām.<br />
Jautājums Nr.12.<br />
Pretendents lūdz skaidrot vai attiecībā <strong>uz</strong> 10.9.punktu un 11.10.punktu – vai pakalpojuma izpilde<br />
tiks veikta testa vidē? Pozitīvas atbildes gadījumā, Pretendenta ieskatā nevar iestāties punktā<br />
minētie apstākļi un šie abi punkti ir dzēšami pilnībā.<br />
Atbilde<br />
Pasūtītāja testa vide satur reālus personu datus, jo testa datu bāzes tiek izmantotas reālu problēmu<br />
situāciju izpētei un tāpēc nav iespējams testa vidēs „nobojāt” personu kodus, lai personu dati kļūtu<br />
nepieejami ārējiem konsultantiem.<br />
Jautājums Nr.13.<br />
Pretendents lūdz skaidrojumus, kā līgumiski tiek risināta situācija, kad Pasūtītājs nebūs nodrošinājis<br />
līguma izpildei nepieciešamo informāciju (līguma 11.1.2.punkts) un šī iemesla tiks kavēta vai nebūs<br />
iespējama pakalpojumu sniegšana/pabeigšana līgumā noteiktā termiņa ietvaros?<br />
Atbilde<br />
Pasūtītājs ir ieinteresēts pakalpojuma savlaicīgā un kvalitatīvā izpildē un tādēļ vēl jo vairāk<br />
ieinteresēts nodrošināt izpildītāju ar visu nepieciešamo informāciju un operatīvi risināt visus<br />
jautājumus, lai nodrošinātu darbu kvalitatīvu un savlaicīgu izpildi.<br />
Turklāt saskaņā ar līguma projekta 11.12.apakšpunktu katra puse ir atbildīga par līguma<br />
neizpildīšanu vai par to, ka līgums nav izpildīts pienācīgi tās vainas dēļ. Respektīvi, izpildītājs<br />
nevarēs tikt vainots, ja līguma izpildes termiņš vai veiktā pakalpojuma kvalitāte neatbildīs līguma<br />
noteikumiem dēļ tā, ka pasūtītājs izpildītāju nebūs savlaicīgi nodrošinājis ar nepieciešamo<br />
informāciju un tieši dēļ šā iemesla būs iestājies līguma pārkāpums.<br />
Jautājums Nr.14.<br />
Pretendenta ieskatā Līguma 11.2.1.punktā minēto izmaiņu veikšana tieši ietekmēs līguma izpildes<br />
kārtību un termiņus. Vai Pretendents pareizi saprot, ka “informēšana” tiek veikta pirms jebkādu<br />
minēto izmaiņu izdarīšanas un izmaiņas nevar skart tās daļas, attiecībā <strong>uz</strong> kurām tiek veikti līgumā<br />
minētie testēšanas darbi?
5<br />
Atbilde<br />
Ja programmatūrā tiek veiktas izmaiņas, tad tiek sagatavots laidiens un <strong>uz</strong>likts arī testēšanas vidē<br />
par ko tiks informēti testētāji. Ja izmaiņas skars daļas, kurām tiek veikti līgumā minētie testēšanas<br />
darbi un testēšana attiecīgām sadaļām būs pabeigta, Pasūtītājs <strong>uz</strong>ņemas visu atbildību par izmaiņām<br />
un sadaļu testēšanu veiks pats.<br />
Jautājums Nr.15.<br />
Lūdzam apstiprināt, ka, ņemto vērā Tehniskajā specifikācijā norādīto darba veidu un apjomu, par<br />
informācijas sistēmu izstrādes pakalpojumiem nolikuma 3.4.1.punkta kontekstā tiks <strong>uz</strong>skatīti<br />
testēšanas pakalpojumi, ievērojot, ka testēšana parasti ir daļa no IS izstrādes dzīves cikla.<br />
Atbilde<br />
Ņemot vērā prasītā pakalpojuma specifiku, testēšanas pakalpojumu projekts tiks <strong>uz</strong>skatīts par<br />
atbilstošu norādītajam nolikuma punktam
Change language