Duke testuar kuti e bardhë

Testimi i përdorshmërisë

A) Testimi i ngarkesës

Testimi i Performancës

Testimi funksional

Duke testuar software

Testimi është procesi i ekzekutimit të një programi (ose një pjese të një programi) me qëllim (ose qëllim) për të gjetur gabime.

Ekzistojnë disa kritere me të cilat është zakon të klasifikohen llojet e testimit. Zakonisht dallohen shenjat e mëposhtme:

I) Sipas objektit të testimit:

(përcaktimi ose grumbullimi i treguesve të performancës dhe kohës së përgjigjes së një sistemi ose pajisjeje softuerike dhe harduerike në përgjigje të një kërkese të jashtme për të përcaktuar përputhjen me kërkesat për këtë sistem)

b) Testimi i stresit

(vlerëson besueshmërinë dhe qëndrueshmërinë e sistemit në kushte të tejkalimit të kufijve të funksionimit normal.)

c) Testimi i stabilitetit

4) Testimi i ndërfaqes së përdoruesit

5) Testimi i sigurisë

6) Testimi i lokalizimit

7) Testimi i përputhshmërisë

II) Nga njohja e sistemit:

1) Testimi i kutisë së zezë

(po testohet një objekt, struktura e brendshme e të cilit nuk dihet)

(Struktura e brendshme e programit kontrollohet, të dhënat e testit merren duke analizuar logjikën e programit)

III) Sipas shkallës së automatizimit:

1) Testimi manual

2) Testimi i automatizuar

3) Testimi gjysmë i automatizuar

IV) Sipas shkallës së izolimit të përbërësve:

1) Testimi i komponentëve (njësive).

2) Testimi i integrimit

3) Testimi i sistemit

V) Deri në momentin e testimit:

1) Testimi alfa- një proces i mbyllur i testimit të programit nga zhvillues ose testues me kohë të plotë. Një produkt alfa është më së shpeshti i plotë vetëm 50%, ka një kod programi, por një pjesë e konsiderueshme e dizajnit mungon.

2) Testimi beta- përdorim i rëndë versioni i përfunduar programe me qëllim identifikimin e numrit maksimal të gabimeve në punën e tij për eliminimin e tyre të mëvonshëm përpara hyrjes përfundimtare në treg, te konsumatori masiv. Në testim përfshihen vullnetarë nga përdoruesit e zakonshëm të ardhshëm.

Verifikimi i softuerit është një koncept më i përgjithshëm sesa testimi. Qëllimi i verifikimit është të arrihet siguria që objekti që verifikohet (kërkesat ose kodi i programit) plotëson kërkesat, zbatohet pa funksione të padëshiruara dhe plotëson specifikimet dhe standardet e projektimit. ISO 9000-2000). Procesi i verifikimit përfshin inspektimet, testimin e kodit, analizën e rezultateve të testit, gjenerimin dhe analizën e raporteve të problemeve. Kështu, përgjithësisht pranohet se procesi i testimit është pjesë integrale procesi i verifikimit.

Shën Petersburg

Universiteti Shtetëror Elektroteknik

Departamenti i MOEM

sipas disiplinës

"Procesi i zhvillimit të softuerit"

"Verifikimi i softuerit"

Shën Petersburg

Qëllimi i verifikimit………………………………………………………………… faqe 3

Vërejtje hyrëse……………………………………………………………….. faqe 3

Synimet speciale dhe të përgjithshme…………………………………………….. faqe 4

Praktika e pritshme sipas objektivave………………………………………… faqe 4

SG1 Përgatitja për Verifikim……………………………………………………. faqe 4

SG2 Kryerja e provimeve (vlerësimi i kolegëve)…………………………… faqe 7

SG3 Zbatimi i Verifikimit…………………………………………………. faqe 9

Shtojca 1. Pasqyrë e mjeteve të automatizimit për procesin e verifikimit……….. faqe 11

Aneksi 2. Kryesor qasjet moderne për verifikim…………….. faqe 12

Lista e literaturës së përdorur…………………………………………….. faqe 14

Një model i integruar i përsosmërisë dhe pjekurisë

Verifikimi (Niveli 3 i maturimit)

Synimi

Qëllimi i verifikimit është duke ofruar siguri që programi i mesëm ose produkti përfundimtar i përzgjedhur plotëson kërkesat e specifikuara.

