2356

EN + हिं Easy

GB What is 'technical obsolescence' and what three strategic responses are available to organisations facing it?

IN 'तकनीकी अप्रचलन' क्या है और इसका सामना करने वाले संगठनों के लिए कौन सी तीन रणनीतिक प्रतिक्रियाएँ उपलब्ध हैं?

A

Technical obsolescence is when a software system is no longer needed by its users तकनीकी अप्रचलन तब होता है जब किसी सॉफ़्टवेयर सिस्टम की उसके उपयोगकर्ताओं को आवश्यकता नहीं रह जाती है

B

Technical obsolescence occurs when a system's technology stack (OS, language, framework) reaches EOL with no vendor support — responses: 1) wrapping (add API layer, extend lifespan), 2) migration (port to modern platform), 3) replacement (rewrite or buy replacement system) तकनीकी अप्रचलन तब होता है जब किसी सिस्टम का प्रौद्योगिकी स्टैक (ओएस, भाषा, ढांचा) बिना किसी विक्रेता समर्थन के ईओएल तक पहुंच जाता है - प्रतिक्रियाएं: 1) रैपिंग (एपीआई परत जोड़ें, जीवनकाल बढ़ाएं), 2) माइग्रेशन (आधुनिक प्लेटफॉर्म पर पोर्ट), 3) प्रतिस्थापन (प्रतिस्थापन सिस्टम को फिर से लिखें या खरीदें)

C

Technical obsolescence always requires immediate system replacement — no other response is viable तकनीकी अप्रचलन के लिए हमेशा तत्काल सिस्टम प्रतिस्थापन की आवश्यकता होती है - कोई अन्य प्रतिक्रिया व्यवहार्य नहीं है

D

Technical obsolescence is solved automatically by containerisation technologies like Docker तकनीकी अप्रचलन को डॉकर जैसी कंटेनरीकरण प्रौद्योगिकियों द्वारा स्वचालित रूप से हल किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Wrapping: expose a REST API over a legacy COBOL system — the internals stay unchanged but modern consumers can integrate. Migration: port .NET Framework 4.5 to .NET 6 — same language, major platform modernisation. Replacement: the mainframe is strategically replaced with a cloud-native system over 5 years using strangler fig. Each has different cost, risk, and timeline profiles — the choice depends on business value of the system, available skills, and risk tolerance.

व्याख्या (हिन्दी) रैपिंग: एक पुराने COBOL सिस्टम पर REST API को उजागर करें - आंतरिक अपरिवर्तित रहते हैं लेकिन आधुनिक उपभोक्ता एकीकृत कर सकते हैं। माइग्रेशन: पोर्ट .NET फ्रेमवर्क 4.5 से .NET 6 - समान भाषा, प्रमुख प्लेटफ़ॉर्म आधुनिकीकरण। प्रतिस्थापन: स्ट्रैंगलर अंजीर का उपयोग करके 5 वर्षों में मेनफ्रेम को रणनीतिक रूप से क्लाउड-नेटिव सिस्टम से बदल दिया गया है। प्रत्येक की अलग-अलग लागत, जोखिम और समयरेखा प्रोफ़ाइल होती है - चुनाव सिस्टम के व्यावसायिक मूल्य, उपलब्ध कौशल और जोखिम सहनशीलता पर निर्भर करता है।

2357

EN + हिं Medium

GB What is 'software composition analysis' (SCA) and why is it a critical maintenance practice for modern applications?

IN 'सॉफ़्टवेयर संरचना विश्लेषण' (एससीए) क्या है और यह आधुनिक अनुप्रयोगों के लिए एक महत्वपूर्ण रखरखाव अभ्यास क्यों है?

A

SCA analyses whether the software meets its functional requirements after each deployment एससीए विश्लेषण करता है कि सॉफ्टवेयर प्रत्येक तैनाती के बाद अपनी कार्यात्मक आवश्यकताओं को पूरा करता है या नहीं

B

SCA inventories all third-party open-source dependencies and checks them against vulnerability databases (CVE/NVD) — critical because modern applications are 80%+ open-source code, meaning unpatched dependencies are the primary attack vector (Log4Shell, Spring4Shell) एससीए सभी तृतीय-पक्ष ओपन-सोर्स निर्भरताओं की सूची बनाता है और उन्हें भेद्यता डेटाबेस (सीवीई/एनवीडी) के विरुद्ध जांचता है - महत्वपूर्ण है क्योंकि आधुनिक एप्लिकेशन 80%+ ओपन-सोर्स कोड हैं, जिसका अर्थ है कि अप्रकाशित निर्भरताएं प्राथमिक आक्रमण वेक्टर हैं (लॉग4शेल, स्प्रिंग4शेल)

C

SCA is only required for applications that directly handle financial transactions एससीए केवल उन अनुप्रयोगों के लिए आवश्यक है जो सीधे वित्तीय लेनदेन को संभालते हैं

D

