Boboev L. B., Abduraxmanova N. N. Dasturiy loyihalarni boshqarish fanidan
Dasturiy loyihalarni boshqarish -типография (2)
3.8- rasm. Nazorat ro‘yhati Tezkor jarayonlar tekshiruv yoki expert baxolashning resmiy jarayonlaridan kam foydalanishadi. Ular ko‘proq bir-birini kodini tekshiga ishonib qolishadi va har bir dasturchi o‘zini kodini tekshirishga ishonadilar. Favqulotda dasturlash amalyotchilari bunday dasturlashni tekshiruvni samarali o‘rnbosari deb bilishadi chunki haqiqatdan ham bunday tekshiruv jarayoni uzluksiz bajariladi. Iikita odam kodning har bir satrini ko‘rib chiqadi va qabul qilishdan oldin tekshiradi. Juftlikda dasturlashda dastur haqida chuqur bilimga ega bo‘ladi shunki ikkila dasturchi yaratishni davom ettirish uchun bir-birini ishini tushunishi kerak. Boshqa tekshiruv jarayonlarida bunday bilimga erishish qiyin va dasturchilar uftligi rasmiy tekshiruvda aniqlanishi qiyin bo‘lgan hatolarni topishi mumkin. Lekin ikkalasi ham bir hil hatolikka yo‘l qo‘ysa o‘zaro kelishmovchilik chiqishi mumkin. Undan tashqari loyiha rivojlanishi to‘xtashini hohlamasdan juftliklar hato axtarishni rad etishi mumkin. Dasturlashni ichidagi odamlar tashqi tekshiruv chamoasi kabi obyektiv bo‘la olmaydi va ularning hatolarini topish qobilyati sihdagi yaqin munosabatlariga putir yetkazishi mumkin. 3.4. Dasturiy ta‘minot o‘lchamlari va metrikalari Dasturiy ta‘minot o‘lchamlari deganda dasturiy ta‘minot tizimi yoki jarayonning komponentini xususiyati uchun sonli qiymat yoki profilni olish tushiniladi. Bu qiymatlar bir biri bilan va tashkilotda qabul qilingan standartlarga nisbatan taqqoslab, Siz dasturiy ta‘minot sifati xaqida xulosa chiqarishingiz yoki dasturiy ta‘minotning jarayonlari, vositalari va usullarining samaradorligini baxolashingiz mumkin. Masalan, aytaylik, tashkilot dasturiy ta‘minotni tekshiruvchi yangi instrumentni qo‘llamoqchi. Instrumentni qo‘llashdan avval Siz dasturiy ta‘minotda xozirgi vaqtda aniqlangan defektlar miqdorini yozib olasiz. Bu instrumentning samarasini tekshirish uchun asos bo‘ladi. Instrumentni ishlatgandan keyin vaqt o‘tib siz bu jarayonni qaytarasiz. Instrument ishlatilgandan buyon ko‘proq defekt topilgan bo‘lsa, bu dasturiy ta‘minotni ratifikatsiyalash jarayoniga yordam berayotgani xaqida aytishingiz mumkin. Dasturiy ta‘minotni o‘lchashning uzoq muddatli maqsadi shundaki, dasturiy ta‘minot sifati xaqida xulosa chiqarishda sharxlar o‘rniga o‘lchashni qo‘llashdir. Dasturiy ta‘minotni o‘lchash yo‘li bilan tizim baxolanishi ideal bo‘lardi va tizim sifati bo‘yicha metrika va ularning qiymatlari diapazoni kiritilishi mumkin bo‘lardi. Dasturiy ta‘minot yetarli sifat darajasiga ega bo‘lsa, uni sharxsiz ma‘qullash mumkin bo‘ladi. Dasturiy ta‘minot o‘lchamlari birinchi o‘ringa qo‘yilganda bu soxada ancha muvaffaqiyatlarga erishish mumkin bo‘lardi. Lekin biz xozirda bu ideal xolatdan ancha olismiz va sifatni avtomatik baxolash yaqin kelajakda xaqiqatga aylanishining xech qanday belgisi yo‘q. Dasturiy ta‘minot metrikasi – ob’ektiv o‘lchanishi mumkin bo‘lgan dasturiy ta‘minot tizimining, tizim xujjatining yoki rivojlantirish jarayonining xususiyatidir. Metrikalar misollari ichiga maxsulotning kodi satrlar o‘lchamida; yozma matnning o‘qilishining qulayligini o‘lchovchi Tuman indeksi (Obstrel, 1962); dasturiy maxsulotdagi topilayotgan xatoliklar miqdori; odamga tizim komponentini yaratishga kerak bo‘lgan kunlar miqdori. Dasturiy ta‘minot metrikalari nazorat metrikasi yoki bashoratlovchi metrika bo‘lishi mumkin. Nomlar jarayonni boshqarishda yordam bergandek, bashoratlovchi metrikalar dasturiy ta‘minotning xususiyatlarini oldindan aytishga yordam beradi. Nazorat metrikalari odatda dasturiy ta‘minotning jarayonlariga bog‘liq bo‘ladi. Jarayonlar yoki nazorat metrikasini misollari – defektlar xaqida xabar berishga kerak bo‘lgan o‘rtacha vaqt va xarakat. Bashoratlovchi metrikalar bevosita dasturiy ta‘minot bilan bog‘liq bo‘ladi va ba‘zida “maxsulot metrikalari” deb nomlanishadi. Bashoratlovchi metrikalar misollari - cyclomatic modulь murakkabligi (8 bobda muxokama qilingan), dasturdagi identifikatorlarning o‘rtacha uzunligi, va dizaynda ob’ekt sinflari bilan bog‘langan belgi va amallarning miqdori. 3.9- rasm. Bashorat qilish va nazorat qilish o‘lcho‘vlari 3.9- rasmda ko‘rsatilgandek, nazorat va bashoratlovchi metrikalari boshqaruv qarorini qabul qilishga ta‘sir qilishi mumkin. Boshqaruvchilar jarayonga o‘zgartirish kiritish kerakligi xaqida qaror qabul qilishda jarayon o‘lchamlaridan foydalanadi va dasturiy ta‘minotda o‘zgartirish bajarishga ketadigan xarakatni baxolash uchun bashoratlovchi metrikalarni ishlatadi. Bu bobda men asosan bashoratlovchi metrikalarni ko‘rib chiqaman, chunki dasturiy ta‘minot kodini taxlil qilishda ularning o‘rni beqiyosdir. Nazorat metrikalarini va ular jarayonni mukammallashtirishda qanday ishlatilishini 26 bobda ko‘rib chiqamiz. Dasturiy ta‘minot tizimida o‘lchamlar bajarilishining ikkita yo‘li bor: Tizim sifatini qiymatini belgilash – tizim komponentlarini xususiyatlarini o‘lchash va bu o‘lchamlarni qo‘shish, Siz tuzatish mumkinligi kabi xususiyatlarni baxolashingiz mumkin bo‘ladi. Sifati standart bo‘lmagan tizim komponentlarini identifikatsiyalash. O‘lchamlar xususiyatlari me’yordan og‘ib turuvchi aloxida komponentlarni identifikatsiyalash mumkin. Masalan, siz komponentlarni o‘lchashiz mumkin va eng murakkabini topishiz mumkin. Ularda xato bo‘lishi mumkin, chunki murakkabligi uchun ularni tushinish qiyinroq. Afsuski, 3.2- rasmda kursatilgan dasturiy ta‘minotining ko‘p sifat xususiyatlarni to‘g‘ridan to‘g‘ri o‘lchamlarini olish qiyin. Tuzatish mumkinligi, o‘qish osonligi, foydalanishning qulay va osonligi kabi sifat belgilari – yaratuvchi va foydalanuvchilarga tegishli bo‘lgan tashqi belgilardir. Ularda foydalanuvchi tajribasi va ma‘lumoti kabi sub’ektiv omillar ta‘sir etib ular ob’ektiv o‘lchanishining ilojisi yo‘q. Bu belgilar xaqida xulosa chiqarish uchun siz dasturiy ta‘minotning ichki belgilarini (o‘lchami, murakkabligi va x.) o‘lchashingiz va ular sizni xavotirga solayotgan sifat xususiyatlari bilan bog‘likligini ko‘rib chiqishingiz kerak. 3.10- rasmda dasturiy ta‘minotning sifatini ba‘zi tashqi belgilari va ular bilan bog‘liq bo‘lishi mumkin bo‘lgan ichki belgilar ko‘rsatilgan. Diagrammada tashqi va ichki belgilar o‘rtasida munosabatlar bo‘lishi mumkinligi xaqida gapirilgan, lekin bu belgilar qanday bog‘langanligi aytilmagan. 3.10- rasm. Ichki va tashqi tasturiy ta‘minotlar o‘rtasidagi munosabatlar Ichki belgining o‘lchami dasturiy ta‘minotning tashqi xususiyatiga ta‘sir qilishi mumkin bo‘lsa, uchta shart bajarilishi kerak (Kitchenham, 1990): Ichki xususiyat aniq o‘lchanishi kerak. Bu xar doim xam to‘g‘ridan to‘g‘ri bajarilishi mumkin emas va bu o‘lchamni bajarish uchun maxsus vositalar kerak bo‘lishi mumkin. O‘lchanishi mumkin bo‘lgan belgi va qiziqtiraetgan tashqi sifat belgisi o‘rtasida bog‘liqlik bo‘lishi kerak. Shunday qilib, sifat xususiyati qiymati o‘lchanishi mumkin bo‘lgan xususiyatning qiymatiga bog‘liq bo‘lishi kerak. Tashqi va ichki xususiyat o‘rtasidagi bu munosabat tushinilishi, tasdiqlanishi va qaysidur ifoda yoki modelь yordamida ko‘rsatilishi kerak. Namunaviy ifodada modelni funktsionali yig‘ilgan ma‘lumotlarni taxliliga asoslanib, modelga kiritilishi kerak bo‘lgan parametrlarni belgilaydi va mavjud ma‘lumotlar asosida bu parametrlarni kalibrovka qiladi. Komponent murakkabligi kabi dasturiy ta‘minotning ichki xususiyatlari dasturiy ta‘minotning dastlabki kodini taxlil qiluvchi dasturiy vositalar yordamida o‘lchanadi. Bu o‘lchamlarni bajarish uchun mavjud vositalar umumiy foydalanishdadir. Dasturiy ta‘minot komponentining murakkabligi va ishlatishda kuzatilayotgan rad etishlar miqdori o‘rtasida bog‘liqlik borligi sezilsa xam, buni ob’ektiv namoyish etish qiyin. Bu fikrni isbotlash uchun siz ko‘p komponentlar ishdagi xatolari xaqidagi ma‘lumot va dastlabki kodni taxlil qilishga ruxsatga ega bo‘lishingiz kerak. Juda kam tashkilotlar o‘z dasturiy maxsuloti xaqida ma‘lumotlarni uzoq muddat davomida yig‘ishni o‘z bo‘yniga olgan, shuning uchun rad etishlar xaqidagi ma‘lumotlarni taxlil qilishni ilojisi yo‘q. Hewlett Packard (Greydi, 1993), AT&T (Barnard i TSena, 1994), va Nokia (Kilpi, 2001) kabi ba‘zi katta tashkilotlar 1990-chi yillarda dasturlarni metrikalarini kiritishgan. Ular o‘z maxsulot va jarayonlarini o‘lchovlarini o‘tkazishgan va ulardan sifatni boshqarish jarayonlarida foydalanishgan. Dastur metrikalari asosida tekshiruv va ratifikatsiya jarayonlari bajarilgan. Offen va Djeffri (1997) xamda Zal va Fenton (1997) metrikalar dasturini sanoatga kiritishni batafsil muxokama etishgan. Sanoatda dasturiy ta‘minotni tizimli o‘lchash xaqida ozgina axborot bor. Ko‘p tashkilotlar xaqiqatda xam o‘z dasturiy ta‘minoti xaqida ma‘lumot to‘playdi, bunda o‘zgartirish kiritishga oid talablar va testlashda aniqlangan defektlar miqdori ko‘riladi. Lekin ular bu tizimli o‘lchamlarni nima uchun ishlatishlari noma‘lum: dasturiy maxsulot va jarayonlarni taqqoslash uchunmi yoki o‘zgartirishlarni dasturiy ta‘minot va vositalarga ta‘sirini baxolash uchunmi. Buning murakkabligining bir nechta sababi bor: Tashkilotda metrikalar dasturini ishlatilishi qancha mablag‘ni saqlab qolishi noma‘lumligi. Metrikalardan foydalanmasdan dasturiy ta‘minotni mukammallashtirishda oxirgi yillarda katta o‘zgarishlarga erishildi, shuning uchun dasturiy ta‘minotni o‘lchash va baxolashga sarflashning asoslantirish qiyin. Dasturiy ta‘minot metrikalari uchun xech qanday standart xamda o‘lchash va taxlil qilishning standartlashtirilgan jarayonlar yo‘q. Ko‘p tashkilotdar dasturni o‘lchamlarini standart va vositalarigacha olib borishni rad etishmoqda. Ko‘p tashkilotlarda dasturiy ta‘minot jarayonlari standartlashtirilmagan va yaxshi aniqlanmagan, yaxshi boshqarilmaydi. SHuningdek bitta tashkilotning ichida jarayon shunchali o‘zgaruvchanki, o‘lchamlar unda ishlatilishi axamiyatsiz bo‘ladi. Dasturiy ta‘minotni o‘lchash va metrikalari soxasidagi tadqiqotlarning katta qismi asosan kod va rejalashtirishni boshqarish jarayonining metrikalariga e’tibor qaratgan. Lekin xozir ERP yoki GOST tizimlarini shakllantiruvchi, yoki tezkor usullaridan foydalangan dasturiy ta‘minot ko‘proq ishlab chiqilyapti. SHuning uchun biz oldingi tadqiqotlar dasturiy ta‘minotni yaratishning bu usullariga qo‘llanishi mumkinmi bilmaymiz. O‘lchamni taqdim qilinishi yuqoridagi jarayonlarga qo‘shimcha ish bo‘ladi. Bu tezkor usullarning maqsadlariga mos kelmaydi, chunki ular dasturni rivojlanishi bilan bevosita bog‘liq bo‘lmagan jarayonlarni rad etadi. Tezkor usullarni ishlatayotgan tashkilotlar metrikalar dasturini qabul qilishi qiyin. Dasturiy ta‘minotni o‘lchash va metrikalar – empirik dasturlashning asosidar (Endres va Rombach, 2003). Bu tadqiqot soxasida dasturiy ta‘minot tizimlaridagi tajribalar va real loyxalar xaqidagi ma‘lumotlar dasturlash usullari xaqida gipotezalarni shakllantirish va tasdiqlash uchun ishlatiladi. Bu soxada ishlovchi tadqiqotchilar aytishicha, dasturlash usullarining muximligi ular xaqiqatdan xam aytilgan foydani keltirishini isboti bo‘lsagina tasdiqlanadi. Afsus, ob’ektiv o‘lchamlarni bajarish imkoni bo‘lsa xam va natijalarini ko‘rish mumkin bo‘lsa xam, qaror qabul qiluvchi shaxslar ularga ishonmasligi mumkin. Qaror qabul qilinishiga ko‘proq yangiligi yoki amaliyotchilarda usullar qiziqish o‘yg‘onganlik darajasi kabi sub’ektiv omillar ta‘sir qiladi. Shuning uchun, men o‘ylashimcha, empirik dasturlashning dasturlash amaliyotiga ta‘sir etishiga xali ancha yillar bor. Download 1,03 Mb.
|
Bosh sahifa
Aloqalar Bosh sahifa Boboev L. B., Abduraxmanova N. N. Dasturiy loyihalarni boshqarish fanidan
|