1. shënime uji

Verifikimi i produkteve softuerike është verifikimi i produktit të përfunduar ose i versioneve të ndërmjetme të tij për të përmbushur kërkesat origjinale. Kjo nënkupton jo vetëm testimin e vetë programit, por edhe auditimin e projektit, dokumentacionit të përdoruesit dhe teknik, etj.

Qëllimi i verifikimit të sistemit të softuerit është të identifikojë dhe raportojë gabimet që mund të bëhen gjatë fazave të ciklit jetësor. Detyrat kryesore të verifikimit:

përcaktimi i përputhshmërisë së kërkesave të nivelit të lartë me kërkesat e sistemit;

duke marrë parasysh kërkesat e nivelit të lartë në arkitekturën e sistemit;

pajtueshmëria me arkitekturën dhe kërkesat për të në kodin burimor;

përcaktimi i përputhshmërisë së kodit të ekzekutueshëm me kërkesat për sistemin;

përcaktimin e mjeteve të përdorura për zgjidhjen e detyrave të mësipërme, të cilat janë teknikisht të sakta dhe mjaftueshëm të plota.

Verifikimi përfshin verifikimin e produkteve të gatshme dhe verifikimin e produkteve të ndërmjetme kundrejt të gjitha kërkesave të përzgjedhura, duke përfshirë kërkesat e klientëve, kërkesat për produktet e gatshme dhe kërkesat për komponentët e tij individualë.

Verifikimi është në thelb një proces inkremental (rritës) që nga momenti i fillimit të tij gjatë zhvillimit të produkteve dhe gjithë punës në produkte. Verifikimi fillon me verifikimin e kërkesave, pastaj pason verifikimin e të gjitha produkteve të ndërmjetme në faza të ndryshme të zhvillimit dhe prodhimit të tyre dhe përfundon me verifikimin e produktit përfundimtar.

Verifikimi i produkteve të ndërmjetme në çdo fazë të zhvillimit dhe prodhimit të tyre rrit ndjeshëm gjasat që produkti përfundimtar të përmbushë kërkesat e klientit, kërkesat për produktin e përfunduar dhe kërkesat për përbërësit e tij individualë.

Verifikimi dhe Vërtetimi i proceseve janë në thelb procese të ndërlidhura, por që synojnë marrjen e rezultateve të ndryshme. Qëllimi i Validimit është të demonstrojë se produkti i përfunduar në të vërtetë përmbush qëllimin e tij origjinal. Verifikimi synon të sigurohet që produkti plotëson saktësisht disa kërkesa. Me fjalë të tjera, Verifikimi siguron që " ju bëni atë të drejtë", dhe vërtetimi është se " ju jeni duke bërë gjënë e duhur”.

Verifikimi duhet të zbatohet sa më shpejt që të jetë e mundur në proceset përkatëse (të tilla si dorëzimi, zhvillimi, funksionimi ose mirëmbajtja) për të vlerësuar efektivitetin e kostos dhe performancën. Ky proces mund të përfshijë analizën, verifikimin dhe testimin (testimin).

Ky proces mund të kryhet me shkallë të ndryshme të pavarësisë së interpretuesve. Shkalla e pavarësisë së interpretuesve mund të shpërndahet si ndërmjet subjekteve të ndryshme në vetë organizatën, ashtu edhe subjekteve në një organizatë tjetër, me shkallë të ndryshme të shpërndarjes së përgjegjësive. Ky proces quhet proces verifikimi i pavarur nëse organizata zbatuese është e pavarur nga shitësi, zhvilluesi, operatori ose mirëmbajtësit.

Vlerësimet e ekspertëve (ekspertizë) janë një pjesë e rëndësishme e verifikimit si një mjet i mirëpërcaktuar për eliminimin efektiv të defekteve. Një avantazh i rëndësishëm nga kjo është nevoja për të zhvilluar një kuptim dhe kuptim më të thellë të versioneve të punës të produktit, si dhe të rrjedhave të punës të përdorura për të identifikuar defektet e mundshme dhe për të krijuar një mundësi për përmirësime nëse është e nevojshme.

Ekzaminimet përfshijnë një studim metodik të punës së kryer nga ekspertët për të identifikuar defektet dhe ndryshimet e tjera të kërkuara.