SCA is fully replaced by unit testing and code coverage analysis in modern DevSecOps pipelines आधुनिक DevSecOps पाइपलाइनों में SCA को पूरी तरह से यूनिट परीक्षण और कोड कवरेज विश्लेषण द्वारा प्रतिस्थापित किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Log4Shell (Dec 2021, CVSS 10.0) affected virtually every Java application using Log4j 2.x. Organisations without SCA had no inventory of where Log4j was used — they couldn't even identify which systems were vulnerable. SCA tools (Snyk, OWASP Dependency-Check, GitHub Dependabot) automate this: scan manifests and binaries, cross-reference CVE databases, block builds with critical vulnerabilities, and generate alerts when new CVEs are published for used libraries.

व्याख्या (हिन्दी) Log4Shell (दिसंबर 2021, CVSS 10.0) ने Log4j 2.x का उपयोग करने वाले लगभग हर जावा एप्लिकेशन को प्रभावित किया। SCA के बिना संगठनों के पास इस बात की कोई सूची नहीं थी कि Log4j का उपयोग कहाँ किया गया था - वे यह भी नहीं पहचान सके कि कौन से सिस्टम असुरक्षित थे। एससीए उपकरण (स्निक, ओडब्ल्यूएएसपी डिपेंडेंसी-चेक, गिटहब डिपेंडेबोट) इसे स्वचालित करते हैं: मैनिफ़ेस्ट और बायनेरिज़ को स्कैन करें, क्रॉस-रेफरेंस सीवीई डेटाबेस, महत्वपूर्ण कमजोरियों के साथ ब्लॉक ब्लॉक करें, और प्रयुक्त पुस्तकालयों के लिए नए सीवीई प्रकाशित होने पर अलर्ट उत्पन्न करें।

2358

EN + हिं Medium

GB What is 'maintenance release planning' and how does it balance corrective, adaptive, and perfective work?

IN 'रखरखाव रिलीज योजना' क्या है और यह सुधारात्मक, अनुकूली और पूर्ण कार्य को कैसे संतुलित करती है?

A

Maintenance release planning always prioritises corrective work over all other maintenance types रखरखाव रिलीज़ योजना हमेशा अन्य सभी प्रकार के रखरखाव की तुलना में सुधारात्मक कार्य को प्राथमिकता देती है

B

Maintenance release planning allocates capacity across maintenance types based on business priorities: critical defects addressed immediately; adaptive work driven by external deadlines (OS upgrades, regulation changes); perfective work in regular releases; the allocation ratio reflects risk tolerance and strategic investment decisions रखरखाव रिलीज योजना व्यावसायिक प्राथमिकताओं के आधार पर रखरखाव के प्रकारों में क्षमता आवंटित करती है: महत्वपूर्ण दोषों को तुरंत संबोधित किया जाता है; बाहरी समय सीमा (ओएस अपग्रेड, विनियमन परिवर्तन) द्वारा संचालित अनुकूली कार्य; नियमित रिलीज़ में उत्तम कार्य; आवंटन अनुपात जोखिम सहनशीलता और रणनीतिक निवेश निर्णयों को दर्शाता है

C

Maintenance release planning eliminates the need for a product backlog by using a maintenance-specific process रखरखाव रिलीज़ योजना रखरखाव-विशिष्ट प्रक्रिया का उपयोग करके उत्पाद बैकलॉग की आवश्यकता को समाप्त कर देती है

D

All maintenance types must be planned in equal proportions to maintain system health सिस्टम के स्वास्थ्य को बनाए रखने के लिए सभी प्रकार के रखरखाव की समान अनुपात में योजना बनाई जानी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A typical enterprise allocation: ~20% emergency corrective (P1/P2 bugs addressed within SLA), ~25% adaptive (compliance, infrastructure updates, third-party API changes), ~55% perfective (new features, performance improvements, UX refinements). This shifts when: a security vulnerability demands immediate corrective focus; a major OS EOL drives adaptive work; or strategic product initiatives demand more perfective capacity.

व्याख्या (हिन्दी) एक विशिष्ट उद्यम आवंटन: ~20% आपातकालीन सुधारात्मक (एसएलए के भीतर पी1/पी2 बग का समाधान), ~25% अनुकूली (अनुपालन, बुनियादी ढाँचा अपडेट, तृतीय-पक्ष एपीआई परिवर्तन), ~55% पूर्ण (नई सुविधाएँ, प्रदर्शन सुधार, यूएक्स परिशोधन)। यह तब बदलता है जब: सुरक्षा भेद्यता तत्काल सुधारात्मक फोकस की मांग करती है; एक प्रमुख OS EOL अनुकूली कार्य को संचालित करता है; या रणनीतिक उत्पाद पहल के लिए अधिक उत्तम क्षमता की आवश्यकता होती है।

2359

EN + हिं Easy

GB What is 'architecture erosion' and what governance mechanism can slow or reverse it?

IN 'वास्तुकला क्षरण' क्या है और कौन सा शासन तंत्र इसे धीमा या उलट सकता है?

A

Architecture erosion occurs when the system runs out of available disk space on production servers आर्किटेक्चर क्षरण तब होता है जब सिस्टम उत्पादन सर्वर पर उपलब्ध डिस्क स्थान से बाहर हो जाता है

B

