• N1 koddagi operatorlarning umumiy soni
Download 0.72 Mb.
|
- Bu sahifa navigatsiya:
- TCF F i
- 171−5.2ln(HV)−0.23CC−16.2ln(LOC)+50sin√2.46∗COM
8.1-jadval Qiyinchilik bo'yicha tasniflangan tashqi o'zaro ta'sirlar to'plamiga misol. Har bir katakda qat'iy og'irliklar oddiy shriftda ko'rsatilgan va bizning xayoliy dasturiy ta'minot tizimimiz uchun taqdim etilgan raqamlar qalin qilib ko'rsatilgan. O'zaro ta'sirlar qiyinchilik bo'yicha tasniflangan va ball berilgandan so'ng, Unadjusted Function Point Count (UFC) ni hisoblash mumkin. Bu o'zaro ta'sirlarning har bir toifasi uchun o'zaro ta'sirlar sonini berilgan qiyinchilikning og'irligiga ko'paytirish va barcha qiymatlarni jamlash, so'ngra barcha yig'ilgan qiyinchiliklarni qo'shish orqali hisoblanadi.
Bu erda xi j - i turdagi va murakkablikdagi o'zaro ta'sirlar soni, va wi j - tortish omili. Mashq: 8.1-jadvaldagi qiymatlar uchun UFC ni hisoblang. UFC hisoblab chiqilgandan so'ng, Texnik murakkablik faktori (TCF) deb ataladigan qo'shimcha ball hisoblanadi. Bu birinchi navbatda 0 dan 5 gacha bo'lgan tartibli shkala bo'yicha 14 ta "texnik omil" reytingi bilan hisoblanadi (bu erda 0 "ta'sir yo'q" va 5 "tanqidiy ta'sir" degan ma'noni anglatadi). Faktorlar 8.7-rasmda keltirilgan. 8.7-rasm Texnik murakkablik omillari Bu bizga TCF ni quyidagicha hisoblash imkonini beradi:
FPC =UFC×TCFFunktsiya nuqtalari uchun juda ko'p potentsial tuzoqlar mavjud. Birinchidan, har xil turdagi o'zaro ta'sirlarga bog'liq bo'lgan og'irliklarni hisoblash kerak va buni qanday qilish kerakligi aniq emas. Bu, ayniqsa, muammoli, chunki og'irliklarni noto'g'ri tanlash (yoki bu borada o'zaro ta'sirlarni tasniflash) noto'g'ri natijalarga olib kelishi mumkin. Ko'rinib turibdiki, funktsiya ballari sonini hisoblash jarayoni zerikarli bo'lishi mumkin va resurslarni baholash kabi maqsadlar uchun keraksiz darajada murakkab deb tanqid qilinadi [51]. 8.2.2 Modullik ko'rsatkichlari Dasturiy ta'minot tizimlari, agar ularning turli funktsiyalari tizimning aniq belgilangan joylariga aniq tarzda joylashtirilgan bo'lsa, tushunish osonroq bo'ladi. Misol uchun, agar matn protsessorini amalga oshirishni ko'rib chiqsak, fayllarni yuklash va saqlash uchun mas'ul bo'lgan kod matnni tahrirlash va formatlash uchun javobgar bo'lgan kod bilan aralashmaganligini tushunish osonroq bo'ladi. Ushbu mezon erkin tarzda "modullik" deb ataladi. Bu masala 60-yillarning oxirida, dasturiy ta'minot sifatining umumiy muammosi birinchi marta diqqat markazida bo'lganida e'tiborga tushdi. O'sha paytda kompyuter dasturlari odatda oqim sxemalari sifatida ko'zda tutilgan; Dastur kompyuterga qachon sodir bo'lishini aytib beradigan ko'rsatmalar ketma-ketligi sifatida yaratilgan. Bu o'sha davrning asosiy tillari - COBOL va FORTRAN tomonidan qo'llab-quvvatlangan. Ular juda ko'p funktsiyalar uchun yuqori darajadagi sintaksisni taklif qiladilar va bu ko'rsatmalarni to'g'ri tartibda joylashtirish asosan dasturchiga bog'liq edi. Murakkab boshqaruv konstruksiyalarini yoqish uchun ular GO TO kabi buyruqlarni taklif qiladilar, bu esa dasturchiga nazorat oqimini dasturning ixtiyoriy nuqtalariga yo'naltirishga imkon beradi, agar ular tsikllar va hokazolarni keltirmoqchi bo'lsa. Ushbu dasturlash rejimi bilan bog'liq muammo shundaki, bu juda labirintli dasturlarga olib kelishi mumkin edi, bu erda boshqaruv oqimini ajratish juda qiyin bo'lib qoldi. Bunday dasturlar odatda "spagetti kodi" deb ataladi (bu erda turli xil boshqaruv oqimlari spagetti plastinkasiga o'xshaydi). Bu tezda juda qiyin (va shuning uchun juda qimmat) va ko'plab yashirin xatolarni o'z ichiga oladigan dasturlarning paydo bo'lishiga olib keldi. Bu masalalar Edsger Deykstraning "Zararli deb hisoblangan bayonotga o'tish" deb nomlangan hozirgi mashhur inshosida keng e'tiborga olingan. Mashq: Deykstra essayini o'qing. Dijkstraning kuzatishlari modulli dasturiy ta'minotni ishlab chiqishni rag'batlantirishga intilayotgan dasturlash tilini loyihalashda bir qancha o'zgarishlarga olib keldi. Bu Devid Parnas kabi arboblar tomonidan yaratilgan "modulizatsiya" yondashuvlariga olib keldi. 1972 yilda dasturiy ta'minotni modullarga ajratish haqidagi inshosida [105] u "ma'lumotni yashirish" tushunchasini ishlab chiqdi - turli modullar (funktsionallikning o'ziga xos jihatlari bilan bog'liq) bir-birining qarorlari va ma'lumotlaridan xabardor bo'lishlari shart emas. Bunday g'oyalar zamonaviy dasturlash tillari va paradigmalarining asosini tashkil etuvchi ko'plab tushunchalarni (ma'lumotni yashirish, interfeyslar, meros va boshqalar) keltirib chiqardi. 8.2.2.1 Ulanish va birlashish "Ulanish" va "Uyg'unlik" - bu modullik tushunchasi kabi uzoq vaqtdan beri mavjud bo'lgan atamalar. Ular ma'lum bir tizimning "modulli" ekanligini muhokama qilish uchun ishlatilishi mumkin bo'lgan atamalardir. Intuitiv ta'riflar quyidagilar: • Bog'lanish ikki modulning bir-biri bilan “bog'liqligi” darajasini tavsiflaydi (quyida muhokamaga qarang). • Uyg'unlik bitta modulga tegishli bo'lib, ma'lumotlar va funksiyalarning o'zaro bog'liqligini tavsiflaydi. Birlashtirilgan modulda o'zgaruvchilar va funktsiyalar ko'pincha bir-biriga kuchli bog'liq bo'ladi. Agar bunday bo'lmasa, modul ichidagi o'zgaruvchilar va funktsiyalarning bir nechta guruhlari ko'pincha sodir bo'ladi. bir-biridan mustaqil bo'lishi (va, ehtimol, alohida modullarga bo'linishi mumkin). Bog'lanishdagi "munosabat" tushunchasi ko'proq muhokama qilishni talab qiladi, chunki u kamdan-kam hollarda aniq ta'riflanadi. Qattiq, kod-tahlil nuqtai nazaridan, agar dastlabki kodda aniq munosabatlar mavjud bo'lsa, ikkita modul bog'lanishi mumkin: bir modul boshqa moduldagi funktsiyani chaqiradi, u boshqa moduldagi o'zgaruvchidan o'qiydi / yozadi yoki (da). ob'ektga yo'naltirilgan kontekst) boshqa moduldan meros oladi. Biroq, bir juft modulni bog'lashning boshqa ko'plab mumkin bo'lgan usullari mavjud. Misol uchun, Bek va Diehl [17] yana bir qancha boshqa yashirin munosabatlarga ishora qiladilar: • Ular tizimdagi boshqa sinflar/kutubxonalar bilan o'xshash munosabatlarga ega bo'lishi mumkin. • Ular ishlab chiqish jarayonida o'xshash vaqtda o'zgartirilgan bo'lishi mumkin (versiyalar omboridagi tahrirlar). • Ular bir-biriga o'xshash yoki bir xil bo'lgan bir nechta kod qismlarini o'z ichiga olishi mumkin. • Ular umumiy mualliflarni baham ko'rishlari mumkin. • Ular matn jihatidan o'xshash bo'lishi mumkin (o'xshash kalit so'zlar, funksiya nomlari va boshqalarni o'z ichiga oladi). Mashq: Bir juft modul o'rtasidagi munosabatni tavsiflashning ko'plab mumkin bo'lgan usullari mavjud. Qanday qilib bu o'lchov nuqtai nazaridan muammoli bo'lishi mumkin? Hozircha biz munosabatlarning eng oddiy, tizimli ta'rifiga amal qilamiz. Birlashma va birlashishning asosiy tushunchalarini tasvirlash uchun biz birinchi navbatda 8.8-rasmdagi rasmni ko'rib chiqamiz. Bu erda biz ikkita modul o'rtasida keng ko'lamli aloqa mavjudligini ko'ramiz; chap moduldagi ko'plab usullar o'ngdagi usullarni chaqiradi va ikkala usul to'plami boshqa moduldagi ma'lumotlar a'zolariga tez-tez kirishadi.
- 8.8-rasm Yuqori ulanish (va past kogeziya) tasviri. Ikki to'rtburchaklar modullarni ifodalaydi (masalan, ob'ektga yo'naltirilgan tizimdagi sinflar). Doiralar ma'lumotlar o'zgaruvchilarini (masalan, sinf atributlari) va kvadratlar funktsiyalarni (masalan, sinf usullari) ifodalaydi. Juftlik funksiyalari orasidagi strelkalar funksiya chaqiruvlarini, funksiyalar va maʼlumotlar atributlari orasidagi oʻqlar esa oʻqish yoki yozishni ifodalaydi. 8.9-rasm Yuqori kogeziya (A modulida) va past kogeziya (B modulida) tasviri. 1994 yilda Chidamber va Kemerer tomonidan ishlab chiqilgan ob'ektga yo'naltirilgan o'lchovlar to'plamidan paydo bo'lgan [29]. Bog'lanish ob'ektlar o'rtasidagi bog'lanish ko'rsatkichi bilan o'lchandi va birlashma quyida tavsiflangan birlashma etishmasligi ko'rsatkichi bilan o'lchandi. 8.2.2.2 Ob'ektlar orasidagi bog'lanish (CBO) Ob'ektlar orasidagi bog'lanish (CBO) tizimdagi har bir sinf uchun u bog'langan boshqa sinflar sonini ifodalovchi qiymatni hisoblab chiqadi. Ko'rib chiqilgan aloqalar standart hisoblanadi: o'zgaruvchidan o'qish / o'zgaruvchiga yozish yoki usulni chaqirish. Agar usul chaqiruvi polimorfik bo'lsa (ma'lum bir qo'ng'iroq orqali chaqirilishi mumkin bo'lgan bir nechta usul mavjud), u holda barcha mumkin bo'lgan qo'ng'iroqlar hisobga olinadi. Mashq: 8.8-rasmda siz ikkita sinfga qarayapsiz deb faraz qiling. A sinfi uchun CBO ni hisoblang. 8.2.2.3 Usullar o'rtasida uyg'unlikning yo'qligi (LCOM) Uyg'unlik (yoki aniqrog'i, uning etishmasligi) odatda LCOM ko'rsatkichi bilan o'lchanadi. Muxtasar qilib aytganda, u umumiy sinf atributlariga kirish imkoniga ega bo'lmagan juft usullar soni minus umumiy sinf atributlariga kirish huquqiga ega bo'lgan a'zo funksiyalar juftligi soni sifatida hisoblanadi. Bu ko'rsatkich yillar davomida o'zgarib, ko'plab tanqidlarga uchragan [15].
8.2-jadval A va B sinflari uchun LCOMni hisoblash asoslari 8.9-rasm 8.2-jadvalda 8.9-rasmdagi misollar uchun LCOM qanday hisoblanganligi ko'rsatilgan. Har bir satr bir juft usulga mos keladi va "O'zgaruvchilar" ustuni ular qancha o'zgaruvchilarni taqsimlashini ko'rsatadi. A klassi uchun barcha uchta juft usullar o'zgaruvchilarni almashadi (bu o'zgaruvchilarni baham ko'rmaydigan usullar jufti emasligini anglatadi), shuning uchun LCOMA = 0−3 =−3, bu nol sifatida qayta yoziladi; boshqacha aytganda, birdamlik yo'q. B klassi uchun yana uchta o'zgaruvchi juftligi mavjud, ammo ularning hech biri o'zgaruvchiga kirish huquqiga ega emas, shuning uchun B sinfi uchun LCOMB = 3−0 = 3. Mashq: 8.1-bo'limda biz o'rgangan turli xil o'lchov turlariga murojaat qilsak, nima uchun LCOM ko'rsatkichi muammoli bo'lishi mumkin? LCOMning asosiy tanqidi (yuqoridagi mashqqa javoban) uning asosli ravishda intervalli shkalada o'lchanganligi, ammo har qanday salbiy qiymatlarni nol sifatida qayta yozish orqali nisbatlar shkalasiga biroz noqulay tarzda majburlanganligidir. Muammo shundaki, bu konvertatsiya to'liq ishlamaydi, chunki nol qiymatga ega bo'lgan narsaning kanonik ta'rifi yo'q; bir-biridan qanday qilib (un) birlashtirilganligi jihatidan keskin farq qiluvchi modullarning barchasi nol LCOM qiymatini ishlab chiqishi mumkin. 8.10-rasm 8.9-rasmdagi A sinfidan farqli kogeziyaga ega, lekin bir xil LCOM qiymatini ishlab chiqaradigan sinf. Misol tariqasida 8.10-rasmdagi S sinfini ko'rishimiz mumkin. Ushbu sinfga nazar tashlaydigan bo'lsak, bir juft usul o'zgaruvchilarga (b va c) kirishni baham ko'rmaydi, ikkitasi esa. Bu shuni anglatadiki, LCOMC = 1−2, u ham nolga qayta yoziladi. Shunday qilib, A va C sinflari turli darajadagi uyg'unlikka ega bo'lsa-da, ular bir xil qiymatga ega. 8.2.3 Ta'minot ko'rsatkichlari va texnik xizmat ko'rsatish indeksi 2-bobda ko'rib turganimizdek, "qo'llab-quvvatlash" ko'pgina asosiy sifat modellarining asosiy komponentini tashkil qiladi. Agar dasturiy ta'minot tizimiga xizmat ko'rsatish imkoni bo'lmasa, uni atrof-muhitdagi o'zgarishlarga va undan kelib chiqadigan talablarning o'zgarishiga osongina moslashtirib bo'lmaydi 8.3 Maqsad savollari ko'rsatkichining haqiqiyligi va foydalanish Bu uzoq muddatda ishlashni tobora qimmatlashtiradi, chunki ishlab chiquvchilar uchun kerakli o'zgarishlarni to'g'ri kiritish qiyinroq.
Mashq: Faraz qilaylik, siz C# loyihasini baholayapsiz. Siz uni Visual Studio-ga yuklaysiz va uning barqarorligi haqida tasavvurga ega bo'lish uchun MI-ni hisoblashga o'tasiz. Olingan ko'rsatkichlarga ishonishda nima uchun ikkilanishingiz mumkin? Uchta sababni yozing. 8.3 Maqsad savollari ko'rsatkichining haqiqiyligi va foydalanish Ushbu bo'limda it dasturiy ta'minoti muhandisligi ko'rsatkichlariga moyil bo'lgan haqiqiylik muammolari ko'rib chiqiladi. Keyin u umumiy texnikani taqdim etadi - Goal Question Metric (GQM), bu ba'zi muammolarni hal qilish uchun ishlatilishi mumkin. 8.3.1 Haqiqiylik muammolari Ko'rib turganimizdek, ko'rsatkichlar vakillik shartiga asoslanadi: o'lchovlar doirasida o'lchanayotgan elementlar (masalan, manba kodlari fayllari) o'rtasidagi munosabatlar saqlanib qoladi. E'tibor bering, bu oddiy ko'rsatkichning (masalan, LOC) haqiqiyligini alohida-alohida baholash mumkin emasligini anglatadi; uning haqiqiyligi u o'lchamoqchi bo'lgan xususiyatga bevosita bog'liq. Bu munosabatlar ma'lum bir kuchli ta'sirga ega. Xususiyatni o'lchash uchun metrikani qo'llash uchun (a) o'lchamoqchi bo'lgan xususiyatning aniq ta'rifiga ega bo'lish va (b) berilgan ko'rsatkich nima uchun ushbu xususiyatni etarli darajada ifodalashini tushuntira olish kerak. Agar ushbu nuqtalardan biri bajarilmasa, metrikaning haqiqiyligini tasdiqlash uchun hech qanday asos yo'q. Bunday holda, metrikaning haqiqatda vakillik shartini bajaradimi yoki yo'qligi haqidagi savol oxir-oqibat omadga tushadi. Ushbu nuqtalardan biri yoki ikkalasini ham shubha ostiga qo'yib bo'lmaydigan o'lchovlarni qo'llash juda kam. Eng ommabop ko'rsatkichlar bo'yicha e'lon qilingan son-sanoqsiz tanqidlar mavjud va ularning aksariyati namoyish qilish sharti buzilgan va metrikaning yaroqsiz holga kelishi holatlariga e'tibor qaratishadi. Dasturiy ta'minotda ko'rsatkichlar, agar ularning maqsadi aniq bo'lsa, amal qiladi. Agar, masalan, filial qamrovi bo'yicha funktsiyani sinab ko'rish qanchalik oson bo'lishini o'lchashga harakat qilinsa, siklomatik murakkablik, ehtimol, oqilona ko'rsatkichdir. Ammo, agar biror kishi rivojlanish harakati yoki ishonchlilik kabi ko'proq mavhum xususiyatlarni o'lchashga intilsa, siklomatik murakkablik haqiqiy o'lchov emas (hech bo'lmaganda umumiy holatda) [120]. Halstead Metrics va MI kabi ko'rsatkichlar bu tanqidlarga ayniqsa zaifdir. Ular unchalik aniq bo'lmagan narsalarni o'lchashni maqsad qiladi ("Sa'y-harakatlar", "Tibbiylik"). Ular ishlatadigan formulalarni ham oqlash qiyin. MI holatida bu muammolar deyarli patologikdir. Ta'minot - bu juda mavhum tushuncha bo'lib, uni aniqlash qiyin bo'lgan juda ko'p turli xil talqinlar mavjud. Buning ustiga, MI formulasini to'liq tushunish mumkin emas, chunki u avtomatik ravishda ishlab chiqarilgan (masalan, nima uchun kvadrat ildizning sinusini sharhlangan kod satrlari sonidan 2,45 marta olish kerak?). MI (va boshqa ko'rsatkichlar) bilan bog'liq muammolar barqarorlik bo'yicha so'nggi tadqiqotlar bilan mustahkamlangan. 2012 yilda Sjoberg va boshqalar. barqarorlik ko'rsatkichlari bo'yicha kichik empirik tadqiqot o'tkazdi [123], undan ba'zi foydali tushunchalarni olishimiz mumkin. Ular to'rtta yirik tizimda MIni o'z ichiga olgan bir qator texnik xizmat ko'rsatish ko'rsatkichlarini taqqosladilar va ularga tegishli bo'lgan haqiqiy texnik xizmat ko'rsatishni hisobga oldilar. Asosiy natijalar quyidagilar edi: • Sozlangan texnik xizmat ko‘rsatish ko‘rsatkichlarining hech biri (masalan, MI) bir-biriga mos kelmadi. • Haqiqiy texnik xizmat ko'rsatish talabiga mos keladigan yagona ko'rsatkichlar LOC va LCOM edi (8.2.2.3-bo'limga qarang). 8.3.2 Maqsad savollari ko'rsatkichi Ko'rsatkichning haqiqiyligini qo'llab-quvvatlash uchun to'liq empirik tadqiqotsiz, metrikaga ishonish mumkinmi yoki yo'qmi, degan qaror odamning sub'ektiv sezgisiga bog'liq. Bilan -
Goal Question Metric framework[129] koʻrsatkichlarni tanlashni tushuntirish uchun foydali asos boʻlib xizmat qiladi. Kontseptsiya juda oddiy. Tizimda ma'lum bir xususiyatni o'lchash muammosi uchta darajada amalga oshiriladi: 1. Kontseptual: Bu o'lchov mashqlarining yuqori darajadagi maqsadlarini qamrab oladi. Tizimning qanday ta'riflab bo'lmaydigan xususiyatlarini o'rnatishimiz kerak?
8.11-rasm Dasturiy ta'minotning modulliligini baholashda qo'llaniladigan GQM misoli. Har bir daraja mos ravishda kontseptual, operatsion va miqdoriy darajalarni ifodalaydi. Bu daraxt shaklidagi tuzilmani hosil qiladi, yuqori darajadagi yuqori darajadagi maqsadlar, ularning har biri savollar to'plami bilan bog'langan va har bir savol bir qator ko'rsatkichlar bilan bog'langan. Misol 8.11-rasmda keltirilgan. E'tibor bering, GQM ko'rsatkichlar avtomatlashtirilgan yoki avtomatlashtirilmaganligi haqida hech qanday taxmin qilmaydi. Bizning ko'rsatkichimiz uchun uning modulliligi faqat ulanish va uyg'unlik bilan baholanmaydi. Ushbu ko'rsatkichlar boshqa sub'ektiv savollarga ko'r emas (masalan, modullar muammoli sohadagi mos ob'ektlarga mos keladimi [65]). Shunday qilib, uchinchi savol uchun, bu dekompozitsiya modullar soni bo'yicha mos keladimi (ya'ni butun tizim uchun faqat bitta katta modul mavjud emas) va modullar domen ichidagi intuitiv ob'ektlarni ifodalaydimi yoki yo'qmi degan domen ekspertining fikrini hisobga oladi. . Shu o‘rinda kitobning oldingi bo‘limlariga nazar tashlashga arziydi. Ba'zi bir o'lchov shakllarini osonlashtirish uchun ierarxiyalar targ'ib qilingan bir necha nuqtalar mavjud. Mashq: ular nima ekanligini eslay olasizmi? Javobni xohlamaguningizcha boshqa o'qimang! 2-bobda biz Barri Boemning Q-modeli bilan uchrashdik [22]. Bu dasturiy ta'minot sifati atributlarini qo'lga kiritish uchun ierarxik vosita edi, lekin daraxtdagi eng past "barglar" o'lchanishi kerakligiga urg'u berdi. Keyinchalik, biz GSN [82] ga duch keldik, bu dastur tizimlari uchun xavfsizlik argumentlarini yanada o'lchanadigan qilish uchun tuzilgan daraxt yozuvi. Ikkala holatda ham (GQMda bo'lgani kabi) murakkab vazifa, ehtimol, bo'lish va zabt etish, murakkab tushunchalarni soddaroq, o'lchanadiganlarga bo'lish orqali amalga oshiriladi. 8.4 Asosiy fikrlar • Ko'rsatkichlar dasturiy ta'minot sifatini ta'minlashga qaratilgan har qanday sa'y-harakatlar uchun asosiy vositadir. DeMarkoning iqtibosida aytilganidek - siz o'lchay olmaydigan narsani nazorat qila olmaysiz va sifat kafolati oxir-oqibatda dasturiy ta'minot sifatini maksimal darajada oshirish uchun nima qilishingiz mumkinligini nazorat qilishdir. Bundan tashqari, ko'rsatkichlar sifatni ta'minlash muvaffaqiyatsizlikka uchragan tizimlarga ham qattiq yorug'lik berishi mumkin, buni Toyota ko'zda tutilmagan tezlashtirish holatlarida ko'rsatkichlardan foydalanish guvohlik beradi.
Theoretical questions: 1. What is the focus of the Halstead complexity metric suite in contrast to LOC and Cyclomatic Complexity? 2. How are the Halstead metrics based on the categorization of source code text? 3. Why are the Halstead metrics widely implemented despite being rarely used as stand-alone metrics? 4. What is the concept of "modularity" in relation to software systems, and why is it beneficial? 5. How were computer programs traditionally structured in the late 60s, and what issues did this approach lead to? 6. What was the main concern highlighted by Edsger Dijkstra in his essay "Go To Statement Considered Harmful"? 7. What is the representation condition in relation to metrics, and why is it important for the validity of a metric? 8. What are the implications of the representation condition for using metrics to measure properties? 9. How does the specificity of the purpose affect the validity of metrics in software development? 10. Why are metrics such as Halstead Metrics and the Maintainability Index (MI) particularly susceptible to criticisms regarding their validity and justification? Tests 1. Which of the following components is measured by Halstead Complexity Metrics? a) Number of lines of code b) Number of comments in the code c) Names of variables and operators d) Time taken to execute the code 2. Which metric is calculated by Halstead Complexity Metrics to estimate the size and complexity of the program? a) Program length b) Program difficulty c) Program volume d) Program effort 3. Halstead Complexity Metrics focus on: a) Control flow structures b) Logical conditions in the code c) Textual content of the source code d) Execution time of the code 4. True or False: Halstead Complexity Metrics are primarily used to measure the maintainability of the code. a) True b) False 5. Which of the following is a commonly used metric for measuring modularity in software systems? a) Lines of code (LOC) b) Cyclomatic Complexity c) Halstead Complexity Metrics d) Cohesion and Coupling metrics 6. What does modularity in software systems refer to? a) The physical size of the software code b) The number of external libraries used in the software c) The organization and separation of different functionalities in the code d) The level of code reusability within the software system 7. Which of the following statements is true about modularity metrics? a) Modularity metrics only focus on the functional aspects of the software. b) Modularity metrics primarily measure the execution time of the software. c) Modularity metrics assess the level of code duplication in the software. d) Modularity metrics provide insights into the structure and organization of the software. 8. What is the purpose of Maintainability Metrics in software development? a) To measure the performance of a software system b) To estimate the lines of code in a program c) To assess the ease of maintaining and evolving software d) To measure the complexity of software algorithms 9. Which of the following factors is typically considered when calculating the Maintainability Index? a) Lines of code and number of comments b) Cyclomatic Complexity and Halstead Metrics c) Number of bugs found during testing d) User satisfaction ratings for the software 10. Which of the following statements is true about Maintainability Metrics? a) Maintainability Metrics focus only on code readability and formatting. b) Maintainability Metrics provide insights into the ease of modifying and maintaining software. c) Maintainability Metrics are primarily used for measuring the execution time of the software. d) Maintainability Metrics are independent of the software's functionality. 11. What is the representation condition in relation to software metrics? a) The requirement to accurately represent the properties being measured by the metric. b) The condition where metrics should be represented visually through charts and graphs. c) The condition where metrics should be universally applicable to all software projects. d) The requirement to represent the code base using a specific programming language. 12. When using metrics to measure a property, what is necessary to ensure the validity of the metric? a) The metric should be based on subjective interpretations of the property. b) The metric should be widely used and accepted by industry professionals. c) There should be an unambiguous definition of the property and an explanation of how the metric adequately represents it. d) The metric should be able to measure multiple properties simultaneously. 13. What are the limitations of metrics like Halstead Metrics and the Maintainability Index? a) They rely solely on the lines of code in the software. b) They provide subjective interpretations of software quality. c) They measure properties that are difficult to define and justify. d) They can only be used for small-scale software projects. 14. What is the primary purpose of Function Points in software development? a) To estimate the lines of code in a program b) To measure the complexity of software algorithms c) To estimate the effort required to develop software d) To measure the performance of a software system 15. Which of the following factors is NOT considered when calculating Function Points? a) Number of lines of code b) Complexity of the user interface c) Number of input and output components d) Complexity of data structures used Download 0.72 Mb. Do'stlaringiz bilan baham: 
| ||||||||||||||||||||||||||||||||||||