Metodat kryesore të vlerësimit të ekspertëve janë:

inspektimit

kontrolli strukturor nga fundi në fund

Dy konceptet e vërtetimit dhe verifikimit shpesh ngatërrohen. Për më tepër, vërtetimi i kërkesave të sistemit shpesh ngatërrohet me vërtetimin e sistemit. Unë sugjeroj ta shqyrtojmë këtë çështje.

Në artikull, kam konsideruar dy qasje për modelimin e objekteve: si një e tërë dhe si një strukturë. Në artikullin aktual, do të na duhet kjo ndarje.

Supozoni se kemi një objekt funksional të projektuar. Ky objekt le të konsiderohet prej nesh si pjesë e ndërtimit të një objekti tjetër funksional. Le të ketë një përshkrim të ndërtimit të Objektit, i tillë që të përmbajë një përshkrim të objektit. Në një përshkrim të tillë, objekti ka një përshkrim në tërësi, domethënë ndërfaqet e tij të ndërveprimit me objektet e tjera përshkruhen brenda kornizës së ndërtimit të Objektit. Le të jepet përshkrimi i objektit si strukturë. Le të ketë një objekt informacioni që përmban kërkesa për hartimin e përshkrimit të objektit si strukturë. Le të ketë një grup njohurish që përmban rregulla konkluzionesh, në bazë të të cilave një përshkrim i objektit si strukturë merret nga përshkrimi i objektit në tërësi. Trupi i njohurive është ajo që dizajnerëve u mësohet në institute - shumë, shumë njohuri. Ato lejojnë, në bazë të njohurive për objektin, të hartojnë strukturën e tij.

Pra, mund të filloni. Mund të pohojmë se nëse objekti në tërësi përshkruhet saktë, nëse trupi i njohurive është i saktë dhe nëse respektohen rregullat e konkluzionit, atëherë përshkrimi që rezulton i ndërtimit të objektit do të jetë i saktë. Kjo është, në bazë të këtij përshkrimi, një objekt funksional që korrespondon me kushte reale operacion. Cilat rreziqe mund të lindin:

1. Përdorimi i njohurive të pasakta për Objektin. Modeli i Objektit në mendjet e njerëzve mund të mos korrespondojë me realitetin. Ata nuk e dinin rrezikun e vërtetë të tërmeteve, për shembull. Prandaj, kërkesat për objektin mund të jenë të formuluara gabimisht.

2. Regjistrim jo i plotë i njohurive për Objektin - diçka mungon, bëhen gabime. Për shembull, ata dinin për erërat, por harruan ta përmendnin. Kjo mund të çojë në një përshkrim të pamjaftueshëm të plotë të kërkesave për objektin.

3. Njohuri e gabuar. Na mësuan përparësinë e masës ndaj parametrave të tjerë, por doli që duhej të rrisnim shpejtësinë.

4. Zbatimi i gabuar i rregullave të konkluzionit në përshkrimin e objektit. Gabime logjike, diçka mungon në kërkesat për projektimin e objektit, gjurma e kërkesave është prishur.

5. Regjistrim jo i plotë i konkluzioneve të marra rreth projektimit të sistemit. Gjithçka është marrë parasysh, gjithçka është llogaritur, por kanë harruar të shkruajnë.

6. Sistemi i krijuar nuk përputhet me përshkrimin.

Është e qartë se të gjitha artefaktet e projektit shfaqen, si rregull, në formën e tyre të përfunduar vetëm deri në fund të projektit, dhe madje edhe atëherë jo gjithmonë. Por, nëse supozojmë se zhvillimi është ujëvarë, atëherë rreziqet janë siç përshkrova. Kontrollimi i çdo rreziku është një operacion specifik që mund t'i jepet një emër. Nëse dikush është i interesuar, mund të përpiqeni të gjeni dhe shprehni këto kushte.

Çfarë është verifikimi? Në rusisht, verifikimi është një kontroll për pajtueshmërinë me rregullat. Rregullat janë në formën e një dokumenti. Kjo do të thotë, duhet të ketë një dokument me kërkesat e dokumentacionit. Nëse dokumentacioni plotëson kërkesat e këtij dokumenti, atëherë ai ka kaluar verifikimin.