Architecture erosion occurs when implemented code progressively diverges from intended architecture due to expedient fixes and shortcut implementations — slowed by Architecture Decision Records (ADRs), automated architectural fitness functions, and regular architecture review sessions आर्किटेक्चर क्षरण तब होता है जब कार्यान्वित कोड समीचीन सुधारों और शॉर्टकट कार्यान्वयन के कारण इच्छित आर्किटेक्चर से क्रमिक रूप से अलग हो जाता है - आर्किटेक्चर डिसीजन रिकॉर्ड्स (एडीआर), स्वचालित आर्किटेक्चरल फिटनेस फ़ंक्शंस और नियमित आर्किटेक्चर समीक्षा सत्रों द्वारा धीमा हो जाता है।

C

Architecture erosion is natural and unavoidable; no governance mechanism can address it वास्तुकला का क्षरण प्राकृतिक और अपरिहार्य है; कोई भी शासन तंत्र इसका समाधान नहीं कर सकता

D

Architecture erosion only occurs in monolithic architectures; microservices are immune to it वास्तुकला का क्षरण केवल अखंड वास्तुकला में होता है; माइक्रोसर्विसेज इससे प्रतिरक्षित हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Neal Ford's 'evolutionary architecture' concept addresses this: architectural fitness functions (automated tests checking architectural properties — no package dependency cycles, no cross-layer calls, response time thresholds) run in CI and fail builds that violate architecture. ADRs document why decisions were made — preventing 'shortcut' fixes that reintroduce patterns previously decided against. Regular architecture katas keep the team aligned.

व्याख्या (हिन्दी) नील फोर्ड की 'विकासवादी आर्किटेक्चर' अवधारणा इसे संबोधित करती है: आर्किटेक्चरल फिटनेस फ़ंक्शंस (वास्तुशिल्प गुणों की जांच करने वाले स्वचालित परीक्षण - कोई पैकेज निर्भरता चक्र, कोई क्रॉस-लेयर कॉल, प्रतिक्रिया समय सीमा नहीं) सीआई में चलते हैं और आर्किटेक्चर का उल्लंघन करने वाले विफल बिल्ड होते हैं। एडीआर दस्तावेज करते हैं कि निर्णय क्यों लिए गए - 'शॉर्टकट' सुधारों को रोकना जो पहले से तय किए गए पैटर्न को फिर से प्रस्तुत करते हैं। नियमित वास्तुकला काटा टीम को एकजुट रखता है।

2360

EN + हिं Easy

GB What is 'knowledge management' in software maintenance and what creates 'knowledge debt'?

IN सॉफ़्टवेयर रखरखाव में 'ज्ञान प्रबंधन' क्या है और क्या 'ज्ञान ऋण' बनाता है?

A

Knowledge management refers to tracking which developers have read the software documentation ज्ञान प्रबंधन से तात्पर्य यह ट्रैक करना है कि किन डेवलपर्स ने सॉफ़्टवेयर दस्तावेज़ीकरण पढ़ा है

B

Knowledge management in maintenance preserves and distributes understanding of the system — 'knowledge debt' accumulates when: key developers leave without knowledge transfer, documentation is not updated with changes, and tribal knowledge is never externalised into wikis or decision records रखरखाव में ज्ञान प्रबंधन सिस्टम की समझ को संरक्षित और वितरित करता है - 'ज्ञान ऋण' तब जमा होता है जब: प्रमुख डेवलपर्स ज्ञान हस्तांतरण के बिना चले जाते हैं, दस्तावेज़ीकरण परिवर्तनों के साथ अद्यतन नहीं किया जाता है, और जनजातीय ज्ञान को कभी भी विकी या निर्णय रिकॉर्ड में बाह्यीकृत नहीं किया जाता है

C

Knowledge debt is automatically resolved by modern IDEs that extract documentation from code ज्ञान ऋण का समाधान आधुनिक आईडीई द्वारा स्वचालित रूप से किया जाता है जो कोड से दस्तावेज़ निकालते हैं

D

Knowledge management is only important for projects with more than 50 developers ज्ञान प्रबंधन केवल 50 से अधिक डेवलपर्स वाली परियोजनाओं के लिए महत्वपूर्ण है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The bus factor problem: if a key developer leaves, how much institutional knowledge leaves with them? Knowledge debt is the gap between documented and undocumented understanding. Mitigations: pair programming distributes knowledge; Architecture Decision Records document why; code archaeology (comments like 'see bug #1234 for why this exists') preserves context; cross-training ensures no single person holds critical knowledge.

व्याख्या (हिन्दी) बस कारक समस्या: यदि कोई प्रमुख डेवलपर छोड़ देता है, तो उसके पास कितना संस्थागत ज्ञान बचेगा? ज्ञान ऋण प्रलेखित और अप्रलेखित समझ के बीच का अंतर है। शमन: जोड़ी प्रोग्रामिंग ज्ञान वितरित करती है; वास्तुकला निर्णय रिकॉर्ड दस्तावेज़ क्यों; कोड पुरातत्व ('यह क्यों मौजूद है इसके लिए बग #1234 देखें' जैसी टिप्पणियाँ) संदर्भ को सुरक्षित रखता है; क्रॉस-ट्रेनिंग यह सुनिश्चित करती है कि किसी एक व्यक्ति के पास महत्वपूर्ण ज्ञान न हो।

