|
Boboev L. B., Abduraxmanova N. N. Dasturiy loyihalarni boshqarish fanidan
|
| bet | 45/79 | | Sana | 23.12.2023 | | Hajmi | 1,03 Mb. | | #127344 |
Bog'liq Dasturiy loyihalarni boshqarish -типография (2)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 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 (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.
|
| |