Çfarë është vërtetimi? Në rusisht, vërtetimi është verifikimi i saktësisë së përfundimeve. Kjo do të thotë, duhet të ketë një grup njohurish që përshkruan se si të merrni një përshkrim të një dizajni bazuar në të dhënat e objektit. Kontrollimi i korrektësisë së zbatimit të këtyre përfundimeve është vërtetim. Vërtetimi është, ndër të tjera, kontrollimi i përshkrimit për qëndrueshmëri, plotësi dhe kuptueshmëri.

Shpesh, vërtetimi i kërkesave ngatërrohet me vërtetimin e një produkti të ndërtuar mbi këto kërkesa. Nuk ia vlen ta bësh këtë.

Ekipi përfshin më shumë se dy persona në mënyrë të pashmangshme ngre çështjen e shpërndarjes së roleve, të drejtave dhe përgjegjësive në ekip. Një grup specifik rolesh përcaktohet nga shumë faktorë - numri i pjesëmarrësve në zhvillim dhe preferencat e tyre personale, metodologjia e zhvillimit të miratuar, veçoritë e projektit dhe faktorë të tjerë. Pothuajse në çdo ekip zhvillimi, mund të dallohen rolet e mëposhtme. Disa prej tyre mund të mungojnë plotësisht, ndërsa njerëz individualë mund të kryejnë disa role në të njëjtën kohë, por përbërja e përgjithshme ndryshon pak.

Klienti (aplikuesi). Ky rol i takon një përfaqësuesi të organizatës që urdhëroi zhvillimin e sistemit. Në mënyrë tipike, aplikanti është i kufizuar në ndërveprimin e tyre dhe komunikon vetëm me menaxherët e projektit dhe një specialist certifikimi ose zbatimi. Zakonisht, klienti ka të drejtë të ndryshojë kërkesat për produktin (vetëm në bashkëpunim me menaxherët), të lexojë dokumentacionin e projektimit dhe certifikimit që ndikon në tiparet jo-teknike të sistemit që po zhvillohet.

Menaxher i Projektit. Ky rol siguron një kanal komunikimi midis klientit dhe ekipit të projektit. Menaxheri i produktit menaxhon pritshmëritë e klientit dhe zhvillon dhe ruan kontekstin e biznesit për projektin. Puna e tij nuk lidhet drejtpërdrejt me shitjen, ai është i fokusuar tek produkti, detyra e tij është të përcaktojë dhe të sigurojë kërkesat e klientëve. Menaxheri i projektit ka të drejtë të ndryshojë kërkesat për produktin dhe dokumentacionin përfundimtar për produktin.

Menaxher i programit. Ky rol menaxhon komunikimet dhe marrëdhëniet brenda ekipit të projektit, vepron si koordinator në një farë mënyre, zhvillon dhe menaxhon specifikimet funksionale, mirëmban orarin e projektit dhe raporton mbi statusin e projektit dhe fillon vendimet kritike për projektin.

Duke testuar- procesi i ekzekutimit të një programi për të zbuluar një gabim.

të dhënat e testimit- hyrjet që përdoren për të testuar sistemin.

Situata e testimit (rast testi)- hyrjet për të testuar sistemin dhe daljet e pritura në varësi të hyrjeve, nëse sistemi funksionon në përputhje me specifikimet e kërkesave.

Rast i mirë provë- një situatë që ka një probabilitet të lartë për të zbuluar një gabim ende të pazbuluar.

test me fat- një test që zbulon një gabim ende të pazbuluar.

Gabim- veprimi i një programuesi në fazën e zhvillimit, duke çuar në faktin se softueri përmban një defekt të brendshëm, i cili, gjatë funksionimit të programit, mund të çojë në një rezultat të pasaktë.

Refuzimi- sjellje e paparashikueshme e sistemit, që çon në një rezultat të papritur, i cili mund të shkaktohet nga defektet e përfshira në të.

Kështu, në procesin e testimit të softuerit, si rregull, kontrollohen sa vijon.

Verifikimi dhe vërtetimi ( verifikimi dhe vërtetimi-V& v) janë krijuar për të analizuar, verifikuar ekzekutimin e saktë dhe përputhshmërinë e softuerit me specifikimet dhe kërkesat e klientit. Këto metoda të kontrollit të korrektësisë së programeve dhe sistemeve përkatësisht nënkuptojnë:

• verifikimi është verifikimi i korrektësisë së krijimit të sistemit në përputhje me specifikimet e tij;
• Validimi është një verifikim i saktësisë së përmbushjes së kërkesave të specifikuara për sistemin.

Verifikimi ndihmon për të nxjerrë një përfundim në lidhje me korrektësinë e sistemit të krijuar pas përfundimit të projektimit dhe zhvillimit të tij. Validimi ju lejon të përcaktoni realizueshmërinë e kërkesave të specifikuara dhe përfshin një numër veprimesh për të marrë programet dhe sistemet e duhura, përkatësisht:

• planifikimi i procedurave të inspektimit dhe kontrollit zgjidhjet e projektimit dhe kërkesat;
• sigurimi i nivelit të automatizimit të projektimit të programit me CASE-means;
• kontrollimi i funksionimit të saktë të programeve përmes metodave të testimit në grupet e testeve të synuara;
• përshtatja e produktit me mjedisin e funksionimit etj.

Validimi i kryen këto aktivitete duke rishikuar dhe inspektuar specifikimet dhe rezultatet e projektimit në fazat e ciklit jetësor për të konfirmuar se ka një zbatim të saktë të kërkesave fillestare dhe se kushtet dhe kufizimet e specifikuara janë përmbushur. Detyrat e verifikimit dhe vërtetimit përfshijnë kontrollimin e plotësisë, konsistencës dhe paqartësisë së specifikimeve të kërkesave dhe korrektësisë së performancës së funksioneve të sistemit.

Verifikimi dhe vërtetimi i nënshtrohen:

• komponentët kryesorë të sistemit;
• ndërfaqet e komponentëve (softuerike, teknike dhe informative) dhe ndërveprimet e objekteve (protokollet dhe mesazhet) që sigurojnë zbatimin e sistemit në mjedise të shpërndara;
• mjetet e qasjes në bazën e të dhënave dhe skedarët (transaksionet dhe mesazhet) dhe verifikimin e mjeteve të mbrojtjes nga aksesi i paautorizuar në të dhënat e përdoruesve të ndryshëm;
• dokumentacion për softuerin dhe për sistemin në tërësi;
• testet, procedurat e testimit dhe të dhënat hyrëse.

Me fjalë të tjera, metodat kryesore sistematike të korrektësisë së programit janë:

• verifikimi Vlefshmëria e specifikimeve të komponentëve PS dhe kërkesave;
• Inspektimi i PS të vendosë përputhshmërinë e programit me specifikimet e dhëna;
• duke testuar Kodi i daljes së PS në të dhënat e testimit në një mjedis specifik operimi për të identifikuar gabimet dhe defektet e shkaktuara nga defekte të ndryshme, anomali, dështime të pajisjeve ose prishje të sistemit (shih Kapitullin 9).

ISO/IEC 3918-99 dhe 12207 përfshijnë proceset e verifikimit dhe vërtetimit. Për ta, përcaktohen qëllimet, detyrat dhe veprimet për të verifikuar korrektësinë e produktit të krijuar (përfshirë produktet e punës, të ndërmjetme) në fazat e ciklit jetësor dhe pajtueshmërinë me kërkesat e tij.

Detyra kryesore e proceseve të verifikimit dhe vërtetimit është që kontrolloni dhe konfirmoni që softueri përfundimtar të jetë i përshtatshëm për qëllimin dhe të plotësojë kërkesat e klientit. Këto procese ju lejojnë të identifikoni gabimet në produktet e punës të fazave të ciklit jetësor, pa zbuluar arsyet e shfaqjes së tyre, si dhe të përcaktoni korrektësinë e softuerit në lidhje me specifikimin e tij.

Këto procese janë të ndërlidhura dhe përcaktohen nga një term - "verifikimi dhe vlefshmëria" (V&V 7).

Verifikimi kryhet:

• verifikimi i korrektësisë së përkthimit të përbërësve individualë në kodin e daljes, si dhe përshkrimet e ndërfaqes duke gjurmuar marrëdhëniet e komponentëve në përputhje me kërkesat e specifikuara të klientit;
• analiza e korrektësisë së aksesit në skedarë ose një bazë të dhënash, duke marrë parasysh procedurat e miratuara në mjetet e sistemit që përdoren për manipulimin e të dhënave dhe transmetimin e rezultateve;
• verifikimi i mjeteve mbrojtëse të komponentëve për përputhjen me kërkesat e klientëve dhe gjurmimin e tyre.