2361

EN + हिं Easy

GB What is 'software retirement' and what criteria should trigger a formal retirement decision?

IN 'सॉफ़्टवेयर सेवानिवृत्ति' क्या है और औपचारिक सेवानिवृत्ति निर्णय के लिए किन मानदंडों को गति देनी चाहिए?

A

Software retirement is triggered automatically when support contract expires समर्थन अनुबंध समाप्त होने पर सॉफ़्टवेयर सेवानिवृत्ति स्वचालित रूप से चालू हो जाती है

B

Software retirement decommissions a system and migrates its functions — criteria: maintenance cost exceeds business value delivered, replacement system has achieved equivalent functionality, user migration is complete, and data archival/legal retention requirements are satisfied सॉफ़्टवेयर रिटायरमेंट एक सिस्टम को निष्क्रिय कर देता है और उसके कार्यों को माइग्रेट कर देता है - मानदंड: रखरखाव लागत वितरित व्यावसायिक मूल्य से अधिक है, प्रतिस्थापन प्रणाली ने समतुल्य कार्यक्षमता हासिल कर ली है, उपयोगकर्ता माइग्रेशन पूरा हो गया है, और डेटा अभिलेखीय/कानूनी प्रतिधारण आवश्यकताएं पूरी हो गई हैं

C

Software retirement requires unanimous agreement from all stakeholders before proceeding सॉफ़्टवेयर सेवानिवृत्ति के लिए आगे बढ़ने से पहले सभी हितधारकों से सर्वसम्मत सहमति की आवश्यकता होती है

D

A system should be retired as soon as a newer technology becomes available in the market जैसे ही कोई नई तकनीक बाजार में उपलब्ध हो जाए, सिस्टम को बंद कर देना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Retirement decisions weigh: total cost of ownership (is it cheaper to maintain than replace/retire?), risk profile (is the system a security liability?), user adoption of replacement (have all users migrated?), legal requirements (some data must be retained for 7-10 years even after retirement). Premature retirement leaves users without functionality; delayed retirement wastes maintenance budget on zero-value systems.

व्याख्या (हिन्दी) सेवानिवृत्ति के निर्णयों का वजन होता है: स्वामित्व की कुल लागत (क्या इसे प्रतिस्थापित/सेवानिवृत्त करने की तुलना में बनाए रखना सस्ता है?), जोखिम प्रोफ़ाइल (क्या सिस्टम एक सुरक्षा दायित्व है?), उपयोगकर्ता द्वारा प्रतिस्थापन को अपनाना (क्या सभी उपयोगकर्ता स्थानांतरित हो गए हैं?), कानूनी आवश्यकताएं (कुछ डेटा को सेवानिवृत्ति के बाद भी 7-10 वर्षों तक बनाए रखा जाना चाहिए)। समयपूर्व सेवानिवृत्ति उपयोगकर्ताओं को कार्यक्षमता से वंचित कर देती है; विलंबित सेवानिवृत्ति शून्य-मूल्य प्रणालियों पर रखरखाव बजट बर्बाद करती है।

2362

EN + हिं Easy

GB What is 'legacy modernisation' and what distinguishes 'rehosting', 'replatforming', and 'refactoring' strategies?

IN 'विरासत आधुनिकीकरण' क्या है और 'रीहोस्टिंग', 'रीप्लेटफॉर्मिंग' और 'रीफैक्टरिंग' रणनीतियों में क्या अंतर है?

A

All three strategies require complete rewriting of the system in a modern programming language सभी तीन रणनीतियों के लिए आधुनिक प्रोग्रामिंग भाषा में सिस्टम के पूर्ण पुनर्लेखन की आवश्यकता होती है

B

Rehosting ('lift and shift') moves to new infrastructure without code changes; replatforming makes minimal code changes to leverage cloud capabilities; refactoring restructures code for maintainability while preserving functionality — cost/risk increases in that order, as does modernisation value रीहोस्टिंग ('लिफ्ट और शिफ्ट') कोड परिवर्तन के बिना नए बुनियादी ढांचे में ले जाती है; क्लाउड क्षमताओं का लाभ उठाने के लिए रीप्लेटफ़ॉर्मिंग न्यूनतम कोड परिवर्तन करता है; कार्यक्षमता को संरक्षित करते हुए रखरखाव के लिए रीफैक्टरिंग कोड को पुनर्गठित करता है - उसी क्रम में लागत/जोखिम बढ़ता है, जैसा कि आधुनिकीकरण मूल्य में होता है

C

Rehosting is always preferred because it is cheapest and provides maximum modernisation value रीहोस्टिंग को हमेशा प्राथमिकता दी जाती है क्योंकि यह सबसे सस्ता है और अधिकतम आधुनिकीकरण मूल्य प्रदान करता है

D

