Va kommunikatsiyalarini rivojlantirish vazirligi muhammad al-xorazmiy nomidagi toshkent axborot

 
3.3.2. Dasturni tekshirish 
 
Dasturni  tekshirish-“expert  baxolash”,  bunda  jamoa  a‘zolari  hamkorlikda 
yaratilayotgan  dasturda  hatoliklarni  topihadi.  8  bobda  aytganimdek  tekshiruv 
dasturiy ta‘minotning tekshiruv va ratifikatsiya qismi bo‘lishi mumkin. Ular dastur 

---

98 
 
bajarilishini  talab  qilmagani  uchun  sinovdan  o‘tkazishga  qo‘shimcha  bo‘lishi 
mumkin. Budegani  tizimning  to‘liq bo‘lmagan  versiyalari  hamda  UML  modellari 
kabi  taqdimotlari  tekshirilishi  mumkin.  Gilb  va  Graham  (1993)  tekshuruvlarning 
samarali  foydalanish  usullari  sifatida  tizim  buzilishlarini  ko‘rishni  taklif  etishgan. 
Tekshiruvlar testlardagi muammolarni aniqlashga va dasturni hatolarini samarasini 
yaxshilashga yordam beradi. 
Dasturlarni  tekshirishga  jamoaning  har-xil  a‘zolari  taklif  etiladi  va  ular 
ehtiyotkorlik  bilan  dasturning  dastlabki  kodini  tekshirib  chiqishadi.  Ular  hato  va 
muammolarni  topishadi  va  tekshiruvchilar  uchrashuvida  tasniflab  beradi.  Bu 
hatolar mantiqiy hato noto‘g‘ri shartni ko‘rsatuvchi anomaliya, kodda qolib ketgan 
joylar  bo‘lishi  mumkin.  Tekshiruv  jamoasi  model  dizayni  yoki  dastur  kodini 
tuzatilishi kerak bo‘lgan detal va asosiy anomaliya borligiga tekshiradi. 
Tekshiruv  paytida  hatoliklarni  topishni  yengillashtirishni  topish  uchun 
umumiy  dasturiy  hatoliklarning  nazorat  ro‘yhati  ishlatiladi.  Bu  nazorat  ro‘yhati 
kotiblardagi 
misollarga 
yoki 
alohida 
amaliy 
sohada 
keng 
tarqalgan 
defektlarhaqidagi  bilimlarga  soslanishi  mumkin.  Dasturlashning  har-xil  tillari 
uchun  siz  alohida  nazorat  ro‘yhatini  ishlatasiz,  chunki  har  bir  tilda  o‘ziga  hos 
hatoliklar  bo‘ladi.  Xamfri(1989)  tekshiruvlarni  har  tomonlama  muhokamasida 
tekshirishning nazorat ro‘yhatlarining ko‘p misolini keltirgan.  
Tekshiruv  jarayonida  bajarilishi  mumkin  bo‘lgan  tekshirishlar  3.8  rasmda 
ko‘rsatilgan.  Gilb  va  Graham  (1993)  har-bir  tashkilot  o‘zining  standart  va 
usullariga  asoslanga  tekshiruvning  nazorat  ro‘yhatini  ishlab  chiqishni  aytishgan. 
Bu  nazorat  ro‘yhatlari  doim  yangilanib  turishi  kerak  chunki  hatoliklarning  yangi 
turlari paydo bo‘ladi. Nazoarat ro‘yhatidagi punkitlar komplatsiya vaqtida mumkin 
bo‘lga  tekshiruvning  har-xil  darachasi  borligi  uchun  dasturlash  tiliga  ko‘ra 
o‘zgaradi. Masalan Java kompilyatori funksiyalarda parametrlash soni to‘g‘riligini 
tekshiradi. C kompilyatori bu ishni bajarmaydi. 
Tekshiruvlarni  amalga  oshirgan  ko‘plab  tashkilotlar  ular  hatolarni  topishda 
samarali  ekanligini  bilishdi.  Fagan(1986)  habar  qilishicha  dasturdagi  60  %  dan 
ko‘p  hatoliklar    norasmiy  tekshiruvlarda  aniqlanishi  mumkin.  Mills  va  boshqalar 

---

99 
 
(1987)  to‘g‘rilik  argumentlariga  asoslangan  tekshiruvga  rasmiy  yondashuv  orqali 
dasturdagi  90%  dan  ko‘proq  hatoliklar  topilishi  mumkin  deb  taxmin  qilishdi. 
MCConnell  (2004)  taqqoslaganda testlashda  25  %  hatoliklar topilgan tekshiruvda 
esa  60%.  U  shuningdek  ko‘p  misollar  keltirgan  bitta  misolida  expert  baxolash 
kiritilganda unumdorlik 14% oshgan va dasturdagi hatoliklar 90% kamygan. 
Tekshiruv yoki expert baxolashlarni samaradorligi haqida ko‘p ijodiy fikirlar 
bildirilganiga  qaramay  dasturiy  ta‘minot  yaratuvchilarining  ko‘pi  ulardan 
foydalanishni hohlamaydi. Dasturlashni sinovdat o‘tkazish tajribasiga ega dasturiy 
ta‘minot yaratuvchilari tekshiruvlar hatoni testlardan ko‘ra yaxshiroq topishini tan 
olgilari kelmaydi. 
Boshqaruvchilar  bunga  shubha  bilan  qaraydilar  chunki  tekshiruvlar 
loyihalash va yaratishy vaqtida qo‘shimcha sarf harajatni talab qiladi. Ular dasturni 
sinovda o‘tkazishni ketadigan sarfdan ko‘payib ketishi mumkin deb qo‘rqishadi.