Pas kontrollit të përbërësve individualë të sistemit, kryhet integrimi i tyre, si dhe verifikimi dhe vlefshmëria e sistemit të integruar. Sistemi testohet në një mori grupesh testimi për të përcaktuar nëse grupet e testimit janë të përshtatshme dhe të mjaftueshme për të përfunduar testin dhe për të përcaktuar korrektësinë e sistemit.

Ideja e krijimit të një projekti ndërkombëtar për verifikimin zyrtar u propozua nga T. Hoare, ajo u diskutua në një simpozium mbi softuerin e verifikuar në shkurt 2005 në Kaliforni. Më pas, në tetor të të njëjtit vit, në konferencën e IFIP në Cyrih, u miratua një projekt ndërkombëtar për një periudhë 15-vjeçare për të zhvilluar një "grumbullim holistik të automatizuar të mjeteve për kontrollimin e korrektësisë së PS".

Ai formuloi detyrat kryesore të mëposhtme:

• zhvillimi i një teorie të unifikuar të ndërtimit dhe analizës së programeve;
• ndërtimi i një grupi gjithëpërfshirës të integruar të mjeteve të verifikimit për të gjitha fazat e prodhimit, duke përfshirë zhvillimin e specifikimeve dhe verifikimin e tyre, gjenerimin e rasteve të testimit, përsosjen, analizën dhe verifikimin e programeve;
• krijimi i një depoje të specifikimeve formale dhe objekteve të verifikuara të softuerit tipe te ndryshme dhe llojet.

Ky projekt supozon se verifikimi do të mbulojë të gjitha aspektet e krijimit dhe kontrollit të korrektësisë së softuerit dhe do të bëhet një ilaç për të gjitha problemet që lidhen me shfaqjen e vazhdueshme të gabimeve në programet që krijohen.

Shumë metoda formale për vërtetimin dhe verifikimin e programeve të specifikuara janë testuar në praktikë. U krye punë e madhe komiteti ndërkombëtar ISO/IEC në kuadër të Standardi ISO/ IEC 12207:2002 mbi standardizimin e proceseve të verifikimit dhe vlefshmërisë së softuerit. Kontrollimi i korrektësisë me metoda formale të objekteve të ndryshme programimi është premtues.

Depoja është një depo e programeve, specifikimeve dhe mjeteve të përdorura në zhvillimin dhe testimin, vlerësimin e komponentëve të përfunduar, mjetet dhe metodat bosh. Ai ka këto detyra të përgjithshme:

• akumulimi i specifikimeve të verifikuara, metodave të vërtetimit, objekteve të programit dhe zbatimeve të kodeve për aplikacione komplekse;
• grumbullimi i metodave të ndryshme të verifikimit, dizajnimi i tyre në një formë të përshtatshme për kërkimin dhe përzgjedhjen e një ideje teorike të realizuar për aplikim të mëtejshëm;
• zhvillimi i formave standarde për vendosjen dhe shkëmbimin e specifikimeve formale të objekteve të ndryshme programore, si dhe mjeteve dhe sistemeve të gatshme;
• zhvillimi i mekanizmave të ndërveprimit dhe ndërveprimit për transferimin e produkteve të përfunduara të verifikuara nga depoja në mjedise të reja të shpërndara dhe të rrjetit për të krijuar PS të reja.

Ky projekt mendohet të zhvillohet brenda 50 viteve. Projektet e mëparshme vendosën synime të ngjashme: përmirësimi i cilësisë së softuerit, formalizimi i modeleve të shërbimit, reduktimi i kompleksitetit nëpërmjet përdorimit të PIC-ve, krijimi i mjeteve korrigjuese për diagnostikimin vizual të gabimeve dhe eliminimin e tyre, etj. Megjithatë, një ndryshim thelbësor në programim nuk ka ndodhur as në kuptimin e korrigjimi vizual ose në arritje Cilesi e larte AKTIV. Procesi i zhvillimit vazhdon.

Një projekt i ri ndërkombëtar i verifikimit të softuerit kërkon nga pjesëmarrësit e tij jo vetëm njohuri aspektet teorike specifikimet e programit, por edhe programues shumë të kualifikuar për zbatimin e tij në vitet në vijim.