All legacy modernisation strategies require a complete system shutdown during the migration period सभी विरासती आधुनिकीकरण रणनीतियों के लिए प्रवासन अवधि के दौरान पूर्ण सिस्टम शटडाउन की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Gartner's 5Rs (now 7Rs) of cloud migration: Rehost — VM to cloud VM, no code changes, quick but misses cloud-native benefits; Replatform — use managed services (RDS instead of self-managed DB), minor code changes; Refactor — redesign for cloud-native (containerise, add auto-scaling). Each represents increasing investment and increasing long-term benefit. Most organisations start with rehosting for speed, then replatform/refactor as the business case justifies.

व्याख्या (हिन्दी) क्लाउड माइग्रेशन के लिए गार्टनर के 5Rs (अब 7Rs): रीहोस्ट - VM से क्लाउड VM, कोई कोड परिवर्तन नहीं, त्वरित लेकिन क्लाउड-नेटिव लाभ नहीं; रिप्लेटफ़ॉर्म - प्रबंधित सेवाओं का उपयोग करें (स्व-प्रबंधित डीबी के बजाय आरडीएस), मामूली कोड परिवर्तन; रिफैक्टर - क्लाउड-नेटिव के लिए रीडिज़ाइन (कंटेनराइज़, ऑटो-स्केलिंग जोड़ें)। प्रत्येक बढ़ते निवेश और बढ़ते दीर्घकालिक लाभ का प्रतिनिधित्व करता है। अधिकांश संगठन गति के लिए रीहोस्टिंग से शुरुआत करते हैं, फिर व्यावसायिक मामले के अनुसार रीप्लेटफ़ॉर्म/रिफ़ेक्टर करते हैं।

2363

EN + हिं Easy

GB What is 'mean time to repair' (MTTR) versus 'mean time between failures' (MTBF) and which metric matters most for high-availability systems?

IN 'मरम्मत का औसत समय' (MTTR) बनाम 'विफलताओं के बीच का औसत समय' (MTBF) क्या है और उच्च-उपलब्धता प्रणालियों के लिए कौन सा मीट्रिक सबसे अधिक मायने रखता है?

A

MTBF measures repair speed; MTTR measures failure frequency — both are equally important एमटीबीएफ मरम्मत की गति को मापता है; एमटीटीआर विफलता की आवृत्ति को मापता है - दोनों समान रूप से महत्वपूर्ण हैं

B

MTBF is the average time between failures (reliability measure); MTTR is the average time to restore service after failure (recovery measure) — for high-availability systems, minimising MTTR often provides more availability improvement than reducing MTBF, as modern systems accept failures as inevitable एमटीबीएफ विफलताओं (विश्वसनीयता माप) के बीच का औसत समय है; एमटीटीआर विफलता (पुनर्प्राप्ति उपाय) के बाद सेवा को बहाल करने का औसत समय है - उच्च उपलब्धता प्रणालियों के लिए, एमटीटीआर को कम करने से अक्सर एमटीबीएफ को कम करने की तुलना में अधिक उपलब्धता में सुधार होता है, क्योंकि आधुनिक सिस्टम विफलताओं को अपरिहार्य मानते हैं

C

MTBF is the only metric that matters; systems with long MTBF always have high availability एमटीबीएफ एकमात्र मीट्रिक है जो मायने रखती है; लंबे एमटीबीएफ वाले सिस्टम में हमेशा उच्च उपलब्धता होती है

D

MTTR only applies to hardware components; software systems use different metrics एमटीटीआर केवल हार्डवेयर घटकों पर लागू होता है; सॉफ़्टवेयर सिस्टम विभिन्न मेट्रिक्स का उपयोग करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Availability = MTBF / (MTBF + MTTR). Netflix's chaos engineering philosophy: accept that failures will happen (don't rely solely on MTBF); invest in fast recovery (MTTR). A system that fails every 24 hours but recovers in 1 second has 99.999% availability. A system that fails every 1000 hours but takes 10 minutes to recover has 99.98% availability. Modern DevOps focuses on MTTR: automated rollbacks, circuit breakers, health checks, and zero-downtime deployments.

व्याख्या (हिन्दी) उपलब्धता = एमटीबीएफ / (एमटीबीएफ + एमटीटीआर)। नेटफ्लिक्स की अराजकता इंजीनियरिंग दर्शन: स्वीकार करें कि विफलताएं होंगी (केवल एमटीबीएफ पर भरोसा न करें); तेजी से रिकवरी (एमटीटीआर) में निवेश करें। एक प्रणाली जो हर 24 घंटे में विफल हो जाती है लेकिन 1 सेकंड में ठीक हो जाती है उसकी 99.999% उपलब्धता होती है। एक सिस्टम जो हर 1000 घंटे में विफल हो जाता है लेकिन ठीक होने में 10 मिनट लेता है उसकी 99.98% उपलब्धता होती है। आधुनिक डेवऑप्स एमटीटीआर पर केंद्रित है: स्वचालित रोलबैक, सर्किट ब्रेकर, स्वास्थ्य जांच और शून्य-डाउनटाइम तैनाती।

2364

EN + हिं Medium

GB What is 'software re-engineering' and how does it differ from plain refactoring?

IN 'सॉफ़्टवेयर री-इंजीनियरिंग' क्या है और यह सादे रीफैक्टरिंग से किस प्रकार भिन्न है?

A

Software re-engineering is identical to refactoring; the terms are used interchangeably सॉफ़्टवेयर री-इंजीनियरिंग रीफैक्टरिंग के समान है; शब्दों का प्रयोग परस्पर उपयोग किया जाता है

B

Re-engineering examines and alters an existing system to reconstruct it in a new form at a higher level of abstraction — it includes reverse engineering (understanding existing system), restructuring, and forward engineering, often transforming the system's architecture, not just code quality री-इंजीनियरिंग एक मौजूदा सिस्टम की जांच करती है और उसे अमूर्तता के उच्च स्तर पर एक नए रूप में पुनर्निर्माण करने के लिए बदल देती है - इसमें रिवर्स इंजीनियरिंग (मौजूदा सिस्टम को समझना), पुनर्गठन और फॉरवर्ड इंजीनियरिंग शामिल है, जो अक्सर सिस्टम की वास्तुकला को बदल देती है, न कि केवल कोड गुणवत्ता को।

C

Re-engineering requires complete system shutdown and data migration before work can begin री-इंजीनियरिंग के लिए काम शुरू होने से पहले पूर्ण सिस्टम शटडाउन और डेटा माइग्रेशन की आवश्यकता होती है

D

Re-engineering only applies when moving from one programming language to another री-इंजीनियरिंग केवल एक प्रोग्रामिंग भाषा से दूसरी प्रोग्रामिंग भाषा में जाने पर लागू होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Refactoring improves code quality without changing behaviour or architecture (Fowler's definition). Re-engineering is broader (Chikofsky and Cross): it may change the architecture, platform, or paradigm while preserving functionality. Re-engineering a procedural COBOL system into a microservices architecture involves reverse engineering its business logic, restructuring into services, and forward engineering modern code — far beyond refactoring.

व्याख्या (हिन्दी) रीफैक्टरिंग व्यवहार या वास्तुकला को बदले बिना कोड गुणवत्ता में सुधार करती है (फाउलर की परिभाषा)। री-इंजीनियरिंग व्यापक है (चिकोफ़्स्की और क्रॉस): यह कार्यक्षमता को संरक्षित करते हुए वास्तुकला, मंच या प्रतिमान को बदल सकती है। एक प्रक्रियात्मक COBOL प्रणाली को माइक्रोसर्विसेज आर्किटेक्चर में पुन: इंजीनियरिंग करने में इसके व्यावसायिक तर्क को रिवर्स इंजीनियरिंग, सेवाओं में पुनर्गठन और आधुनिक कोड को आगे बढ़ाने वाली इंजीनियरिंग शामिल है - रिफैक्टरिंग से कहीं आगे।

2365

EN + हिं Easy

GB What is the 'broken windows theory' applied to software maintenance and what evidence supports it?

IN सॉफ़्टवेयर रखरखाव पर लागू 'टूटी हुई विंडोज़ सिद्धांत' क्या है और कौन से साक्ष्य इसका समर्थन करते हैं?

A

Broken windows theory in software means literal UI bugs that appear broken to users should be fixed first सॉफ़्टवेयर में टूटे हुए विंडोज़ सिद्धांत का अर्थ है कि उपयोगकर्ताओं को टूटे हुए दिखाई देने वाले शाब्दिक यूआई बग को पहले ठीक किया जाना चाहिए

B

The broken windows theory (Hunt and Thomas) suggests that visible neglect (bad code, commented-out code, inconsistent style) signals that the codebase has no standards, inviting further neglect — empirically, modules with high existing defect density attract disproportionately more new defects टूटे हुए विंडोज़ सिद्धांत (हंट और थॉमस) से पता चलता है कि दृश्यमान उपेक्षा (खराब कोड, टिप्पणी-आउट कोड, असंगत शैली) संकेत देती है कि कोडबेस में कोई मानक नहीं है, जो आगे की उपेक्षा को आमंत्रित करता है - अनुभवजन्य रूप से, उच्च मौजूदा दोष घनत्व वाले मॉड्यूल असंगत रूप से अधिक नए दोषों को आकर्षित करते हैं

C

Broken windows theory has been empirically disproved and is not considered valid in modern software engineering टूटी हुई विंडोज़ सिद्धांत को अनुभवजन्य रूप से अस्वीकृत कर दिया गया है और इसे आधुनिक सॉफ्टवेयर इंजीनियरिंग में मान्य नहीं माना जाता है

D

Broken windows theory only applies to open-source projects where community standards are absent टूटी विंडोज़ सिद्धांत केवल ओपन-सोर्स परियोजनाओं पर लागू होता है जहां सामुदायिक मानक अनुपस्थित हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Research (Nagappan and Ball at Microsoft, Ostrand et al.) empirically shows defect proneness is heavily concentrated: 20% of files contain 80% of defects, and those same files accumulate more defects over time. The broken windows effect: developers seeing bad code conclude 'this is how we work here' and apply less care. The Boy Scout Rule is the direct counter-practice: leave code better than you found it, creating a visible standard of care.

व्याख्या (हिन्दी) अनुसंधान (माइक्रोसॉफ्ट, ऑस्ट्रैंड एट अल में नागप्पन और बॉल) अनुभवजन्य रूप से दिखाता है कि दोष प्रवणता अत्यधिक केंद्रित है: 20% फ़ाइलों में 80% दोष होते हैं, और वही फ़ाइलें समय के साथ और अधिक दोष जमा करती हैं। टूटी खिड़कियों का प्रभाव: खराब कोड देखकर डेवलपर्स यह निष्कर्ष निकालते हैं कि 'हम यहां इसी तरह काम करते हैं' और कम सावधानी बरतते हैं। बॉय स्काउट नियम प्रत्यक्ष प्रति-अभ्यास है: कोड को जितना आपने पाया था उससे बेहतर छोड़ें, जिससे देखभाल का एक दृश्यमान मानक तैयार हो सके।

2366

EN + हिं Easy

GB What is 'software maintenance cost model' and what factor does empirical research identify as the dominant driver?

IN 'सॉफ़्टवेयर रखरखाव लागत मॉडल' क्या है और अनुभवजन्य अनुसंधान किस कारक को प्रमुख चालक के रूप में पहचानता है?

A

Maintenance cost models identify lines of code as the dominant cost driver रखरखाव लागत मॉडल प्रमुख लागत चालक के रूप में कोड की पंक्तियों की पहचान करते हैं

B

Maintenance cost models predict long-term maintenance effort — empirical research (Boehm, Jones, Lehman) consistently identifies the system's structural complexity (cyclomatic complexity, coupling, cohesion) and the quality of design documentation as the dominant maintenance cost drivers रखरखाव लागत मॉडल दीर्घकालिक रखरखाव प्रयास की भविष्यवाणी करते हैं - अनुभवजन्य अनुसंधान (बोहेम, जोन्स, लेहमैन) लगातार सिस्टम की संरचनात्मक जटिलता (साइक्लोमैटिक जटिलता, युग्मन, सामंजस्य) और डिजाइन दस्तावेज़ीकरण की गुणवत्ता को प्रमुख रखरखाव लागत चालकों के रूप में पहचानता है।

C

Maintenance cost is primarily driven by the number of developers on the maintenance team रखरखाव लागत मुख्य रूप से रखरखाव टीम में डेवलपर्स की संख्या से प्रेरित होती है

D

Maintenance cost models are theoretical tools that have never been validated with real project data रखरखाव लागत मॉडल सैद्धांतिक उपकरण हैं जिन्हें वास्तविक परियोजना डेटा के साथ कभी भी मान्य नहीं किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm's COCOMO maintenance model and Jones' function point-based models both show: structurally complex systems (high coupling, low cohesion, deep inheritance) cost 3-5x more to maintain than well-designed systems of the same size. Undocumented systems add another 30-50% overhead for comprehension. This quantifies the ROI of investing in design quality — lower maintenance cost over the system's lifetime exceeds the upfront design investment.

व्याख्या (हिन्दी) बोहेम के COCOMO रखरखाव मॉडल और जोन्स के फ़ंक्शन पॉइंट-आधारित मॉडल दोनों दिखाते हैं: संरचनात्मक रूप से जटिल सिस्टम (उच्च युग्मन, कम सामंजस्य, गहरी विरासत) को बनाए रखने की लागत समान आकार के अच्छी तरह से डिज़ाइन किए गए सिस्टम की तुलना में 3-5 गुना अधिक है। गैर-दस्तावेजी प्रणालियाँ समझ के लिए अतिरिक्त 30-50% ओवरहेड जोड़ती हैं। यह डिज़ाइन गुणवत्ता में निवेश के आरओआई की मात्रा निर्धारित करता है - सिस्टम के जीवनकाल में कम रखरखाव लागत अग्रिम डिज़ाइन निवेश से अधिक है।

2367

EN + हिं Easy

GB Which of the following best describes 'software entropy' and its long-term impact?

IN निम्नलिखित में से कौन सा 'सॉफ़्टवेयर एन्ट्रॉपी' और इसके दीर्घकालिक प्रभाव का सबसे अच्छा वर्णन करता है?

A

Encrypted sections that reduce performance एन्क्रिप्टेड अनुभाग जो प्रदर्शन को कम करते हैं

B

Gradual code quality degradation due to uncoordinated changes increasing complexity and maintenance cost असंगठित परिवर्तनों के कारण धीरे-धीरे कोड गुणवत्ता में गिरावट से जटिलता और रखरखाव लागत बढ़ रही है

C

Reduction in defects over the software lifecycle सॉफ़्टवेयर जीवनचक्र में दोषों में कमी

D

Efficient use of CPU and memory by the software सॉफ्टवेयर द्वारा सीपीयू और मेमोरी का कुशल उपयोग

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Software entropy (software rot) refers to increasing disorder in a codebase caused by accumulated patches and uncoordinated changes. Over time it raises complexity, making the system harder to maintain and more prone to defects.

व्याख्या (हिन्दी) सॉफ़्टवेयर एन्ट्रॉपी (सॉफ़्टवेयर रोट) संचित पैच और असंगठित परिवर्तनों के कारण कोडबेस में बढ़ती अव्यवस्था को संदर्भित करता है। समय के साथ यह जटिलता बढ़ाता है, जिससे सिस्टम को बनाए रखना कठिन हो जाता है और दोषों की संभावना अधिक हो जाती है।

2368

EN + हिं Easy

GB What is the primary distinction between 'validation' and 'verification' in software engineering?

IN सॉफ़्टवेयर इंजीनियरिंग में 'सत्यापन' और 'सत्यापन' के बीच प्राथमिक अंतर क्या है?

A

Validation is by developers; verification is by users सत्यापन डेवलपर्स द्वारा किया जाता है; सत्यापन उपयोगकर्ताओं द्वारा होता है

B

Verification checks the product is built correctly per specs; validation checks the right product is built for user needs सत्यापन यह जांचता है कि उत्पाद विशिष्टताओं के अनुसार सही ढंग से बनाया गया है; सत्यापन यह जाँचता है कि उपयोगकर्ता की ज़रूरतों के लिए सही उत्पाद बनाया गया है

C

Validation is static analysis; verification is dynamic testing सत्यापन स्थैतिक विश्लेषण है; सत्यापन गतिशील परीक्षण है

D

Both terms are synonymous per IEEE standards आईईईई मानकों के अनुसार दोनों शब्द पर्यायवाची हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Verification answers 'Are we building the product right?' by checking conformance to specifications, while validation answers 'Are we building the right product?' by checking actual user needs. Both are essential but address different concerns.

व्याख्या (हिन्दी) सत्यापन उत्तर 'क्या हम उत्पाद सही ढंग से बना रहे हैं?' विशिष्टताओं के अनुरूपता की जाँच करके, जबकि सत्यापन उत्तर देता है 'क्या हम सही उत्पाद बना रहे हैं?' वास्तविक उपयोगकर्ता आवश्यकताओं की जाँच करके। दोनों आवश्यक हैं लेकिन अलग-अलग चिंताओं का समाधान करते हैं।

2369

EN + हिं Medium

GB Which factor does NOT directly influence the unadjusted function point count in Function Point Analysis?

IN फ़ंक्शन बिंदु विश्लेषण में कौन सा कारक असमायोजित फ़ंक्शन बिंदु गणना को सीधे प्रभावित नहीं करता है?

A

Number of external inputs बाह्य इनपुट की संख्या

B

Number of internal logical files आंतरिक तार्किक फ़ाइलों की संख्या

C

Number of external outputs बाह्य आउटपुट की संख्या

D

Programming language used for implementation कार्यान्वयन के लिए प्रोग्रामिंग भाषा का उपयोग किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Unadjusted Function Points are derived from five functional components: external inputs, outputs, inquiries, internal logical files, and external interface files. The programming language affects productivity but not the functional size measurement.

व्याख्या (हिन्दी) असमायोजित फ़ंक्शन पॉइंट पांच कार्यात्मक घटकों से प्राप्त होते हैं: बाहरी इनपुट, आउटपुट, पूछताछ, आंतरिक तार्किक फ़ाइलें और बाहरी इंटरफ़ेस फ़ाइलें। प्रोग्रामिंग भाषा उत्पादकता को प्रभावित करती है लेकिन कार्यात्मक आकार माप को नहीं।

2370

EN + हिं Easy

GB What does 'technical debt' specifically imply in the context of long-running software projects?

IN लंबे समय से चलने वाली सॉफ़्टवेयर परियोजनाओं के संदर्भ में 'तकनीकी ऋण' का विशेष रूप से क्या अर्थ है?

A

Financial cost of purchasing software licenses सॉफ़्टवेयर लाइसेंस खरीदने की वित्तीय लागत

B

Accumulated suboptimal design decisions for short-term gain that must be refactored at greater future cost अल्पकालिक लाभ के लिए संचित उप-इष्टतम डिजाइन निर्णय जिन्हें भविष्य में अधिक लागत पर दोबारा तैयार किया जाना चाहिए

C

Outstanding unresolved bug reports in the backlog बैकलॉग में बकाया अनसुलझे बग रिपोर्ट

D

Lag between software release and user adoption सॉफ़्टवेयर रिलीज़ और उपयोगकर्ता द्वारा अपनाए जाने के बीच अंतराल

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Technical debt (Ward Cunningham) is the implied cost of rework caused by choosing quick-and-easy solutions over better long-term approaches. Like financial debt, it accrues interest — the longer it is left unaddressed, the more expensive it becomes to fix.

व्याख्या (हिन्दी) तकनीकी ऋण (वार्ड कनिंघम) बेहतर दीर्घकालिक दृष्टिकोण की तुलना में त्वरित और आसान समाधान चुनने के कारण होने वाली पुन: कार्य की निहित लागत है। वित्तीय ऋण की तरह, इस पर ब्याज लगता है - जितना अधिक समय तक इसका समाधान नहीं किया जाता है, इसे ठीक करना उतना ही महंगा हो जाता है।

Software Engineering — MCQ Practice